On 2/3/2004 3:21 AM, Paul Crowley wrote:
I think it's still *way* too early to be discussing this sort of
detail, but for what it's worth... I understand the temptation to say
that the world should settle on ONE generalised tree format and use it
for everything, to bring some control to file format hell. I have a
lot of sympathy, but a big point of disagreement.
The world needs TWO generalised tree formats. It needs one very rich,
expressive one that's good at handling text and whose fundamental unit
is the character, and one very simple, sparse one based on octets that
easily and efficiently handles arbitarary binary content and which is
incredibly easy to parse.
My feeling is that we're blurring the human-to-human vs general transport
lines again.
The overall transport doesn't need a specific body-type; it should be
content-neutral, since there are many potential usages, and MIME can
pretty much handle those variances without much additional effort on our
part. Applications that want/need to exchange automata shouldn't be forced
into using a body format that doesn't suit them. If we agree on that, then
we're pretty much left to agree that mime-type and CTE declarations for
the message body are the major concerns, while the content-types are for
the applications to worry about.
Talking about the characteristics of the preferred human-to-human format
does make sense, but in the context of that specific application. Some of
the features I'd personally like to see supported in an H2H format:
eliminate hard line-wrapping; flowed by default
eliminate the '>' metaphor; in-band references and annotations
allow sender- and recipient-side display formatting alike
All of that stuff (and more) could be folded into a new MIME type along
with the various rules and such, and XML or some other markup language
could be used for that.
At the same time, the system should also allow the transport of legacy
text/plain, or a futuristic application/sql-response, and anything else
that might be transported between the disconnected processes.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/