Eric A. Hall wrote:
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"
So far, so good.
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.
With the proposal as it stands, you'd also still have an opaque
blob, with the same problems. But not with multipart/digest. And
why do you claim that there will not be any conversions; multipart/digest
is the lingua franca of message collections and it is unrealistic
to expect that some system is going to be able to reliably handle
an opaque blob constructed on a foreign system, in the face of
common transport modifications, and with no information regarding
the content of the blob other than an extremely vague label.
(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.
Since you have opposed parameters, what you are left with is
merely a subtype tag change from "octet-stream" to "mbox". Now
could you please explain exactly what "'s not working" about
that, and precisely how *merely* changing the subtype tag to
"mbox", with no supplementary information is going to solve
whatever those problems are. In other words, what *exactly* is
the problem that you're trying to solve that cannot be addressed
by existing media types, and *precisely* how will the proposal
solve that problem?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf