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

From: Bruce Lilly <[email-masked]>
Date: Wed, 11 Aug 2004 20:06:46 -0400

The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider
> the
> following document:
> 
> - 'The APPLICATION/MBOX Media-Type '
>    <draft-hall-mime-app-mbox-02.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2004-09-06.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-hall-mime-app-mbox-02.txt
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

The draft mentions that "some form of external
     negotiation or prior agreement is often necessary in order to
     ensure that the contents of the database are accurately read by
     messaging systems on other hosts".

MIME provides for such mechanisms via the Content-Type field
parameters.  It would appear to be desirable to define at least
two parameter attributes for use with this media type, viz. one
defining the separator between messages (perhaps as a regular
expression), and another defining the line-ending sequence in use
(defaulting to CRLF).  Note that RFC 2231 provides mechanisms for
quoting and encoding parameter content, so that for example a lone
LF line-ending sequence could be encoded in the parameter value as
"%0A".

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

---

From: Tony Hansen <[email-masked]>
Date: Thu, 12 Aug 2004 17:18:19 -0400

The information about the mbox format being anecdotally defined is 
incorrect. The mbox format has traditionally been documented in the 
binmail(1) or mail.local(8) man pages (BSD UNIX derivatives) or mail(1) 
man page (UNIX System 3/5/III/V derivatives). There have been several 
variants of the mbox format in use by those different systems. The most 
complete description of an mbox format can be seen in the man page from 
any UNIX System Vr4 derived system, such as Solaris.

The description found in http://qmail.org./man/man5/mbox.html, referred 
to at the end of Appendix A, does cover these variations fairly 
succinctly. However Appendix A doesn't cover the variations properly.

	Tony Hansen
	[email-masked]

The IESG wrote:

> The IESG has received a request from an individual submitter to
> consider the following document:
>

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 12 Aug 2004 18:31:13 -0400

On 8/12/2004 5:18 PM, Tony Hansen wrote:

>  man page (UNIX System 3/5/III/V derivatives).

I checked each of those and none of them seem to adequately describe the
message or database format.

> The most complete description of an mbox format can be seen in the man
> page from any UNIX System Vr4 derived system, such as Solaris.
>

Do you have a specific URL to a specific man page that you think would be
appropriate and authoritative?

I spent a while looking (see also http://makeashorterlink.com/?X61D16909
for example), and couldn't find anything that seemed to be authoritative
enough to reference.

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

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 12 Aug 2004 17:12:18 -0600 (MDT)

> From: "Eric A. Hall" <[email-masked]>
> To: Tony Hansen <[email-masked]>

> appropriate and authoritative?

There are plenty of man pages and documentation for UNIX mbox formats.
Outfits such as Netscape have figured the stuff out (painfully simple
as it is) to make libraries to deal with local mailboxes.

However, that seems irrelevant unless an auuthority ceeds change control
for the UNIX mbox format to the IETF.  Never mind that the notion of
an authority that could exercise any authority over any UNIX mbox
format other than in its own source trees would be crazy.  There's no
law that says Dragonfly, NetBSD, FreeBSD, OpenBSD, Linux, IRIX, HP/UX,
AIX, etc. and so forth and so on must have a common mbox format or
that they cannot switch to something better, not withstanding things
like that Netscape library.  The old mbox formats are fine for a VAX-750
or 3B2, but are very bad ideas for more than a few hundred messages.

The most you could do is define your own interchange mbox format that
would by coincidence be extremely similar to one format such as the
System V or 4.3 BSD (I think I recall small differences between those
two), and tell implementors of your MIME type to convert into and out
of your format.

There is an overriding question.  Where is the market demand for
an IETF standards track RFC defining a UNIX mbox interchange type?
Who would use it?  
I can imagine "importing" and "exporting" mboxes, but not via SMTP.
Is anyone thinking about new code to convert among Netscape, Exchange,
and UNIX mbox mailboxes?  Doesn't enough of that code already exist,
and doesn't all of it use transport mechanisms other than SMTP?

Isn't the IETF supposed to be about on-the-wire bits and keep its
noses out of host data structures?

Vernon Schryver    [email-masked]

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 12 Aug 2004 20:10:13 -0400

> for example), and couldn't find anything that seemed to be authoritative

The docs/formats.txt file in the UW IMAP distribution
ftp://ftp.cac.washington.edu/mail/imap.tar.Z
describes several variants, some of which are not addressed
by the Bernstein document.  It also discusses a number of
interoperability issues not covered in the captioned draft.

As noted by Mark Crispin in the messages at the URL which you
have provided, different software can have somewhat different
interpretations of separator lines.  The only hope of having
any semblance of interoperability in exchanging such mbox
files between systems is to include an adequate specification
of the *specific* separator format used in the *particular*
file being transported (and I have suggested a regular
expression as a possible means of communicating that specification
via a Content-Type field parameter).

And I agree with Kai Henningsen's statement about use of
application/octet-stream; if there is not provision for
sufficient information (e.g. via parameters) to account for
the interoperability issues, then there's no point in having
a separate application subtype for it -- just use octet-stream
and let the communicating parties thrash out the details
out-of-band.  Or better yet (as briefly noted in the draft)
just use multipart/digest with local-system translations at
each end.

There are some additional issues that should be considered
(and either resolved or documented as known technical
omissions):
1. It is possible that processing by some transport (especially
   gateway) software may alter content which is not protected
   by transport encoding (and quoted-printable encoding might
   be insufficient).  That includes adding or removing trailing
   whitespace, modification of lines beginning with "From ", etc.
2. It is at best unclear how various software which uses one of
   the mbox format variants handles some 8bit and binary content,
   and indeed even 7bit content in MIME messages.  In particular,
   any attempt to convert line endings to/from the on-the-wire
   RFC [2]822 CRLF ending is likely to result in problems. For
   an example of binary content, see
   http://users.erols.com/blilly/mparse/tm35
   Note that the issue is not limited to binary content; "line
   ending" only has meaning in text media (not application, audio,
   image, video, model) and attempts at transforming non-text
   content (not merely text line endings, but e.g. content that
   happens to have <CR><LF>From<SP> in application, audio, etc.
   media) may irreversibly corrupt the content.

My opinion is that none of the mbox variants can handle the above
issues adequately.  Multipart/digest avoids the message separator
problem by using separators which are required not to be present
within the body of the message text in question.  Rigid formats
such as used by mbox variants are guaranteed to conflict with
some content at some point.  Some of the mbox variants appear
to have resulted from attempts to deal with various aspects of
the above and similar issues; the local storage methods that
appear to have the best chance of avoiding all of the problems
are those that use message-per-file storage in RFC [2]822
format (i.e. no attempt to convert line endings or otherwise
fold, spindle or mutilate message content) -- of course those
aren't "mbox" formats.

---

From: [email-masked]
Date: Fri, 13 Aug 2004 20:40:05 -0400

> any UNIX System Vr4 derived system, such as Solaris.

Umm.. Tony?  I hate to say it, but if there have been several variants used in
the wild, and the man pages for said variants document different formats,
that's awfully close to "anecdotally defined" when you're doing a standard.

For example, a Solaris 8 box across the hall says in 'man mail.local':

     Each delivered mail message in the mailbox is preceded by  a
     "Unix From line" with the following format:

          From sender_address time_stamp

     The sender_address  is  extracted  from  the  SMTP  envelope
     address  (the  envelope  address  is  specified  with the -f
     option).

     A trailing blank line is also added to the end of each  mes-
     sage.

Hmm. Nothing about whether the sender_address is, or should be, <bracketed>.
Nothing about the format of the time_stamp. Nothing about '>From ' stuffing
(and yes, I've seen systems that don't do it at all, and systems that only
>-stuff if the From line matched a regexp for what *they* think the entire 'From '
line looks like(*)). The Sendmail 8.13.1 mail.local does say >-stuffing
happens for lines that "which could be mistaken for a ``From '' delimiter
line", and the code actually checks for exactly 5 chars...

