Re: Protest: Complexity running rampant

[John C Klensin <john-ietf at jck.com>]

--On Monday, February 19, 2007 11:45 +0100 Harald Tveit 
Alvestrand <harald at alvestrand.no> 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf