Re: Best practice for data encoding?

[Michael Thomas <mat at cisco.com>]

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.org
https://www1.ietf.org/mailman/listinfo/ietf