"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.
I would certainly be supportive of that.
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.
To be honest I found the specifications totally inpenetrable as a means of
initially learning ASN.1, including the relatively straightforward initial
description that first appeared in X.400-1984. (I have no idea why they insist
on making macros in particular seem like so much more than they really are.) Of
course I no longer have this problem - but surely that's to be expected after
implementing X.400-1988 from scratch...
The free books are OK IMO but not great. Although it's now fairly dated, I
still think the best book on ASN.1 is the one by Douglas Steedman: ASN.1
Tutorial and Reference. Unfortunately it is out of print and nearly impossible
to find - and it was fairly expensive when it was in print. (And no, my copy is
not for sale ;-)
I went so far as to put this one on my list of books the ACM should revive and
republish, but I fear I was the only person who did so.
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.)
Or it might not. If memory serves, I actually implemented this stuff in our
X.400 code because some profile or other (German maybe?) required it. What I
found was that apparently everyone else that did it just coded it as a checkbox
item and didn't bother to check to see if it actually worked. The result was a
huge loss of interoperability, and X.400 interoperability was in general so
poor that I think we actually went so far as to rip it all out. (It's a huge
pain to implement for X.400 in any case because X.400 P1 uses RTSE, not ROSE,
and hence it is convenient to pre-encode messages and put them in files.)
This IMO is one of the big problems with lots of options in protocols - they
tend to result in batches of infrequently used code that contains lots of bugs.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf