Theodore Tso wrote:
On Mon, Jun 05, 2006 at 08:21:29PM -0400, Steven M. Bellovin wrote:
More precisely -- when something is sufficiently complex, it's inherently
bug-prone. That is indeed a good reason to push back on a design. The
question to ask is whether the *problem* is inherently complex -- when the
complexity of the solution significanlty exceeds the inherent complexity of
the problem, you've probably made a mistake. When the problem itself is
sufficiently complex, it's fair to ask if it should be solved. Remember
point (3) of RFC 1925.
One of the complaints about ASN.1 is that it is an enabler of
complexity. It becomes easy to specify some arbitrarily complex data
structures, and very often with that complexity comes all sorts of
problems. To be fair, though, the same thing can be said of XML (and
I'm not a big fan of a number of specifications utilizing XML either,
for the same reason), and ultimately, "you can write Fortran in any
language".
Ultimately, I have to agree with Steve, it's not the encoding, it's
going to about asking the right questions at the design phase more
than anything else, at least as far as the protocol is concerned.
As far as implementation issues, it is true that ASN.1 doesn't map
particularly well to standard programming types commonly in use,
although if you constrain the types used in the protocol that issue
can be relative easily avoided (so would using XML, or a simpler
ad-hoc encoding scheme). I don't think there is any right answer
here, although my personal feelings about ASN.1 can still be summed up
in the aphorism, "Friends don't let friends use ASN.1", but that's
mostly due to psychic scars caused by my having to deal with the
Kerboers v5 protocol's use of ASN.1, and the feature and design bloat
that resulted from it.
Here's my down in the trenches observations about XML and to some degree
ASN.1.
XML gives me the ability to djinn up a scheme really quickly with as
much or as
little elegance as needed. If nothing else, XML quite rapidly allows me
to hack up
intpreters that would otherwise been another parsed text file casuality
residing in /etc.
And most likely, if they could read the previous text encoding, the XML
is about as
transparent. This is a very nice feature as it allows common parsers,
leads to common
practices about how to lay out simple things, and common understanding
about what
is right and wrong. So, for my standpoint XML is "no more ad hoc
parsers!", which
is good from a complexity standpoint, especially when you look at how
spare the
base syntax is.
That said, anything that requires nested structure, etc XML is probably
just as
inadequate as anything else. And who should be surprised? Don't blame the
Legos that they self-assemble into a rocket ship. One big plus about XML is
that I can just _read_ it and hack up pretty printers in trivial time.
ASN.1 that is,
um, abstract necessasrily needs to go through a translation layer which IMO
is never as fun and convenient -- and absolutely discourages dilitante
hacking (when
is the last time you fiddled with an XML file vs. the last time you
fiddled with
ANS.1? never for the latter?).
I guess that what part of what this devolves into is who we're writing these
protocols/schemes for: machines or people? That, I think, is a huge false
dilemma. We clearly are writing things for _both_ (the executors and the
maintainers) ; the only question in my mind is whether an easy for human
to maintain encoding is too inefficient on the wire for its task. In some
cases it clearly is, but those cases are becoming the outliers -- especially
at app layer -- as the march of memory and bandwidth plods on.
So with all of these wars, the sexy overblown hype ("yes of course XML can
solve world hunger!") often eclipses the routine and mundane tasks of
writing
and maintaining a system (golly, I need a config file for this, it's
been a while
since I wrote a really crappy parser. woo woo!). C'est la vie.
Mike
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf