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

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 13 Aug 2004 11:33:18 -0400

Keith Moore <[email-masked]> wrote on Thu, 12 Aug 2004 08:45:24 -0400:

> this is an application for a media-type. it's not trying to define the
> mbox format, it's just trying to define a label for the mbox format
> that can be used in contexts where MIME media-type labels are required.

That's correct; this is a tag definition, not a format specification.

Others should note that RFC2048 is designed to facilitate registrations --
more definitions for common data-types are widely preferred over a
proliferation of "x-foo" media-types that result from high registration
barriers (read the intro to 2048 if you don't believe me) -- and that's
the limited objective of this proposal.

There are a few places where this tag is necessary or useful. Online
downloadable archives of mailing lists would be easier to import, search
and otherwise manipulate if a media-type were defined and which allowed a
transfer agent to bridge the data to a local content agent (most of the
IETF archives are in mbox format, and I'm aware that certain cellular
email systems allow for downloadable SMS/email logs via mbox, not to
mention the proliferation of web/local mail systems that use mbox files
which are often transferred back and forth). Local actions such as
importing or opening a local mbox file would also be easier to perform if
there was a media-type that the OS could use (I have many mbox files of
project-specific archives and would appreciate better OS/messaging
integration with these files [such as opening and searching folders the
same as I can with message/rfc822 file objects], but need an OS-level
media-type to get there). And so forth.

A definitive authoritative specification for all variations of the mbox
database format is explicitly not the objective, for several reasons. For
one thing, such a definition is outside the IETF's purview, the same as a
definition for Outlook or Eudora or other vendor/platform-centric database
formats would be. Second, if the IETF *did* try to write such a
definition, it would quickly settle on the fact that multipart/digest
already exists for such purposes, and that defining an mbox format would
be redundant. If development proceeded beyond that (unlikely at best),
then the spec would necessarily conform with other messaging definitions,
and would end up declaring that mbox files SHOULD/MUST be compliant with
RFC2822 messages at a minimum, which ignores the reality of eight-bit
content, long lines, untagged charsets, EOL variations, etc. Other folks
can start a bof/wg and go through this process if they want to, but
frankly I'm happy just registering the media-type (the purpose of the
process, and the objective of this I-D).

On top of all that, mbox parsers need to be aware of the limitations and
variations on the content, and this cannot be adequately handled with a
media-type definition.

Suggestions about parameters has come up before (John Klensin suggested it
to me a couple of months ago). Unfortunately, these kind of helper tags
attempt to define content rules rather than transfer rules, and therefore
represent a non-trivial layer violation. They are analogous to using a
"version=" tag for app/postscript and relying on that meta-information
instead of embedded clue data. Obviously, content agents should be aware
of the content formatting rules. [what happens when the helper meta-tags
are lost? should the content agent NOT look at the content to make a
determination? that's where the logic belongs in the first place, so
putting it into the transfer layer is not only irrelevant it is possibly
harmful.] This data should not be overflowed to the transfer agent except
where it affects the transfer process proper, which is not the case with
any of the suggested tags.

> however I don't think this should be up for PS, as the standards track
> is intended for protocols that can be subject to interoperability tests,
> and this is just a label. Informational seems more appropriate to me.

I'll go along with that. 2048 only requires IESG approval, but does not
require standards-track, and dropping to informational gets us there.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Aug 2004 11:47:34 -0400

> A definitive authoritative specification for all variations of the
> mbox database format is explicitly not the objective, for several
> reasons. 

that's fine.  I fully support registering application/mbox as a media
type.

> For
> one thing, such a definition is outside the IETF's purview, the same
> as a definition for Outlook or Eudora or other vendor/platform-centric
> database formats would be. 

I have to disagree here.  Perhaps standardizing mbox would be outside
of IETF's purview, but I think it would be valuable for IETF to publish
a peer-reviewed Informational description of (1) existing practice for 
mbox files and (2) recommended practice for reading and writing mbox
files.  I just don't think that this should be critical path for getting
application/mbox registered.

---

From: [email-masked]
Date: Fri, 13 Aug 2004 10:26:50 -0700 (PDT)

> application/mbox registered.

I agree. Such a specification shouldn't be a requirement for this registration,
but an informational document would be a nice thing to have. Whether or not
sufficient energy exists to get it done is another matter - a similar
informational document on the many variations of uuencode has been on my to-do
for well over a decade now, and I don't see myself getting to it any time
soon...

				Ned

---

From: [email-masked] (Kai Henningsen)
Date: 14 Aug 2004 15:04:00 +0200

> That's correct; this is a tag definition, not a format specification.

That is not the problem. The problem is that the tag is not specific  
enough to be useful.

> transfer agent to bridge the data to a local content agent

... but absent specification of *which* mbox format it is, this can only  
work by luck.

> database format is explicitly not the objective, for several reasons.

Note that I never asked for that. (Unless you think the variant of mbox in  
use could only specified if we had that specification, that is ... which  
would only underscore the gaping hole in the current document.)

(Note also that I didn't ask for any specific way of specifying the mbox  
variant - the regular expression proposal was someone else, and I'm not  
convinced it actually solves the problem.)

> represent a non-trivial layer violation.

That seems nonsensical. They're no more or less defining content rules  
than the media type itself is.

> They are analogous to using a
> instead of embedded clue data.

It seems well established that "embedded clue data" for mbox is not  
reliable, unless you involve a full AI.

In any case, I really don't see the qualitative difference between  
claiming "this is XHTML text" and "this is HTML 4.1 text", to pick a  
different example.

I think claims of "layer violation" are clearly - and obviously - wrong.  
There *is* no non-artificial layer boundary here. The boundary in question  
is completely arbitrary.

> Obviously, content agents should be aware
> determination?

Not without asking a human, it probably shouldn't. It's far too easy to  
get it wrong.

> that's where the logic belongs in the first place, so
> harmful.]

Attempting to automatically figure this out is the harmful version.  
Telling what it is is most certainly *NOT* harmful.

MfG Kai

---

From: Robert Elz <[email-masked]>
Date: Sat, 14 Aug 2004 21:04:59 +0700

Date:        Fri, 13 Aug 2004 11:33:18 -0400
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Others should note that RFC2048 is designed to facilitate registrations --
  | more definitions for common data-types are widely preferred over a
  | proliferation of "x-foo" media-types that result from high registration
  | barriers (read the intro to 2048 if you don't believe me) -- and that's
  | the limited objective of this proposal.

All that is fine, and not an issue with anyone.   The problem is that for
the tag to be meaningful, there must be at the very least a common
understanding of what it means and how it can be processed.   Better of
course is an actual published specification of the content format (somewhere).

Without that all you have is a label for a meaningless bucket of bits.

When I send a message how do I know whether it is appropriate to use the
new tag or not?   What content qualifies, and what does not?   Is it
sufficient if I'm sending a file whose name is "mbox"?   (Or which
has an extension of ".mbox" or similar).   Or is it necessary that the
content contain mail in some form?   If so, is it enough if I have a jpeg
file showing a mail box containing letters?

It is 100% useless to define a label without that referring to some
well understood content.

kre