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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf