--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
<simon(_at_)josefsson(_dot_)org> wrote:
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> 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.
Yes, and I thought I sent in a note saying I supported this view but I cannot
find it. I also strongly opposed standards-track publication and think
experimental is a far better choice.
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.
This suggestion was at the very least strongly implicit in the earlier
discussion.
It also occurs to me that what may be needed here is a BCP on how to best use
ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly
decorated with features, so it makes sense to me that if we're going to
continue to use it why not have a document discussing what features make sense
and what ones don't. (For example, some sage advice on when and how to use
EXTERNAL could have made several protocols a lot more tractable.)
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.
Given how little uptake (AFAIK) there has been of the various encodings for
ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two
others whose names I cannot recall), I'm not especially worried about XER
taking the world by storm. Indeed, I think it would actually help XER's case if
there was some explanation of where and why you'd ever want to use it.
The fact that pigs can be made to fly with enough dynamite doesn't get you
permission to use explosives for purposes of implementing porcine aviation.
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.
Agreed.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf