Re: Protest: Complexity running rampant
Hi - > From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > To: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>; "Fred Baker" <[EMAIL > PROTECTED]> > Cc: > Sent: Tuesday, February 27, 2007 6:45 AM > Subject: RE: Protest: Complexity running rampant ... > DER would not have been so bad if they had chosen to use > indefinite length encoding for lists rather than definite length, > thus requiring implementations to chose between unnecessary > recursion and unnecessary memory copies. ... There's a third approach that can be simpler to implement and faster to execute - do the encoding *backwards*, starting at the end of your buffer. Then you don't need to encode the length (and length-of-length) fields before you know their values. That way one can do the encoding without recursion or unnecessary copies, and ensure that all lengths are minimal. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Protest: Complexity running rampant
I don't think this is an issue worth objecting to. Complexity exists at many levels. There is complexity of specification and complexity of implementation. The two are not the same. I can imagine two reasons why I might want to have ASN.1 in XML. The first is that I want to use a single set of tools for data serialization and unpacking. This is particularly attractive if I was going to use an ASN.1 structure inside an XML packet. The second is if I was looking for a way to move from a legacy ASN.1 base to an XML base. As far as complexity of architecture goes neither ASN.1 not XML are to my taste. ASN.1 looks like a briliant idea that went into committee and got broken by a few participants whose political skills exceeded their technical skills. This is a real problem in data formats since they appear to be simple enough that everyone can have an opinion. ASN.1 is not so bad unless you have to either use the seriously derranged DER encoding or deal with some of the later additions to the data model. DER would not have been so bad if they had chosen to use indefinite length encoding for lists rather than definite length, thus requiring implementations to chose between unnecessary recursion and unnecessary memory copies. I recently wrote an ASN.1 unpacking routine in Javascript in a few hundred lines. It is not that difficult (packing is another matter - ugh!). XML syntax is not that bad either. The problems are mostly due to XML schema which makes the unfortunate mistake that C++ made of not jetisoning the all cruft from C and starting fresh. The prefix scheme is neither necessary nor convincing in my view. It breaks the principle that the choice of modular decomposition in a design should not constrain the end result. In other words the fact that XML Encryption is built on XML Signature should not be visible when reading a document that is based on both. I don't see that the 'complexity' of XML or ASN.1 is unreasonable though. The problems come from issues such as modularity and version control that have always been tricky. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
At 9:49 AM -0500 2/19/07, John C Klensin wrote: > >For the record, I would have no problems with Informational or Experimental >publication of this collection -- it is the proposed decision to standardize >that bothers me. When I first discussed publication of this with the IESG, I pointed out that the author had asked for Proposed Standard, but I was more likely to support Informational or Experimental. At the time, Sam asked that it remain under consideration for standards track (at least up until the ballot discussion). One point raised was how easy it would be to reference these as encodings if they were informational or experimental, but I believe Sam had other points as well. Given the ongoing discussion, I asked Russ to Defer this document; that will give Sam a chance to come back from vacation and enter the discussion, and all of us a chance to continue it. My current take-away from the discussion is that the broader community would prefer we start with Informational or Experimental and consider the need to deal with downrefs as signals that this has sufficient constituencies to need standardization. Another point made in private was that many of the reviewers of this document to date have been familiar enough with ASN.1 that those aspects of this encoding were not surprising or difficult; that may be why the model issues were not raised earlier. I'm happy that in the case the Last Call discussion has raised the point, and if Russ's defer does not give us enough time to terminate the discussion, I'll withdraw the document. If we can conclude on a community recommendation (e.g. for Informational or Experimental) before that, though, it would be nice for my successor, who will otherwise need to take these on. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
Dave Crocker wrote: Fred Baker wrote: is it a bad thing to provide the expressive nature of ASN.1 in a human-readable and popular data representation? The one thing IETF standardization certainly ought to imply is that there is a real constituency interesting in using the specification in the near-term. Who wants to use this spec, now, and why? I almost sent an email asking this question when I read the drafts. My reaction was "This seems like a lot of stuff to put on the standards track without being the output of a WG." I didn't, because I figured there must be some significant constituency that wants this standardized. So, is there or not? d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
Bob Braden wrote: Why is "near term" an essential requirement? If the Internet designers had opted for the "near term", we would all be running some flavor of X.25 today. Research vs. engineering. Standards are for engineering. When they don't solve near-term problems they tend not to solve any problems at all. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
The one thing IETF standardization certainly ought to imply is that there is a real constituency interesting in using the specification in the near-term. Dave, Why is "near term" an essential requirement? If the Internet designers had opted for the "near term", we would all be running some flavor of X.25 today. Bob Braden Who wants to use this spec, now, and why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
Fred Baker wrote: is it a bad thing to provide the expressive nature of ASN.1 in a human-readable and popular data representation? The one thing IETF standardization certainly ought to imply is that there is a real constituency interesting in using the specification in the near-term. Who wants to use this spec, now, and why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
On 2/19/07, John C Klensin <[EMAIL PROTECTED]> wrote: For the record, I would have no problems with Informational or Experimental publication of this collection -- it is the proposed decision to standardize that bothers me. Exactly. Under no circumstances should it ever be OK to use IETF reputational leverage to pressure someone to use something as (to be charitable) unproven as this. -Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
--On Monday, February 19, 2007 11:45 +0100 Harald Tveit Alvestrand <[EMAIL PROTECTED]> wrote: Having not read the above and not really caring much what happens in the layers up in the stratosphere as long as its designers don't by its sheer weight make the application unusable, is it a bad thing to provide the expressive nature of ASN.1 in a human-readable and popular data representation? With the "expressive nature of ASN.1" comes every single piece of the complexity of ASN.1 that people have shied away from. And to this complexity, there is added the complexity of XML. I have nothing against such things being published. Let foolishness fail on its own. I have significant issues with using IETF cycles on developing and (not least) maintaining such a complex beast. Let me add an observation to Harald's... (1) "More options" is rarely A Good Thing for the Internet. This is something of a marginal case in terms of how strongly that principle applies because it presumably does not involve multiple options within the same protocol. It does, however, imply less code reuse and more work in other respects. While XML is probably easier to read than ASN.1, much of the ASN.1 complexity involves understanding and working with the model. As far as I can tell from skimming these documents, that requirement doesn't change here: this is just a syntax translation of ASN.1 into XML. IMO, for standards-track, there should be a stronger demonstration of why this is needed -- and enough better than the alternatives -- to justify an additional option. In addition, while it may be just a personal bias, I believe that, in this century, if we are going to standardize another one of these, we should be looking at something that can express semantics (not just syntax, however elaborate) in a clear way. If that method uses an XML or XML-like syntax, so much the better. But this doesn't seem to me to add enough value to clutter the standards-track landscape. For the record, I would have no problems with Informational or Experimental publication of this collection -- it is the proposed decision to standardize that bothers me. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
--On 19. februar 2007 02:40 -0800 Fred Baker <[EMAIL PROTECTED]> wrote: On Feb 19, 2007, at 1:55 AM, Harald Alvestrand wrote: My attention has recently been drawn to this set of documents: - draft-legg-xed-asd - draft-legg-xed-asd-gserei - draft-legg-xed-asd-xerei - draft-legg-xed-rxer - draft-legg-xed-rxer-ei It's, as far as I can tell, an attempt at a complete reimplementation of ASN.1 using XML. Stepping away from the details of the implementation, let me ask what the result is? (note that I am not an apps person, and have no skin the the game, and therefore am asking a question trying to get to the root here) There are any number of structured data representations around; ASN.1 and XML are two, and one could consider the structure used in RFC 2445 as a third example. People have shied away from ASN.1 citing complexity. Whatever its warts, XML is pretty readily understood. I'd challenge that but there is experience that people are using XML successfully in applications. So I guess XML has proven itself. Having not read the above and not really caring much what happens in the layers up in the stratosphere as long as its designers don't by its sheer weight make the application unusable, is it a bad thing to provide the expressive nature of ASN.1 in a human-readable and popular data representation? With the "expressive nature of ASN.1" comes every single piece of the complexity of ASN.1 that people have shied away from. And to this complexity, there is added the complexity of XML. I have nothing against such things being published. Let foolishness fail on its own. I have significant issues with using IETF cycles on developing and (not least) maintaining such a complex beast. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
On Feb 19, 2007, at 1:55 AM, Harald Alvestrand wrote: My attention has recently been drawn to this set of documents: - draft-legg-xed-asd - draft-legg-xed-asd-gserei - draft-legg-xed-asd-xerei - draft-legg-xed-rxer - draft-legg-xed-rxer-ei It's, as far as I can tell, an attempt at a complete reimplementation of ASN.1 using XML. Stepping away from the details of the implementation, let me ask what the result is? (note that I am not an apps person, and have no skin the the game, and therefore am asking a question trying to get to the root here) There are any number of structured data representations around; ASN.1 and XML are two, and one could consider the structure used in RFC 2445 as a third example. People have shied away from ASN.1 citing complexity. Whatever its warts, XML is pretty readily understood. Having not read the above and not really caring much what happens in the layers up in the stratosphere as long as its designers don't by its sheer weight make the application unusable, is it a bad thing to provide the expressive nature of ASN.1 in a human-readable and popular data representation? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protest: Complexity running rampant
My attention has recently been drawn to this set of documents: - draft-legg-xed-asd - draft-legg-xed-asd-gserei - draft-legg-xed-asd-xerei - draft-legg-xed-rxer - draft-legg-xed-rxer-ei It's, as far as I can tell, an attempt at a complete reimplementation of ASN.1 using XML. I was very strongly reminded of a 1992 quip by Marshall Rose: ASN.1 is probably the greatest failure of the OSI effort, it led hundreds of engineers, including myself, to devise data structures that were far too complicated for their own good. Now, what has changed in the last 15 years that: - Makes this complexity valuable, where before it was harmful - Makes the IETF community the right place to standardize this complexity? The deadline for comments is theoretically passed: The IESG has received a request from an individual submitter to consider the following documents: - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER) ' as a Proposed Standard - 'Encoding Instructions for the Robust XML Encoding Rules (RXER) ' as a Proposed Standard - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER) ' as a Proposed Standard - 'Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) ' as a Proposed Standard - 'Abstract Syntax Notation X (ASN.X) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-legg-xed-asd-xerei-03.txt http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-ei-04.txt http://www.ietf.org/internet-drafts/draft-legg-xed-asd-gserei-03.txt http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-07.txt http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10739&rfc_flag=0 But it is not yet approved by the IESG, so it's not too late to comment. Let the arguments begin... Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
