ietf
[Top] [All Lists]

Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC

2007-03-16 11:39:43
"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

<Prev in Thread] Current Thread [Next in Thread>