Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard

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