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