John C Klensin wrote:
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
<[EMAIL PROTECTED]> wrote:
"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> writes:
Arguments on complexity are too easy to make. Every time a
proposal is made I hear the complexity argument used against
it. Everything we do is complex. Computers are complex.
Committee process usually increases complexity somewhat.
If an argument can always be used what is the discrimination
power?
How about using answers to the question "Is this complexity
needed?" as a discriminator?
Sometimes, there is no better solution than one with certain
complexity. That isn't inherently bad.
I'm not sure the need for this particular complex solution was
demonstrated. I don't recall anyone defending it. The
experimental track thus seems appropriate, if it should be
published at all.
But that was precisely where the other thread, if I recall, came
out. It wasn't an argument against complexity. It was an
argument about introducing another optional way of doing things
because we _know_ that many options lead to worse
interoperability. And it was a suggestion/ request that, before
this document was published in _any_ form, that it at least
acquire a clear discussion as to when one would select this form
over the well-established ASN.1 form for which there is existing
deployment, existing tools, etc. Put differently, we all know
that this _can_ be done but, if there is another solution
already out there, widely deployed, and in active use, a clear
explanation about _why_ it should be done and under what
circumstances it is expected to useful is in order.
That suggestion about an explanation was a specific request
about the document, not idle theorizing about the character of
ASN.1 or the nature of complexity.
And, again, pretending that the discussion didn't occur
impresses me as a little strange.
I was going to raise this issue, but I deleted the mail when I realized
this is going to be an Experimental RFC (according to the subject line).
I don't think it harms interoperability to introduce an experiment
into the mix. If deployment and useful tools follow, then maybe
a later revision can move to the standards track.
john
Andy
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