Any doubts that this whole mess is at best anecdotally defined can be dispelled by
mentioning "Content-Length:" (interestingly enough, not even mentioned in the
Solaris or Sendmail man pages, although the Sendmail source tree does mention
that building on Solaris 2.3 or later will turn it on.  Of interest mostly because
the Content-Length: is so easily broken by later >-stuffing/unstuffing or other
similar conversion...

(*) time_stamp. Argh.  Fought with this during a data/machine migration.
Write code that will accept a 26 byte ctime format: 'Fri Sep 13 00:00:00 1986\n\0'.
Works fine once you realize that some systems just used 'From envelop_address'
without a timestamp.

Then I get handed this: 'Fri Aug 13 20:21:32 EDT 2004'.  Fix that, and find some
joker running in a French locale: 'vendredi, 13 août 2004, 20:22:01 EDT'.
And yes, his b0rked software only >-stuffed 'From ' lines that regexp-matched
the *French* variant. Took me *quite* some time to twig into THAT one...

---

From: Tony Hansen <[email-masked]>
Date: Mon, 16 Aug 2004 22:47:52 -0400

> that's awfully close to "anecdotally defined" when you're doing a standard.

The claim in Appendix A is that there were no authoritative sources of 
documentation for the mbox formats and otherwise it's "only documented 
in anecdotal form". I'm sorry, but the the definitions ARE there, and 
ARE almost always authoritative for those systems.

This doesn't preclude there being other formats in the wild, nor does it 
preclude there being other tools on those same machines that conflict.

> ...

Because Solaris 8 is System Vr4-derived, you should look at 'man mail' 
for the definitive definition. You'll find Content-Length: documented there.

	Tony Hansen
	[email-masked]

---

From: [email-masked]
Date: Tue, 17 Aug 2004 13:05:27 -0400

> ARE almost always authoritative for those systems.

Somehow, I can't get thrilled by the concept of saying a format is documented
because we have (for example) 3 systems, and each has an authoritative
definition of the version it uses, and the definitions are incompatible (and
yes, the Solaris 'content-length:' scheme and '>from ' escaping are basically
incompatible - there exist messages that can't be converted from one to the
other without information loss).

> for the definitive definition. You'll find Content-Length: documented there.

It says:

     A letter is composed of some  header  lines  followed  by  a
     blank line followed by the message content. The header lines
     section of the letter consists of one  or  more  UNIX  post-
     marks:

           From     sender     date_and_time     [remote     from
          remote_system_name]

     followed by one or more standardized message header lines of
     the form:

           keyword-name: [printable text]

     where keyword-name  is  comprised  of  any  printable,  non-
     whitespace  characters  other  than  colon (`:'). A Content-
     Length: header line, indicating the number of bytes  in  the
     message  content  will  always  be present unless the letter
     consists of only header lines with  no  message  content.

For bonus points - is the 'crlf-crlf' between the header and the body included
in the Content-Length:?  There's other issues as well - what if the
Content-Length: is computed across a non-canonified message - how do
you send it across the wire?

'man mail' doesn't mention escaping a 'From ' inside a message,
except for this:

     The default mode for printing messages is  to  display  only
     those header lines of immediate interest. These include, but
     are not limited to,  the  UNIX  From  and  >From  postmarks,
     From:,  Date:,  Subject:,  and Content-Length: header lines,
     and any recipient header lines such as To:, Cc:,  Bcc:,  and
     so  forth.  After the header lines have been displayed, mail

Of course, that's because Solaris doesn't use '>From ' escaping
because it has Content-Length instead.

Should other systems trust the value of a Content-Length:?

Should other systems be required to include a Content-Length?

Should other systems escape a 'From ' iff there's no Content-Length?

What if an mbox file has a Content-Length on some items but not others?

How do you recover from a corrupted Content-Length?

So - where is the *one true canonical* definition of an mbox that actually
answers all these basic questions that an implementer *needs* to know the
answer to?

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2004 14:09:34 -0400

--On Tuesday, 17 August, 2004 13:05 -0400
[email-masked] wrote:

>...
> So - where is the *one true canonical* definition of an mbox
> that actually answers all these basic questions that an
> implementer *needs* to know the answer to?

Or, as an alternative, where is the set of required parameters
and values that would give the recipient at least a strong clue
as to which of many definitions and variations is in use?

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.   It is the responsibility
	of the sender to get from whatever is used locally into
	that form and the responsibility of the recipient to get
	from that form into whatever is needed locally.  And the
	wire format is precisely defined, without handwaving or
	system-specific variations.
	
	(2) The content-type specifies a conceptual form
	("application/mbox") but has _required_ parameters that
	specify the specific form being transmitted.  The
	recipient does not require either out of band
	information or heuristics on the body part content
	itself to figure out what was received and whether local
	facilities exist to decode it.
	
	(3) These might as well be sent with
	application/octet-stream, with optional file name, etc.,
	information.

I just don't see any other options that are consistent with the
media type model.

     john

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 17 Aug 2004 15:09:07 -0400

On 8/17/2004 2:09 PM, John C Klensin wrote:

> 	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", because that's where we'd end up after monhts of
beating on each other.

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.

> 	specify the specific form being transmitted.

Global parameters are useless if the parser is intelligent enough to
figure out the message structure independently. Given that such
intelligence is a prerequisite to having a half-baked parser, the global
parameters are always unnecessary.

Actually, global parameters are more than useless. What if we have a mixed
mbox file, where some messages are untagged BIG5 and others are untagged
8859-1, or we have some messages have VMS::Mail addresses and others have
MS/Mail addresses, or so forth? The global nature of global parameters
ignores the per-message reality of the mbox structure.

Global parameters can also be harmful if they conflict with reality.

> 	application/octet-stream, with optional file name, etc.,

That's where we are now and we already now that's not working.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2004 16:06:03 -0400

--On Tuesday, 17 August, 2004 15:09 -0400 "Eric A. Hall"
<[email-masked]> wrote:

>> To be clear about this, I think there are three choices which
>> we might prefer in descending order:
>> 
> 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",
> because that's where we'd end up after monhts of beating on
> each other.
>...
> Global parameters are useless if the parser is intelligent
> enough to figure out the message structure independently.
> Given that such intelligence is a prerequisite to having a
> half-baked parser, the global parameters are always
> unnecessary.

This is a minor point compared to the one below, and probably
not an issue here, but I can't let the above stand.  My
impression of the MIME design, from the beginning, was that I
should be able to inspect the content-type --including both the
primary type and any parameters-- before deciding whether to
retrieve and open the content of the body part.  Yes, we have
implementations and protocols that don't take advantage of that,
or that can take advantage of the content-type only and not the
parameters, but the MIME design, and hence the media type
design, is that I should be able to tell whether I can parse
(see below) the body part without opening it and applying
heuristics to it.

In addition, what you seem to mean by "intelligent enough to
figure out the message structure independently" is what I would
mean if I said "know most or all of the formats and apply
heuristics to figure out which one to apply".  We just don't do
that, at least knowingly and with standards-track media types.
You might rationally argue that this should be an exception if
you could demonstrate that a reasonable set of heuristics would
_always_ make the choice correctly, but that would require you
to document either the heuristics or all of the variations on
mbox and how to tell them apart (or both) -- something that
several people have claimed is basically impossible and that you
clearly haven't expressed a desire to do.

In that context, unless I completely misunderstand what is going
on here, the "...prerequisite to having a half-baked parser..."
assertion borders on the silly.   Take the example to which Tony
has been pointing.  Apparently the Solaris version of an mbox
format is well-documented and based on content length
information rather than key strings.   That implies that, if (i)
I know that what is coming is in that Solaris format and (ii) I
have a rather primitive parser that knows how to find and deal
with content lengths, then I can parse the format without any
ability to "figure out the structure" at all.   However, if I
attempt to apply that parser to something to uses key strings,
rather than lengths, or something that violates the assumptions
Solaris makes about what gets included in the length
computations, the parser is going to be bewildered at best and
yield silly results at worst -- and that is exactly what content
types and their parameters are intended to let receiving
applications guard against.

> Actually, global parameters are more than useless. What if we
> have a mixed mbox file, where some messages are untagged BIG5
> and others are untagged 8859-1, or we have some messages have
> VMS::Mail addresses and others have MS/Mail addresses, or so
> forth? The global nature of global parameters ignores the
> per-message reality of the mbox structure.
> 

That brings us to the main problem, or misunderstanding, or
strawman, depending on one's perspective.

I may be being excessively dense here, but, if I am, I seem to
have significant company.   I am not asking (or suggesting) that
you provide the information that would be required for
multipart/, e.g., the content-type and associated parameters
(such as charset, for your examples above) for each message
(much less, for multipart/digest, that you force everything into
the required subset of an RFC822 message body).  While I have
concerns that we didn't get multipart quite right and that it is
too late to fix it, those concerns don't interact with my
concern about application/mbox at all.

So let's move back a half-step.  To me, the essence of the mbox
format, conceptually, is that it consists of a sequence of blobs
that are normally interpreted as messages in some format or
other. You've made several convincing arguments that we should
see them as blobs, not as messages, and I (and I think others)
accepted them long ago.   I think that such a blob collection is
a reasonable thing to want to mail or otherwise use as a media
type.  And, again, I accept your argument that the blobs may not
be valid 822/2822 messages or encapsulated 2821 messages, and,
indeed, that there may be considerable format and content
heterogeneity from one blob to the next. 

Given that model, the key to an mbox format isn't the content of
the blobs, it is the system used to decompose an mbox into a
blob collection.  If this were a multipart structure, the
corresponding issue of interest would be whether the Boundary
parameter provided enough information to separate the parts.  It
would not be what was in each of the parts or even what _their_
content types were.  It would simply be the ability to separate
the aggregate mbox into separate blobs.

If I know that blobs are length-delimited according to some
specific set of rules, I have that information and can build a
trivial parser (and understand what it can't handle).   If I
know they are separated by indicator strings that obey some
specific set of rules, then I can build a trivial parser (and
understand what it can't handle).  And so on for different sets
of rules.   But, as far as I can tell, you don't want to give us
that information.  Instead, you want us to accept "well, it is
some sort of mbox format, and you either need to guess at how to
separate the blobs by examining the content or you need to get
that information out of band".   If that is what you intend this
specification to imply, IMnvHO, unacceptable for a
standards-track media type.

Finally, if you argue that global parameters are unacceptable as
a means of making the type of format/ de-blob-ing distinctions
outlined below, I suggest that you are not making a good case
for leaving the parameters (and associated information) out.
Instead, you are making a case that this registration should be
a family of, e.g.,
  application/mbox-solaris-v5-and-later
  application/mbox-sendmail-v2-v4
and similar things (examples made up).

       john

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 17 Aug 2004 16:53:22 -0400

On 8/17/2004 4:06 PM, John C Klensin wrote:

> information rather than key strings.

... it is well-defined for writing, but AFAIK the number of reliable
clients that depend on the presence of such data are zero.

This is the point really: Given that the database structure really is
undefined, and that any number of clients may have accessed the database
via ~NFS or via different mailers on the same local client (Pine and KMail
and ...), a half-baked mailer that wants to reliably read mbox data of any
kind will know better than to rely on Content-Length in isolation, and
will have to validate assumptions and check the clues before doing
anything substantive. This includes checking for EOL syntaxes, but also
includes things like default charsets for untagged data, default domains,
and so forth.

> blob collection.

That's a function of the content parser and whatever task it is trying to
perform. The purpose of importing an mbox database into an IMAP store (as
is common with things like downloadable archives) is going to have several
different considerations and requirements than simple searching and
printing (as with local archives generated by ~Mozilla locally), but both
of them can be satisfied through basic sniff tests and local defaults.

Most of the spec work is appropriate and useful and arguably necessary for
*writing* to mbox files, especially if you are appending an existing file,
but even then it takes few smarts to figure out that you should write to
the existing content instead of druidic rules. Having said that, I'd love
to see a canonical authoritative format which could be referenced for such
purposes (not for transfers, but for parsers to use when they go about
generating content).

>   application/mbox-sendmail-v2-v4

I hope not; unrecognized types match to application/octet-stream so many
types that nobody implements won't get us very far either.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Aug 2004 17:38:52 -0700

John,

>> half-baked parser, the global parameters are always

JCK> This is a minor point compared to the one below, and probably
JCK> not an issue here, but I can't let the above stand.

Actually, I suspect you (and we) can and should.

A draft has been presented.  Numerous objections from experienced folks
have been lodged.  Is there more productive discussion likely?

This thread has not looked all that productive from the start and I am
hard-pressed to see how that is going to change.  Certainly countering
arguments about the benefits of standards for labeling, semantics, and
the like is not likely to convince anyone.  If they don't see it, the
only real question is what they are doing in this venue.

Now, the real reason for my posting:  If someone can summarize where
this thread is going and/or should go, I'd appreciate it.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Aug 2004 22:57:46 -0400

On Aug 17, 2004, at 8:38 PM, Dave Crocker wrote:

>  If someone can summarize where

my recommendation to the author -

- do another edit on the draft, mostly for nits and clarity, and 
resubmit for Informational

- don't try to specify the application/mbox format in this document at 
all.  instead, point to various published definitions and descriptions 
(man pages, web pages, whatever) such as exist.

- for that matter, don't try to specify how best to generate mbox 
files.  that's out of scope.

- explicitly point out that there are varieties in how the format has 
been implemented which can affect interoperability.  (this should not 
be a showstopper, as there are varieties in how almost any other 
MIME-labeled format is implemented which can affect interoperability.)

- my preference is to not have parameters describing format variants at 
all, as they're highly unlikely to be used correctly and even less 
likely to be generated correctly.  if you must have parameters, make 
them optional.

- you might want to point out that a wide variety of mbox-reading tools 
generally manage to make sense of mbox files despite the variations.  
and yes, they barf sometimes.  some implementations' heuristics are 
better than others.  again, this is also true of Word, PDF, JPEG, 
PostScript, or any other format you could care to look at.  it's useful 
to be able to distinguish mbox files from other kinds of files, even if 
saying something is an mbox file is not perfectly precise.

- point out that the existence of an application/mbox label is not a 
recommendation that mbox files be used to transport groups of messages 
-  at least, not without first defining a new variant of mbox files 
that is transparent (no >From), reliable (no message boundary 
synchronization errors),  immune to variations in line terminator, and 
doesn't use character or line counts (no content-length).

- recommend base64 encoding as a default for transport of mbox files 
over email, since the encoder typically has no idea about the message 
contents and whether they might contain binary data.

my recommendation to everyone else -

let's wait for the revision and look at it then.  meanwhile, let's 
realize

- that having a way to label mbox fiiles is much more useful than not 
having one;

- that perfectly precise labels for anything are almost nonexistent in 
practice;

- that having an imprecise MIME label for mbox files probably won't 
degrade interop significantly over what it already is

- that there are probably better uses of our time (individually or 
collectively) than to define the perfect label for mbox files.

Keith

---

From: John C Klensin <[email-masked]>
Date: Wed, 18 Aug 2004 00:13:40 -0400

--On Tuesday, 17 August, 2004 17:38 -0700 Dave Crocker
<[email-masked]> wrote:

> JCK> This is a minor point compared to the one below, and
> probably JCK> not an issue here, but I can't let the above
> stand.
> 
> 
> A draft has been presented.  Numerous objections from
> experienced folks have been lodged.  Is there more productive
> discussion likely?
> 
> This thread has not looked all that productive from the start
> and I am hard-pressed to see how that is going to change.
> Certainly countering arguments about the benefits of standards
> for labeling, semantics, and the like is not likely to
> convince anyone.  If they don't see it, the only real question
> is what they are doing in this venue.
> 
> Now, the real reason for my posting:  If someone can summarize
> where this thread is going and/or should go, I'd appreciate it.

Well, I had planned to just stop after that note, on the theory
that the IESG should now have enough information to make
whatever decision they are inclined to make.   My personal
recommendation, I trust obviously, is that they should say "no"
to this particular draft as a proposed standard: for
standardization purposes, it just isn't specific enough about
what is being transmitted.

If I were giving advice to the author, it would pretty closely
follow what I understand Keith to be suggesting.   Withdraw this
document and the request that it be considered for PS.  Generate
a new document that is very specific about how much or how
little can be assumed when something arrives with this content
type, makes it explicit that the receiver had better be prepared
to handle any of the various mbox forms, and points to whatever
documentation or other materials that can be easily identified
and might help in constructing a receiver-processor.   I think
that document should be Informational, with a media type in some
non-IETF tree, but could personally live with a Proposed
Standard if the interoperability constraints, and any security
risks from guessing wrong about properties of the format were
extremely explicit.

Does that agree with your analysis, at least to a first order
approximation?

    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Aug 2004 21:20:34 -0700

John,

JCK> Does that agree with your analysis, at least to a first order
JCK> approximation?

  well (harumph!) i can't let the question stand without answering it...

  I trust the assessments you folks have been making about the document,
  and I have not seen counter-arguments that looked at all persuasive.

  I also have not read the spec.
  
d/

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 18 Aug 2004 09:43:03 -0400

Eric A. Hall wrote:
> "use multipart/digest"

So far, so good.

> 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.

> 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?

---

From: [email-masked]
Date: Thu, 19 Aug 2004 00:43:24 -0700 (PDT)

Keith, very nicely put. I am in complete agreement with everything you
say here.

				Ned