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

Philip Guenther <guenther+ietfd@sendmail.com> Wed, 11 August 2004 03:06 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27712; Tue, 10 Aug 2004 23:06:11 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BujW2-0004sU-BK; Tue, 10 Aug 2004 23:11:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BujMu-0002r4-Bq; Tue, 10 Aug 2004 23:01:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BujLG-0002ak-Sp; Tue, 10 Aug 2004 22:59:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27411; Tue, 10 Aug 2004 22:59:51 -0400 (EDT)
Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BujPu-0004mx-Uw; Tue, 10 Aug 2004 23:04:44 -0400
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i7B2xMji031869 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 10 Aug 2004 19:59:22 -0700
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i7B2xLOV043227; Tue, 10 Aug 2004 19:59:22 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200408110259.i7B2xLOV043227@lab.smi.sendmail.com>
To: "Eric A. Hall" <ehall@ehsco.com>
From: Philip Guenther <guenther+ietfd@sendmail.com>
In-reply-to: <4118E64D.7060307@ehsco.com>
References: <E1BuCka-00016P-6d@megatron.ietf.org> <16664.44858.761574.980321@chiark.greenend.org.uk> <4118E64D.7060307@ehsco.com>
Date: Tue, 10 Aug 2004 19:59:21 -0700
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: ietf@ietf.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, iesg@ietf.org
Subject: Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352

Eric A. Hall <ehall@ehsco.com> writes:
...
>I also note that the digest media-type is already specified and is the
>appropritate interchange format if you actually do have a collection of
>well-formed 2822 objects. But if you have an mbox file, you have to
>exchange it as an opaque database, and you have to delineate any internal
>assumptions through out-of-band negotiations. The mbox media-type is for
>use with tagging and identifying the data being exchanged ("here is an
>opaque database of unspecified message objects") only.
...
>This is not intended to serve as an authoritative reference to the mbox
>database format, but is only intended to provide an identifier for the
>database-type when it is transferred. Out-of-band negotiation is necessary
>in all cases anyway, and I don't really think it's appropriate for the
>IETF to define an application-specific database format anyway.


If there are no defined semantics for the content of an application/mbox
part, how does the type differ from application/octect-stream?  In both
cases you have to look to out-of-band info to interpret the data.
Indeed, there appear to be no requirements at all on the content.  If
successful uses of this content-type effectively requires private
arrangement, why does it need a standard content-type instead of each
such exchange using a content-type tailored to the circumstance and
taken from the "vnd.", "prs.", or "x." trees.  How does use of
application/mbox over application/octet-stream or some other
content-type improve interoperability?

...
[regarding creating a spec for a mailbox file format]
>I'd like to see one, and I'd like to see whatever *NIX consortium is
>responsible for such things get together and define one.

At that point, would application/mbox be updated to refer to said spec,
rendering non-compliant some chunk of the previous uses, or would a new
content-type be specified?


Philip Guenther

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf