> >>>>> "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