On 8/17/2004 2:09 PM, John C Klensin wrote:
> To be clear about this, I think there are three choices which we
> might prefer in descending order:
>
> (1) There is a single canonical "wire" format in which
> these things are transmitted.
Such a specification would surely dictate "a series of message/rfc822
objects". But if we were to require that end-points perform conversion
into a neutral form, we might as well go the whole nickel and just say
"use multipart/digest", because that's where we'd end up after monhts of
beating on each other.
We'd still be in the same place we're at today, of course, because HTTP
and filesystem transfers aren't going to do mbox->digest conversion any
more than they are going to do EOL conversion or Content-Length calcs.
We'd still have opaque messaging databases that people wanted to transfer,
search, open and otherwise automate, but couldn't.
> (2) The content-type specifies a conceptual form
> ("application/mbox") but has _required_ parameters that
> specify the specific form being transmitted.
Global parameters are useless if the parser is intelligent enough to
figure out the message structure independently. Given that such
intelligence is a prerequisite to having a half-baked parser, the global
parameters are always unnecessary.
Actually, global parameters are more than useless. What if we have a mixed
mbox file, where some messages are untagged BIG5 and others are untagged
8859-1, or we have some messages have VMS::Mail addresses and others have
MS/Mail addresses, or so forth? The global nature of global parameters
ignores the per-message reality of the mbox structure.
Global parameters can also be harmful if they conflict with reality.
> (3) These might as well be sent with
> application/octet-stream, with optional file name, etc.,
> information.
That's where we are now and we already now that's not working.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf