"Ned" == Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> writes:
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
<simon(_at_)josefsson(_dot_)org> wrote:
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.
Ned> This suggestion was at the very least strongly implicit in the earlier
Ned> discussion.
I think I made some preliminary conclusions regarding the intent of
this effort, which I can write more about later.
Ned> It also occurs to me that what may be needed here is a BCP on how to best
use
Ned> ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly
Ned> decorated with features, so it makes sense to me that if we're going to
Ned> continue to use it why not have a document discussing what features make
sense
Ned> and what ones don't. (For example, some sage advice on when and how to use
Ned> EXTERNAL could have made several protocols a lot more tractable.)
I began such a document a few years ago. Perhaps I should dust it
off. Also, I think many people contemplating ASN.1 would do well to
read the actual specifications, as well as the reasonably good (and
freely downloadable) books by Dubuisson and Larmouth.
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.
Ned> Given how little uptake (AFAIK) there has been of the various encodings for
Ned> ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two
Ned> others whose names I cannot recall), I'm not especially worried about XER
Ned> taking the world by storm. Indeed, I think it would actually help XER's
case if
Ned> there was some explanation of where and why you'd ever want to use it.
Use of alternative encoding rules might best be coupled with
presentation layer negotiation, which is a direction the IETF has
historically resisted moving towards, I think. (It doesn't help that
PER is rather baroque for the sake of conserving bits.)
Ned> The fact that pigs can be made to fly with enough dynamite doesn't get you
Ned> 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.
Ned> Agreed.
I believe the omissions in the writeup have been acknowledged to be
mistakes.
---Tom
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf