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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >>>>> "Ned" == Ned Freed <ned.freed@xxxxxxxxxxx> writes:

> >> --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
> >> <simon@xxxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]