[
Lists Home |
Date Index |
Thread Index
]
Rick Marshall <rjm@zenucom.com> writes:
> to me it's [rfc822] a bit like vinyl. that was the last sound storage system that
> could be replayed mechanically. all you need is a needle and a paper
> cone. try that with a cd. well ascii .txt is a bit like that. you don't
> need any extra software to read it (cat or type being the equivalent of
> a needle and cone). but just like the recording industry i think there
> are big gains from using more sophisticated techniques to code our
> information and standards, even at the loss of some basic portability.
I think better of the music industry than that they'd adopt a
technique for the sake of its sophistication. There were specific
advantages to the new CD format that made content producers and
consumers choose it over the existing standard: smaller physical size,
lower marginal manufacturing cost, better quality, larger capacity,
better durability, faster seek times (you don't have to manually move
the needle to find the track you want), high cost of copying, at least
before cheap CDR devices came along (this applies to cassettes more
than LPs). I don't believe XML offers any such advantages over
rfc822-style text headers.
Specifically, rfc822 offers applications a lot of flexibility about
how detailed their parsing of the headers is. If you are a mailing
list program, you care about the content of Received: headers because
you want to avoid mail loops, but most MUAs treat them as opaque
strings. Procmail may look into the Subject: field to sort [xml-dev]
messages into an appropriate mailbox, even though
http://ietf.org/rfc/rfc2822.txt#3.6.5 says it is unstructured. If you
wanted to provide the same flexibility in an XML syntax, you'd either
have to specify each EBNF production form the rfc as an element, or
require clients to do serious microparsing. The former is unhelpful
because there is a surprising variety of applications that process
mail and they have completely different needs; no size DTD will fit
them all. The latter offers no advantages over the existing syntax.
> my point is that if soap and the work on xml security really does work
> then an xml based mail system using those technologies (or similar)
Note that both the HTTP and the email bindings for SOAP rely on
rfc822-style ASCII headers to work. You don't /have/ to use either,
but these are the two that people use AFAICS.
Ari.
--
Elections only count as free and trials as fair if you can lose money
betting on the outcome.
|
