>>>>> "Ned" == Ned Freed <[EMAIL PROTECTED]> writes:
>> --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson >> <[EMAIL PROTECTED]> 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
