W3C home > Mailing lists > Public > ietf-discuss@w3.org > April 2001

Re: Two new drafts: Multipart/Interleaved and Application /BatchBeep

From: Keith Moore <moore@cs.utk.edu>
Date: Mon, 30 Apr 2001 15:43:02 -0400
Message-Id: <200104301943.PAA02400@astro.cs.utk.edu>
To: Jacob Palme <jpalme@dsv.su.se>
cc: discuss@apps.ietf.org
> At 15.17 -0400 01-04-24, Keith Moore wrote:
> >  > Did you also look at my comparison between RFC822 and XML
> >>
> >>  RFC822 example:
> >>       From: Father Christmas <fchristmas@northpole.arctic>
> >>
> >>  XML encoding of the same information:
> >>
> >>       <from>
> >>         <user-friendly-name>Father Christmas</user-friendly-name>
> >>         <e-mail-address>
> >>           <localpart>fchristmas</localpart>
> >>           <domainpart>
> >>             <domainelement>northpole</domainelement>
> >>             <domainelement>arctic</domainelement>
> >>         </domainpart>
> >>       </from>
> >>
> >>  The XML encoding uses five times as many characters.
> >
> >you could have as easily said:
> >
> ><from>Father Christmas &#60;fchristmas@northpole.arctic&#62;</from>
> >
> >and that would have been a more accurate comparison.  The XML version
> >uses a few more characters, but it's not a huge difference overall.
> But then you are combining XML with other encoding. &#60 and
> @ are framing constructs from RFC822 which in your example
> are combined with XML. So your example is a mixture of two
> different encoding methods, XML and RFC822, which is not
> very neat. 

I disagree in the strongest possible terms.  Different layers have
different needs in a presentation encoding; neither XML nor any other 
encoding scheme is suitable for use at every layer.  Not only that, but 
it is sometimes quite desirable for the encoding at one layer to be 
opaque to other layers.

> You miss the main advantage of XML (and ASN.1/BER),
> that one single syntactical method is used for all encoding,
> and that the same framing rules can be used everywhere.

just because ASN.1 or XML can be used everywhere doesn't mean it's
a good idea.

yes, RFC 822 would have been better if it were a bit more regular,
but X.400 is even less regular - precisely because it makes too
much use of the expressive power of ASN.1.

> In RFC822, there are different framing rules for different
> places in the encoded information, and different rules for
> allowed characters and special encoding of non-allowed
> characters in different parts of the message header.
> In XML, you get a single, unified method of framing,
> but at the expense of a much more verbose encoding.
> That is the point I wanted to make with my example.

right, but you're presuming that XML is misused.  you might be
presuming the very kind of misuse that the "use XML for everything"
proponents are advocating, but such misuse is not inherent with XML.
nor is XML the only presentation layer to witness this degree of misuse.

> In the case of RFC822, it has solved the problems with use
> of framing characters in encoded data by some very archaic
> rules, such that spaces are (in practice, even if not according
> to the standards text) not allowed in e-mail addresses and
> that special characters have to be encoded in special ways.

in any protocol, regardless of what framing method it uses,
seldom-used features are often mis-implemented.

> We are so accustomed to RFC822 that we do not think of the
> restrictions it imposes. 

implementors are aware of them.

> But non-Internet experts do not
> like the RFC822 rules for what is allowed and not allowed
> in the elementary parts of e-mail addresses, even if
> nowadays almost everyone in high-technology countries
> are so accustomed to Internet rules that they do not
> complain about them anymore.

Could it be that some of those restrictions exist for other reasons?
X.400 also has its share of restrictions on the format of addresses,
even though it uses ASN.1, which would otherwise allow those addresses
to be transparent.

since email addresses get used in a wide variety of contexts other 
than email protocols, it's hardly surprising that there are 
(both practical and imposed) constraints on their use. 

> The XML encoding has another advantage: If the keywords
> are chosen well, you can read the XML data and understand
> it even if you do not know the encoding rules. In the
> RFC822 example, you have to know what is user-friendly
> name and what is e-mail address, what is local part
> and what is domain name, how a domain name can be
> hierarchical by the use of ".". 

that depends on who "you" are.  users just have to be able to
recognize the pattern xxx@yyy.zzz as an email address.  this 
is actually easier for a human than having to look through 
the XML and try to figure out which sub-fields are part of an
address and which ones are part of a message.

> This is of course of
> most value when the data transmitted has a syntax
> with which the reader is not already familiar. In the
> case of RFC822, we are so accustomed to its special
> usage of "<", "@" and ".", that this is no problem to
> an Internet-savvy person.

as far as I can tell, people adapted to this rather quickly.
email addresses are a lot easier to use (and to prononuce)
than URLs, but people have even adapted to URLs.

Received on Monday, 30 April 2001 15:44:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC