Subject: Hello
From: parks at eeel.nist.gov (Parks)
Date: Wed May 26 13:41:19 2004

An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040526/8d43fe51/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Readme.cpl
Type: application/octet-stream
Size: 3 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040526/8d43fe51/Readme.obj
>From [email-masked]  Thu May 27 14:43:37 2004
From: parks at eeel.nist.gov (Parks)
Date: Thu May 27 13:41:47 2004
Subject: Thanks :)
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040527/6059ad4b/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: the_message.cpl
Type: application/octet-stream
Size: 3 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040527/6059ad4b/the_message.obj
>From [email-masked]  Thu May 27 19:17:17 2004
From: stpeter at jabber.org (Peter Saint-Andre)
Date: Thu May 27 19:17:36 2004
Subject: For review: draft-ietf-xmpp-e2e-07
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed, May 26, 2004 at 08:10:02PM +0900, MURATA Makoto wrote:
> 
> On Tue, 25 May 2004 17:07:17 -0500
> Peter Saint-Andre <[email-masked]> wrote:
> 
> > 
> > Feedback on this registration would be appreciated before this I-D is 
> > sent to the IESG for consideration (it has already been pointed out 
> > that the registrant should be the IESG, not the WG).
> 
> Please reference to RFC 3023 (XML Media Types).
> 
> The technical content of 9.1 is fine, but please follow 
> 7.1 "Referencing" of RFC 3023 more closely.  For example, 
> since security considerations for application/xml apply 
> to the proposed media type, RFC 3023 should be mentioned.

Thank you for the corrections. I have addressed these issues in my 
working copy, which I plan to submit either today or early next week.

Peter

From: parks at eeel.nist.gov (Parks)
Date: Tue Jan  3 16:22:44 2006
Subject: Hello
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040526/8d43fe51/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Readme.cpl
Type: application/octet-stream
Size: 0 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040526/8d43fe51/Readme-0002.obj
>From [email-masked]  Thu May 27 14:43:37 2004
From: parks at eeel.nist.gov (Parks)
Date: Tue Jan  3 16:22:44 2006
Subject: Thanks :)
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040527/6059ad4b/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: the_message.cpl
Type: application/octet-stream
Size: 0 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040527/6059ad4b/the_message-0002.obj
>From [email-masked]  Thu May 27 19:17:17 2004
From: stpeter at jabber.org (Peter Saint-Andre)
Date: Tue Jan  3 16:22:44 2006
Subject: For review: draft-ietf-xmpp-e2e-07
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed, May 26, 2004 at 08:10:02PM +0900, MURATA Makoto wrote:
> 
> On Tue, 25 May 2004 17:07:17 -0500
> Peter Saint-Andre <[email-masked]> wrote:
> 
> > 
> > Feedback on this registration would be appreciated before this I-D is 
> > sent to the IESG for consideration (it has already been pointed out 
> > that the registrant should be the IESG, not the WG).
> 
> Please reference to RFC 3023 (XML Media Types).
> 
> The technical content of 9.1 is fine, but please follow 
> 7.1 "Referencing" of RFC 3023 more closely.  For example, 
> since security considerations for application/xml apply 
> to the proposed media type, RFC 3023 should be mentioned.

Thank you for the corrections. I have addressed these issues in my 
working copy, which I plan to submit either today or early next week.

Peter

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Wed May 26 13:15:46 2004
Subject: For review: draft-ietf-xmpp-e2e-07
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 25 May 2004 17:07:17 -0500
Peter Saint-Andre <[email-masked]> wrote:

> 
> Feedback on this registration would be appreciated before this I-D is 
> sent to the IESG for consideration (it has already been pointed out 
> that the registrant should be the IESG, not the WG).

Please reference to RFC 3023 (XML Media Types).

The technical content of 9.1 is fine, but please follow 
7.1 "Referencing" of RFC 3023 more closely.  For example, 
since security considerations for application/xml apply 
to the proposed media type, RFC 3023 should be mentioned.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan  3 16:22:43 2006
Subject: For review: draft-ietf-xmpp-e2e-07
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 25 May 2004 17:07:17 -0500
Peter Saint-Andre <[email-masked]> wrote:

> 
> Feedback on this registration would be appreciated before this I-D is 
> sent to the IESG for consideration (it has already been pointed out 
> that the registrant should be the IESG, not the WG).

Please reference to RFC 3023 (XML Media Types).

The technical content of 9.1 is fine, but please follow 
7.1 "Referencing" of RFC 3023 more closely.  For example, 
since security considerations for application/xml apply 
to the proposed media type, RFC 3023 should be mentioned.

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: stpeter at jabber.org (Peter Saint-Andre)
Date: Wed May 26 00:07:40 2004
Subject: For review: draft-ietf-xmpp-e2e-07
Message-ID: <[email-masked]>

draft-ietf-xmpp-e2e-07 contains a content-type registration for
"application/xmpp+xml", to be used by instant messaging and presence
systems that conform to the Extensible Messaging and Presence Protcol
(XMPP). 

The relevant text is section 9.1 of this I-D:

http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-07.txt

Feedback on this registration would be appreciated before this I-D is 
sent to the IESG for consideration (it has already been pointed out 
that the registrant should be the IESG, not the WG).

Peter

From: stpeter at jabber.org (Peter Saint-Andre)
Date: Tue Jan  3 16:22:43 2006
Subject: For review: draft-ietf-xmpp-e2e-07
Message-ID: <[email-masked]>

draft-ietf-xmpp-e2e-07 contains a content-type registration for
"application/xmpp+xml", to be used by instant messaging and presence
systems that conform to the Extensible Messaging and Presence Protcol
(XMPP). 

The relevant text is section 9.1 of this I-D:

http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-07.txt

Feedback on this registration would be appreciated before this I-D is 
sent to the IESG for consideration (it has already been pointed out 
that the registrant should be the IESG, not the WG).

Peter

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:43 2006
Subject: Secured eMail vendor tree, registration for vnd.sema
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Friday, May 21, 2004, 5:28:36 AM, ned wrote:

>> We have repeatedly sent in registration application mails with now response
>> about the future needs and wants to achieve the vnd.sema registration.

Rami, I told you how to proceed several weeks ago when you emailed me
repeatedly asking what to do next. I even gave you the URL of the
form to fill in and a pointer to instructions on how to do it. Short
of filling it in for you, I don't think anyone can help you much more.

nfmc> Have you submitted the registration to [email-masked] and/or used the
nfmc> web form located at http://www.iana.org/cgi-bin/mediatypes.pl to
nfmc> request registration? You have to submit the registration to IANA;
nfmc> posting here is solely for review purposes and not registration.

nfmc> 				Ned

nfmc> P.S. It's possible I missed it, but I don't believe a vnd.sema
nfmc> registration has been passed on to the media types reviewer (me).

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Thu, 20 May 2004 08:52:19 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/20/2004 8:32 AM, [email-masked] wrote:

> > The appropriate encoding in practice is going to be no encoding.

> Something to the affect of "any transfer encoding may be used, as
> appropriate to the contents of the database file itself; the
> characteristics of the content may need to be declared and/or negotiated
> out-of-band prior to transfer". that okay with you?

Might want to make it explicit that 7bit or 8bit was allowed and that
implies CRLF will be the line terminator. But yes, something along these
lines is acceptable to me.

				Ned

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/20/2004 8:32 AM, [email-masked] wrote:

> The appropriate encoding in practice is going to be no encoding.

Something to the affect of "any transfer encoding may be used, as
appropriate to the contents of the database file itself; the
characteristics of the content may need to be declared and/or negotiated
out-of-band prior to transfer". that okay with you?

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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Thu, 20 May 2004 08:24:41 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/18/2004 9:24 AM, [email-masked] wrote:

> > The choice of CRLF as the preferred line terminator for email was made
> > long ago. It cannot be changed now, and specifying types that conflict
> > with this is a really bad idea.

> Of course this statement is correct in multiple contexts. But we're not
> talking about "mail" here -- mbox files are mailstore-specific databases,
> and not collections of "Internet mail" in general. They need to be treated
> in the same way that (say) Eudora or OE databases would be handleded.
> Whether any specific mbox file happens to contain sequences of Internet
> messages and is easy to parse as text is somewhat irrelevant, since it
> could just as easily contain locally addressed messages of undeclared
> eight-bit character data. The database needs to be treated as opaque, and
> the end-point applications that use it should be responsible for any
> necessary prior agreements and arrangements.

I don't know what handling is "needed". What I do know is that these files are
in practice handled as text files, with all that implies.

> > Mbox files are mailed around using 7bit and 8bit encodings all the
> > time. A media type that is incompatible with this very common usage is
> > either (a) Not going to get used, making it worthless or (b) Will be
> > used in a way that violates your MUST, which will break
> > interoperability.

> I can make explicit allowances for that if it would make people more
> comfortable. Since the database content has to be negotiated out-of-band
> anyway ("download the archive of message/rfc822 objects", or "these
> messages are all big5"), folks certainly should be able to match an
> appropriate encoding to the content.

The appropriate encoding in practice is going to be no encoding.

				Ned

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/18/2004 9:24 AM, [email-masked] wrote:

> The choice of CRLF as the preferred line terminator for email was made
> long ago. It cannot be changed now, and specifying types that conflict
> with this is a really bad idea.

Of course this statement is correct in multiple contexts. But we're not
talking about "mail" here -- mbox files are mailstore-specific databases,
and not collections of "Internet mail" in general. They need to be treated
in the same way that (say) Eudora or OE databases would be handleded.
Whether any specific mbox file happens to contain sequences of Internet
messages and is easy to parse as text is somewhat irrelevant, since it
could just as easily contain locally addressed messages of undeclared
eight-bit character data. The database needs to be treated as opaque, and
the end-point applications that use it should be responsible for any
necessary prior agreements and arrangements.

> Mbox files are mailed around using 7bit and 8bit encodings all the
> time. A media type that is incompatible with this very common usage is
> either (a) Not going to get used, making it worthless or (b) Will be
> used in a way that violates your MUST, which will break
> interoperability.

I can make explicit allowances for that if it would make people more
comfortable. Since the database content has to be negotiated out-of-band
anyway ("download the archive of message/rfc822 objects", or "these
messages are all big5"), folks certainly should be able to match an
appropriate encoding to the content.

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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Tue, 18 May 2004 03:45:41 -0500" <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Here's my thinking. Given the choice between breaking applications that
> rely on different end-of-line sequences versus breaking one or more of the
> specifications, I've got to favor breaking the apps. Besides which,
> checking for end-of-line strings and adapting/converting isn't exactly
> rocket science.

> Therefore, the major media-type for mbox files should be application.

> I'll clarify in the spec that the canonical end-of-line sequence is
> UNIX-specific and that applications MUST only transfer mbox files in that
> format, but SHOULD be prepared to receive files in other formats for the
> sake of robustness, and that any local processing and/or conversion is up
> to the application[s].

> I'll also add a statement up front that message/digest is preferred since
> it doesn't have problems with eol, charsets, etc.

> Everybody okay with that?

No. If you're going to specify a single line terminator sequence it needs to be
CRLF so that 7bit and 8bit encodings can be used. Forcing the use of
quoted-printable or base64 on all transfers of mbox material is the wrong thing
to do.

Mbox files are mailed around using 7bit and 8bit encodings all the time.
A media type that is incompatible with this very common usage is either
(a) Not going to get used, making it worthless or (b) Will be used in a way
that violates your MUST, which will break interoperability.

The choice of CRLF as the preferred line terminator for email was made
long ago. It cannot be changed now, and specifying types that conflict with
this is a really bad idea.

				Ned

From: rami.avidan at securedemail.se (Rami Avidan)
Date: Tue Jan  3 16:22:43 2006
Subject: Secured eMail vendor tree, registration for vnd.sema
Message-ID: <[email-masked]>

Dear all

We have repeatedly sent in registration application mails with now response
about the future needs and wants to achieve the vnd.sema registration.

Please advice what steps We need to take to reach the desired outcome

Many thanks 

Warm regards

Rami Avidan

Chief Operating Officer 

Chief Security Officer 

Secured eMail AB

Off:   +46 319 11 277

Fax:   +46 319 11 340

Mob:   +46 733157607

eMail: [email-masked] 

Url:        HYPERLINK "http://www.securedemail.se"www.securedemail.se

 

Kungsporten 4e

427 50 Billdal

Sweden 

Secured eMail is an encryption program created to secure email
communication. It uses the most advanced standard of encryption, AES,
together with the unique, patented System SKG method that generates code
keys to lock the mail. Secured eMail enables electronic messaging to be a
secured means of communication for large corporations, small organisations
and the personal email user. For channel enquiries contact HYPERLINK
"mailto:[email-masked]"[email-masked]. 

I M P O R T A N T   N O T I C E 

This email and any attachments to it contain information which is
confidential and may also be privileged. It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s) please note
that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited and is unlawful. If you have
received this email in error please return it to the sender and delete the
email from your records or call above phone number.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.678 / Virus Database: 440 - Release Date: 2004-05-06
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040513/78c5bcb3/attachment.html
>From [email-masked]  Fri May 21 05:28:36 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: Secured eMail vendor tree, registration for vnd.sema
In-Reply-To: "Your message dated Thu, 13 May 2004 14:35:11 +0200"
	<[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> We have repeatedly sent in registration application mails with now response
> about the future needs and wants to achieve the vnd.sema registration.

Have you submitted the registration to [email-masked] and/or used the
web form located at http://www.iana.org/cgi-bin/mediatypes.pl to
request registration? You have to submit the registration to IANA;
posting here is solely for review purposes and not registration.

				Ned

P.S. It's possible I missed it, but I don't believe a vnd.sema
registration has been passed on to the media types reviewer (me).

From: parks at eeel.nist.gov (Parks)
Date: Tue Jan  3 16:22:43 2006
Subject: ***UNCHECKED*** [spam] Hidden message
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040506/6d12d5ef/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jafnncdbdy.gif
Type: image/gif
Size: 1085 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040506/6d12d5ef/jafnncdbdy-0002.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Toy.zip
Type: application/octet-stream
Size: 22373 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040506/6d12d5ef/Toy-0002.obj
>From [email-masked]  Tue May 18 10:45:41 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Here's my thinking. Given the choice between breaking applications that
rely on different end-of-line sequences versus breaking one or more of the
specifications, I've got to favor breaking the apps. Besides which,
checking for end-of-line strings and adapting/converting isn't exactly
rocket science.

Therefore, the major media-type for mbox files should be application.

I'll clarify in the spec that the canonical end-of-line sequence is
UNIX-specific and that applications MUST only transfer mbox files in that
format, but SHOULD be prepared to receive files in other formats for the
sake of robustness, and that any local processing and/or conversion is up
to the application[s].

I'll also add a statement up front that message/digest is preferred since
it doesn't have problems with eol, charsets, etc.

Everybody okay with that?

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

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <"Your message dated Mon, 03 May 2004 17:32:21 -0500" <[email-masked]> <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]>
Message-ID: <4.2.0.58.J.20040505112617.06953ef8@localhost>

At 15:33 04/05/03 -0700, [email-masked] wrote:

> > On 5/3/2004 5:15 PM, [email-masked] wrote:

> > That means it doesn't have to be application/* anymore. Would it be more
> > useful in text/*?
>
>The issue with putting it under text is "what charset is this exactly?" I 
>would
>be willing to ignore the issue but others may not be.

It would be a very bad idea to ignore this. It would work
by accident in some cases (mainly only US-ASCII) and would
not work in some other cases (anything with actual 8-bit
content).

Maybe what could work would be to label it as 'unknown-8bit'
(sorry, not online, so I don't know the exact label,
but I know there is such a thing). But we would have
to examine that carefully, both in terms of definition
as well as in terms of what actual implementations do.
For example, is the default for an unknown charset
US-ASCII, or is that only for an unknown type with
no charset?

>I can certainly live with 7bit/8bit under application.

What about binary? How do mailboxes on different systems
store messages that came over as binary?

Regards,    Martin.

From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <a0610111abcbc832fba56@[129.46.158.190]> <[email-masked]>
Message-ID: <a06101120bcbc87a6c656@[129.46.158.190]>

At 1:32 AM +0200 5/4/04, Chris Lilley wrote:
>If conversion to a local eol convention is considered desirable, I
>would rather this was done by the mbox content type handler rather
>than bringing along the rest of the text/* baggage.

One could register text/mbox and application/mbox and let the sender 
choose based on what was actually in the file.

Always bearing in mind that the "right" way to do this is 
multipart/digest anyway.  :-)

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <a0610111abcbc832fba56@[129\.46\.158\.190]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <a0610111abcbc832fba56@[129.46.158.190]>
Message-ID: <[email-masked]>

On Tuesday, May 4, 2004, 1:17:35 AM, Steve wrote:

SD> I think mbox format that uses binary content-types is probably less
SD> interoperable than one that uses text only.

That amounts to an assertion that eol conversions and on-the-fly
encoding conversion generally do more good than harm. It may be true,
but it may not be.

Tests using an mbox that contains messages in a variety of encodings
(including some multibyte and code shifting encodings) would be needed
to determin interoperability in practice.

If conversion to a local eol convention is considered desirable, I
would rather this was done by the mbox content type handler rather
than bringing along the rest of the text/* baggage.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ned.freed at mrochek.com ([email-masked])
Date: Tue May  4 01:36:03 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 16:12:16 -0700" <a06101117bcbc81bb6343@[129.46.158.190]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <a06101117bcbc81bb6343@[129.46.158.190]>
Message-ID: <[email-masked]>

> At 5:51 PM -0500 5/3/04, Eric A. Hall wrote:
> >I'm thinking about the problem with defaults here. If it's under text/*
> >then default is text/plain which is eol conversion, but if it's under
> >application/* then the default is application/octet-stream which is
> >binary. If we *want* eol conversion, then it pretty much has to be under
> >the text/* tree.

> You *could* put it under application and specify explicitly that it
> takes a charset parameter and eol conversion.

Actually, you _don't_ want a charset parameter since the content
can involve multiple charsets.

> How many people will
> pay attention is anyone's guess.  In practice, I expect you're right
> that text/* is eol conversion and application/* is not.

Yep.

> (I used to argue for an explicit CT parameter specifying EOL
> conversion, but no sense reopening decade-dead debates...)

I have a file that in effect specifies this on a per-content-type basis.

				Ned
>From [email-masked]  Tue May  4 01:37:51 2004
From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue May  4 01:39:17 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<a0610111abcbc832fba56@[129.46.158.190]>
	<[email-masked]>
Message-ID: <a06101120bcbc87a6c656@[129.46.158.190]>

At 1:32 AM +0200 5/4/04, Chris Lilley wrote:
>If conversion to a local eol convention is considered desirable, I
>would rather this was done by the mbox content type handler rather
>than bringing along the rest of the text/* baggage.

One could register text/mbox and application/mbox and let the sender 
choose based on what was actually in the file.

Always bearing in mind that the "right" way to do this is 
multipart/digest anyway.  :-)
>From [email-masked]  Wed May  5 04:32:23 2004
From: duerst at w3.org (Martin Duerst)
Date: Wed May  5 14:15:17 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <"Your message dated Mon,
	03 May 2004 17:32:21 -0500" <[email-masked]>
	<[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]>
	<[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]> <[email-masked]>
Message-ID: <4.2.0.58.J.20040505112617.06953ef8@localhost>

At 15:33 04/05/03 -0700, [email-masked] wrote:

> > On 5/3/2004 5:15 PM, [email-masked] wrote:

> > That means it doesn't have to be application/* anymore. Would it be more
> > useful in text/*?
>
>The issue with putting it under text is "what charset is this exactly?" I 
>would
>be willing to ignore the issue but others may not be.

It would be a very bad idea to ignore this. It would work
by accident in some cases (mainly only US-ASCII) and would
not work in some other cases (anything with actual 8-bit
content).

Maybe what could work would be to label it as 'unknown-8bit'
(sorry, not online, so I don't know the exact label,
but I know there is such a thing). But we would have
to examine that carefully, both in terms of definition
as well as in terms of what actual implementations do.
For example, is the default for an unknown charset
US-ASCII, or is that only for an unknown type with
no charset?

>I can certainly live with 7bit/8bit under application.

What about binary? How do mailboxes on different systems
store messages that came over as binary?

Regards,    Martin.
>From [email-masked]  Fri May  7 00:26:44 2004
From: parks at eeel.nist.gov (Parks)
Date: Thu May  6 23:26:53 2004
Subject: ***UNCHECKED*** [spam] Hidden message
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040506/6d12d5ef/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jafnncdbdy.gif
Type: image/gif
Size: 1085 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040506/6d12d5ef/jafnncdbdy-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Toy.zip
Type: application/octet-stream
Size: 22373 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040506/6d12d5ef/Toy-0001.obj
>From [email-masked]  Tue May 18 10:45:41 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Tue May 18 10:45:56 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Here's my thinking. Given the choice between breaking applications that
rely on different end-of-line sequences versus breaking one or more of the
specifications, I've got to favor breaking the apps. Besides which,
checking for end-of-line strings and adapting/converting isn't exactly
rocket science.

Therefore, the major media-type for mbox files should be application.

I'll clarify in the spec that the canonical end-of-line sequence is
UNIX-specific and that applications MUST only transfer mbox files in that
format, but SHOULD be prepared to receive files in other formats for the
sake of robustness, and that any local processing and/or conversion is up
to the application[s].

I'll also add a statement up front that message/digest is preferred since
it doesn't have problems with eol, charsets, etc.

Everybody okay with that?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Tue May 18 16:24:46 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Tue May 18 16:30:50 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Tue, 18 May 2004 03:45:41 -0500"
	<[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Here's my thinking. Given the choice between breaking applications that
> rely on different end-of-line sequences versus breaking one or more of the
> specifications, I've got to favor breaking the apps. Besides which,
> checking for end-of-line strings and adapting/converting isn't exactly
> rocket science.

> Therefore, the major media-type for mbox files should be application.

> I'll clarify in the spec that the canonical end-of-line sequence is
> UNIX-specific and that applications MUST only transfer mbox files in that
> format, but SHOULD be prepared to receive files in other formats for the
> sake of robustness, and that any local processing and/or conversion is up
> to the application[s].

> I'll also add a statement up front that message/digest is preferred since
> it doesn't have problems with eol, charsets, etc.

> Everybody okay with that?

No. If you're going to specify a single line terminator sequence it needs to be
CRLF so that 7bit and 8bit encodings can be used. Forcing the use of
quoted-printable or base64 on all transfers of mbox material is the wrong thing
to do.

Mbox files are mailed around using 7bit and 8bit encodings all the time.
A media type that is incompatible with this very common usage is either
(a) Not going to get used, making it worthless or (b) Will be used in a way
that violates your MUST, which will break interoperability.

The choice of CRLF as the preferred line terminator for email was made
long ago. It cannot be changed now, and specifying types that conflict with
this is a really bad idea.

				Ned
>From [email-masked]  Thu May 20 15:24:41 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Thu May 20 15:24:50 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 5/18/2004 9:24 AM, [email-masked] wrote:

> The choice of CRLF as the preferred line terminator for email was made
> long ago. It cannot be changed now, and specifying types that conflict
> with this is a really bad idea.

Of course this statement is correct in multiple contexts. But we're not
talking about "mail" here -- mbox files are mailstore-specific databases,
and not collections of "Internet mail" in general. They need to be treated
in the same way that (say) Eudora or OE databases would be handleded.
Whether any specific mbox file happens to contain sequences of Internet
messages and is easy to parse as text is somewhat irrelevant, since it
could just as easily contain locally addressed messages of undeclared
eight-bit character data. The database needs to be treated as opaque, and
the end-point applications that use it should be responsible for any
necessary prior agreements and arrangements.

> Mbox files are mailed around using 7bit and 8bit encodings all the
> time. A media type that is incompatible with this very common usage is
> either (a) Not going to get used, making it worthless or (b) Will be
> used in a way that violates your MUST, which will break
> interoperability.

I can make explicit allowances for that if it would make people more
comfortable. Since the database content has to be negotiated out-of-band
anyway ("download the archive of message/rfc822 objects", or "these
messages are all big5"), folks certainly should be able to match an
appropriate encoding to the content.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Thu May 20 15:32:18 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Thu May 20 15:33:53 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Thu, 20 May 2004 08:24:41 -0500"
	<[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/18/2004 9:24 AM, [email-masked] wrote:

> > The choice of CRLF as the preferred line terminator for email was made
> > long ago. It cannot be changed now, and specifying types that conflict
> > with this is a really bad idea.

> Of course this statement is correct in multiple contexts. But we're not
> talking about "mail" here -- mbox files are mailstore-specific databases,
> and not collections of "Internet mail" in general. They need to be treated
> in the same way that (say) Eudora or OE databases would be handleded.
> Whether any specific mbox file happens to contain sequences of Internet
> messages and is easy to parse as text is somewhat irrelevant, since it
> could just as easily contain locally addressed messages of undeclared
> eight-bit character data. The database needs to be treated as opaque, and
> the end-point applications that use it should be responsible for any
> necessary prior agreements and arrangements.

I don't know what handling is "needed". What I do know is that these files are
in practice handled as text files, with all that implies.

> > Mbox files are mailed around using 7bit and 8bit encodings all the
> > time. A media type that is incompatible with this very common usage is
> > either (a) Not going to get used, making it worthless or (b) Will be
> > used in a way that violates your MUST, which will break
> > interoperability.

> I can make explicit allowances for that if it would make people more
> comfortable. Since the database content has to be negotiated out-of-band
> anyway ("download the archive of message/rfc822 objects", or "these
> messages are all big5"), folks certainly should be able to match an
> appropriate encoding to the content.

The appropriate encoding in practice is going to be no encoding.

				Ned
>From [email-masked]  Thu May 20 15:52:19 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Thu May 20 15:52:26 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 5/20/2004 8:32 AM, [email-masked] wrote:

> The appropriate encoding in practice is going to be no encoding.

Something to the affect of "any transfer encoding may be used, as
appropriate to the contents of the database file itself; the
characteristics of the content may need to be declared and/or negotiated
out-of-band prior to transfer". that okay with you?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Thu May 20 16:43:21 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Thu May 20 16:44:07 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Thu, 20 May 2004 08:52:19 -0500"
	<[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/20/2004 8:32 AM, [email-masked] wrote:

> > The appropriate encoding in practice is going to be no encoding.

> Something to the affect of "any transfer encoding may be used, as
> appropriate to the contents of the database file itself; the
> characteristics of the content may need to be declared and/or negotiated
> out-of-band prior to transfer". that okay with you?

Might want to make it explicit that 7bit or 8bit was allowed and that
implies CRLF will be the line terminator. But yes, something along these
lines is acceptable to me.

				Ned
>From [email-masked]  Thu May 13 14:35:11 2004
From: rami.avidan at securedemail.se (Rami Avidan)
Date: Fri May 21 02:18:00 2004
Subject: Secured eMail vendor tree, registration for vnd.sema
Message-ID: <[email-masked]>

Dear all

We have repeatedly sent in registration application mails with now response
about the future needs and wants to achieve the vnd.sema registration.

Please advice what steps We need to take to reach the desired outcome

Many thanks 

Warm regards

Rami Avidan

Chief Operating Officer 

Chief Security Officer 

Secured eMail AB

Off:   +46 319 11 277

Fax:   +46 319 11 340

Mob:   +46 733157607

eMail: [email-masked] 

Url:        HYPERLINK "http://www.securedemail.se"www.securedemail.se

 

Kungsporten 4e

427 50 Billdal

Sweden 

Secured eMail is an encryption program created to secure email
communication. It uses the most advanced standard of encryption, AES,
together with the unique, patented System SKG method that generates code
keys to lock the mail. Secured eMail enables electronic messaging to be a
secured means of communication for large corporations, small organisations
and the personal email user. For channel enquiries contact HYPERLINK
"mailto:[email-masked]"[email-masked]. 

I M P O R T A N T   N O T I C E 

This email and any attachments to it contain information which is
confidential and may also be privileged. It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s) please note
that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited and is unlawful. If you have
received this email in error please return it to the sender and delete the
email from your records or call above phone number.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.678 / Virus Database: 440 - Release Date: 2004-05-06
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040513/78c5bcb3/attachment.htm
>From [email-masked]  Fri May 21 05:28:36 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Fri May 21 05:31:23 2004
Subject: Secured eMail vendor tree, registration for vnd.sema
In-Reply-To: "Your message dated Thu, 13 May 2004 14:35:11 +0200"
	<[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> We have repeatedly sent in registration application mails with now response
> about the future needs and wants to achieve the vnd.sema registration.

Have you submitted the registration to [email-masked] and/or used the
web form located at http://www.iana.org/cgi-bin/mediatypes.pl to
request registration? You have to submit the registration to IANA;
posting here is solely for review purposes and not registration.

				Ned

P.S. It's possible I missed it, but I don't believe a vnd.sema
registration has been passed on to the media types reviewer (me).
>From [email-masked]  Sat May 22 01:40:10 2004
From: chris at w3.org (Chris Lilley)
Date: Sat May 22 01:40:19 2004
Subject: Secured eMail vendor tree, registration for vnd.sema
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Friday, May 21, 2004, 5:28:36 AM, ned wrote:

>> We have repeatedly sent in registration application mails with now response
>> about the future needs and wants to achieve the vnd.sema registration.

Rami, I told you how to proceed several weeks ago when you emailed me
repeatedly asking what to do next. I even gave you the URL of the
form to fill in and a pointer to instructions on how to do it. Short
of filling it in for you, I don't think anyone can help you much more.

nfmc> Have you submitted the registration to [email-masked] and/or used the
nfmc> web form located at http://www.iana.org/cgi-bin/mediatypes.pl to
nfmc> request registration? You have to submit the registration to IANA;
nfmc> posting here is solely for review purposes and not registration.

nfmc> 				Ned

nfmc> P.S. It's possible I missed it, but I don't believe a vnd.sema
nfmc> registration has been passed on to the media types reviewer (me).

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 16:12:16 -0700" <a06101117bcbc81bb6343@[129.46.158.190]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <a06101117bcbc81bb6343@[129.46.158.190]>
Message-ID: <[email-masked]>

> At 5:51 PM -0500 5/3/04, Eric A. Hall wrote:
> >I'm thinking about the problem with defaults here. If it's under text/*
> >then default is text/plain which is eol conversion, but if it's under
> >application/* then the default is application/octet-stream which is
> >binary. If we *want* eol conversion, then it pretty much has to be under
> >the text/* tree.

> You *could* put it under application and specify explicitly that it
> takes a charset parameter and eol conversion.

Actually, you _don't_ want a charset parameter since the content
can involve multiple charsets.

> How many people will
> pay attention is anyone's guess.  In practice, I expect you're right
> that text/* is eol conversion and application/* is not.

Yep.

> (I used to argue for an explicit CT parameter specifying EOL
> conversion, but no sense reopening decade-dead debates...)

I have a file that in effect specifies this on a per-content-type basis.

				Ned

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 17:51:13 -0500" <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/3/2004 5:33 PM, [email-masked] wrote:

> > The issue with putting it under text is "what charset is this exactly?"
> > I would be willing to ignore the issue but others may not be.
> >
> > I can certainly live with 7bit/8bit under application.

> I'm thinking about the problem with defaults here. If it's under text/*
> then default is text/plain which is eol conversion, but if it's under
> application/* then the default is application/octet-stream which is
> binary. If we *want* eol conversion, then it pretty much has to be under
> the text/* tree.

Sadly, you're probably right about this.

				Ned

From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <a0610111abcbc832fba56@[129.46.158.190]>

I think mbox format that uses binary content-types is probably less 
interoperable than one that uses text only.

From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue May  4 01:15:20 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]>	<[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <a06101117bcbc81bb6343@[129.46.158.190]>

At 5:51 PM -0500 5/3/04, Eric A. Hall wrote:
>I'm thinking about the problem with defaults here. If it's under text/*
>then default is text/plain which is eol conversion, but if it's under
>application/* then the default is application/octet-stream which is
>binary. If we *want* eol conversion, then it pretty much has to be under
>the text/* tree.

You *could* put it under application and specify explicitly that it 
takes a charset parameter and eol conversion.  How many people will 
pay attention is anyone's guess.  In practice, I expect you're right 
that text/* is eol conversion and application/* is not.

(I used to argue for an explicit CT parameter specifying EOL 
conversion, but no sense reopening decade-dead debates...)
>From [email-masked]  Tue May  4 01:17:35 2004
From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue May  4 01:20:39 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <a0610111abcbc832fba56@[129.46.158.190]>

I think mbox format that uses binary content-types is probably less 
interoperable than one that uses text only.
>From [email-masked]  Tue May  4 01:26:19 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Tue May  4 01:26:49 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 17:51:13 -0500"
	<[email-masked]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/3/2004 5:33 PM, [email-masked] wrote:

> > The issue with putting it under text is "what charset is this exactly?"
> > I would be willing to ignore the issue but others may not be.
> >
> > I can certainly live with 7bit/8bit under application.

> I'm thinking about the problem with defaults here. If it's under text/*
> then default is text/plain which is eol conversion, but if it's under
> application/* then the default is application/octet-stream which is
> binary. If we *want* eol conversion, then it pretty much has to be under
> the text/* tree.

Sadly, you're probably right about this.

				Ned
>From [email-masked]  Tue May  4 01:32:15 2004
From: chris at w3.org (Chris Lilley)
Date: Tue May  4 01:32:19 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <a0610111abcbc832fba56@[129\.46\.158\.190]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<a0610111abcbc832fba56@[129.46.158.190]>
Message-ID: <[email-masked]>

On Tuesday, May 4, 2004, 1:17:35 AM, Steve wrote:

SD> I think mbox format that uses binary content-types is probably less
SD> interoperable than one that uses text only.

That amounts to an assertion that eol conversions and on-the-fly
encoding conversion generally do more good than harm. It may be true,
but it may not be.

Tests using an mbox that contains messages in a variety of encodings
(including some multibyte and code shifting encodings) would be needed
to determin interoperability in practice.

If conversion to a local eol convention is considered desirable, I
would rather this was done by the mbox content type handler rather
than bringing along the rest of the text/* baggage.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]>	<[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <a06101117bcbc81bb6343@[129.46.158.190]>

At 5:51 PM -0500 5/3/04, Eric A. Hall wrote:
>I'm thinking about the problem with defaults here. If it's under text/*
>then default is text/plain which is eol conversion, but if it's under
>application/* then the default is application/octet-stream which is
>binary. If we *want* eol conversion, then it pretty much has to be under
>the text/* tree.

You *could* put it under application and specify explicitly that it 
takes a charset parameter and eol conversion.  How many people will 
pay attention is anyone's guess.  In practice, I expect you're right 
that text/* is eol conversion and application/* is not.

(I used to argue for an explicit CT parameter specifying EOL 
conversion, but no sense reopening decade-dead debates...)

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tuesday, May 4, 2004, 12:33:24 AM, ned wrote:

>> On 5/3/2004 5:15 PM, [email-masked] wrote:

nfmc> The issue with putting it under text is "what charset is this exactly?" I would
nfmc> be willing to ignore the issue but others may not be. 

I agree others may not be; I am one of them.

A mailbox can contain multiple messages, which can be in different
encodings.

If an entire mbox is being transferred, then making assumptions about
line endings and where they can be fiddled with seems dangerous.

Allowing transcoding also seems dangerous; it would make the internal
labelling of individual messages in the mailbox incorrect. The problem
here is that there are two levels of MIME in use; one for the mbox as
a whiole and then one for the individual emails in the mbox.

Assuming a safe fallback to text/plain;charset=us-ascii as a
reasonable presentation also seems to be unwarranted.

I suggest sticking with application/mbox and leaving encoding
declarations to the individual messages or message body parts in the
mailbox.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/3/2004 5:33 PM, [email-masked] wrote:

> The issue with putting it under text is "what charset is this exactly?"
> I would be willing to ignore the issue but others may not be.
> 
> I can certainly live with 7bit/8bit under application.

I'm thinking about the problem with defaults here. If it's under text/*
then default is text/plain which is eol conversion, but if it's under
application/* then the default is application/octet-stream which is
binary. If we *want* eol conversion, then it pretty much has to be under
the text/* tree.

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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 17:32:21 -0500" <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/3/2004 5:15 PM, [email-masked] wrote:

> >> I'm unconvinced that they're not used with local line conventions on
> >> some platforms.
> >
> > You're right to be unconvinced. I routinely use mbox format files on
> > several different platforms with different line termination conventions
> > and I always use whatever the local convension happens to be.

> The couple of systems I've tested don't seem to care either way. Based on
> your comments, I'd hazard the guess that eol conversion is okay.

Good.

> That means it doesn't have to be application/* anymore. Would it be more
> useful in text/*?

The issue with putting it under text is "what charset is this exactly?" I would
be willing to ignore the issue but others may not be. 

I can certainly live with 7bit/8bit under application.

> It shouldn't be message/* given the other deformities.

I really wish it could be under message, but it just doesn't fit.

				Ned

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>	<a0610110dbcbc6a47e401@[129.46.158.190]> <[email-masked]>
Message-ID: <[email-masked]>

On 5/3/2004 5:15 PM, [email-masked] wrote:

>> I'm unconvinced that they're not used with local line conventions on 
>> some platforms.
> 
> You're right to be unconvinced. I routinely use mbox format files on
> several different platforms with different line termination conventions
> and I always use whatever the local convension happens to be.

The couple of systems I've tested don't seem to care either way. Based on
your comments, I'd hazard the guess that eol conversion is okay.

That means it doesn't have to be application/* anymore. Would it be more
useful in text/*? It shouldn't be message/* given the other deformities.

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

From: ned.freed at mrochek.com ([email-masked])
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 14:32:50 -0700" <a0610110dbcbc6a47e401@[129.46.158.190]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]> <a0610110dbcbc6a47e401@[129.46.158.190]>
Message-ID: <[email-masked]>

> At 4:24 PM -0500 5/3/04, Eric A. Hall wrote:
> >In the meantime, take a look at ftp://ftp.ietf.org/ietf-mail-archive/ ...
> >The whole world (including the IETF) is already using mbox as the default
> >interchange format and its becoming more common.

> "The whole world" is maybe a stretch (my MTA converts them to
> multipart/digest when sending), but certainly a widespread practice
> begs to be documented.

I concur. I have no problem with registering application/mbox, but
multipart/digest usage should be encouraged. (I use multipart/digest as my
default archive format.)

> >I want them to be binary so that the EOL conversion does not occur. The
> >problems start when conversion occurs.

> I'm unconvinced that they're not used with local line conventions on
> some platforms. 

You're right to be unconvinced. I routinely use mbox format files on several
different platforms with different line termination conventions and I always
use whatever the local convension happens to be. A type that mandates LF
terminators is almost entirely useless to me.

> I happen to work on a product that does just that,
> though if I were the only one, I wouldn't worry about it much.

My usage doesn't involve your product, so you're not the only one. 

				Ned

From: sdorner at qualcomm.com (Steve Dorner)
Date: Mon May  3 23:34:16 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
Message-ID: <a0610110dbcbc6a47e401@[129.46.158.190]>

At 4:24 PM -0500 5/3/04, Eric A. Hall wrote:
>In the meantime, take a look at ftp://ftp.ietf.org/ietf-mail-archive/ ...
>The whole world (including the IETF) is already using mbox as the default
>interchange format and its becoming more common.

"The whole world" is maybe a stretch (my MTA converts them to 
multipart/digest when sending), but certainly a widespread practice 
begs to be documented.

>I want them to be binary so that the EOL conversion does not occur. The
>problems start when conversion occurs.

I'm unconvinced that they're not used with local line conventions on 
some platforms.  I happen to work on a product that does just that, 
though if I were the only one, I wouldn't worry about it much.
>From [email-masked]  Tue May  4 00:15:51 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Tue May  4 00:20:07 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 14:32:50 -0700"
	<a0610110dbcbc6a47e401@[129.46.158.190]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
Message-ID: <[email-masked]>

> At 4:24 PM -0500 5/3/04, Eric A. Hall wrote:
> >In the meantime, take a look at ftp://ftp.ietf.org/ietf-mail-archive/ ...
> >The whole world (including the IETF) is already using mbox as the default
> >interchange format and its becoming more common.

> "The whole world" is maybe a stretch (my MTA converts them to
> multipart/digest when sending), but certainly a widespread practice
> begs to be documented.

I concur. I have no problem with registering application/mbox, but
multipart/digest usage should be encouraged. (I use multipart/digest as my
default archive format.)

> >I want them to be binary so that the EOL conversion does not occur. The
> >problems start when conversion occurs.

> I'm unconvinced that they're not used with local line conventions on
> some platforms. 

You're right to be unconvinced. I routinely use mbox format files on several
different platforms with different line termination conventions and I always
use whatever the local convension happens to be. A type that mandates LF
terminators is almost entirely useless to me.

> I happen to work on a product that does just that,
> though if I were the only one, I wouldn't worry about it much.

My usage doesn't involve your product, so you're not the only one. 

				Ned
>From [email-masked]  Tue May  4 00:32:21 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Tue May  4 00:32:29 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<a06101107bcbc64a19123@[129.46.158.190]>
	<[email-masked]>	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 5/3/2004 5:15 PM, [email-masked] wrote:

>> I'm unconvinced that they're not used with local line conventions on 
>> some platforms.
> 
> You're right to be unconvinced. I routinely use mbox format files on
> several different platforms with different line termination conventions
> and I always use whatever the local convension happens to be.

The couple of systems I've tested don't seem to care either way. Based on
your comments, I'd hazard the guess that eol conversion is okay.

That means it doesn't have to be application/* anymore. Would it be more
useful in text/*? It shouldn't be message/* given the other deformities.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Tue May  4 00:33:24 2004
From: ned.freed at mrochek.com ([email-masked])
Date: Tue May  4 00:43:39 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: "Your message dated Mon, 03 May 2004 17:32:21 -0500"
	<[email-masked]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On 5/3/2004 5:15 PM, [email-masked] wrote:

> >> I'm unconvinced that they're not used with local line conventions on
> >> some platforms.
> >
> > You're right to be unconvinced. I routinely use mbox format files on
> > several different platforms with different line termination conventions
> > and I always use whatever the local convension happens to be.

> The couple of systems I've tested don't seem to care either way. Based on
> your comments, I'd hazard the guess that eol conversion is okay.

Good.

> That means it doesn't have to be application/* anymore. Would it be more
> useful in text/*?

The issue with putting it under text is "what charset is this exactly?" I would
be willing to ignore the issue but others may not be. 

I can certainly live with 7bit/8bit under application.

> It shouldn't be message/* given the other deformities.

I really wish it could be under message, but it just doesn't fit.

				Ned
>From [email-masked]  Tue May  4 00:51:13 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Tue May  4 00:51:20 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]>
	<[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 5/3/2004 5:33 PM, [email-masked] wrote:

> The issue with putting it under text is "what charset is this exactly?"
> I would be willing to ignore the issue but others may not be.
> 
> I can certainly live with 7bit/8bit under application.

I'm thinking about the problem with defaults here. If it's under text/*
then default is text/plain which is eol conversion, but if it's under
application/* then the default is application/octet-stream which is
binary. If we *want* eol conversion, then it pretty much has to be under
the text/* tree.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Tue May  4 01:11:22 2004
From: chris at w3.org (Chris Lilley)
Date: Tue May  4 01:11:26 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
	<a0610110dbcbc6a47e401@[129.46.158.190]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tuesday, May 4, 2004, 12:33:24 AM, ned wrote:

>> On 5/3/2004 5:15 PM, [email-masked] wrote:

nfmc> The issue with putting it under text is "what charset is this exactly?" I would
nfmc> be willing to ignore the issue but others may not be. 

I agree others may not be; I am one of them.

A mailbox can contain multiple messages, which can be in different
encodings.

If an entire mbox is being transferred, then making assumptions about
line endings and where they can be fiddled with seems dangerous.

Allowing transcoding also seems dangerous; it would make the internal
labelling of individual messages in the mailbox incorrect. The problem
here is that there are two levels of MIME in use; one for the mbox as
a whiole and then one for the individual emails in the mbox.

Assuming a safe fallback to text/plain;charset=us-ascii as a
reasonable presentation also seems to be unwarranted.

I suggest sticking with application/mbox and leaving encoding
declarations to the individual messages or message body parts in the
mailbox.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]> <[email-masked]>
Message-ID: <a0610110dbcbc6a47e401@[129.46.158.190]>

At 4:24 PM -0500 5/3/04, Eric A. Hall wrote:
>In the meantime, take a look at ftp://ftp.ietf.org/ietf-mail-archive/ ...
>The whole world (including the IETF) is already using mbox as the default
>interchange format and its becoming more common.

"The whole world" is maybe a stretch (my MTA converts them to 
multipart/digest when sending), but certainly a widespread practice 
begs to be documented.

>I want them to be binary so that the EOL conversion does not occur. The
>problems start when conversion occurs.

I'm unconvinced that they're not used with local line conventions on 
some platforms.  I happen to work on a product that does just that, 
though if I were the only one, I wouldn't worry about it much.

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <a06101107bcbc64a19123@[129\.46\.158\.190]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]>
Message-ID: <[email-masked]>

On Monday, May 3, 2004, 11:12:15 PM, Steve wrote:

SD> At 3:58 PM -0500 5/3/04, Eric A. Hall wrote:
>>As per RFC2048, I'm planning to propose an application/mbox media-type.

SD> Hmmmmm.  We already have a type for a collection of messages 
SD> (multipart/digest).  Absent argument to the contrary, I'd rather 
SD> encourage the use of that than to register one particular local form.

Does mbox format follow the syntactic constraints of a digest?

SD> I'm also a little concerned about the EOL issue you allude to.  I 
SD> assume you mean to register these as LF delimitted, which will make
SD> them binary files, and perhaps more problematic for many users to 
SD> deal with.

I think it just means that they transfer intact.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <a06101107bcbc64a19123@[129.46.158.190]>
References: <[email-masked]> <a06101107bcbc64a19123@[129.46.158.190]>
Message-ID: <[email-masked]>

On 5/3/2004 4:12 PM, Steve Dorner wrote:

> At 3:58 PM -0500 5/3/04, Eric A. Hall wrote:
> 
>>As per RFC2048, I'm planning to propose an application/mbox media-type.
> 
> Hmmmmm.  We already have a type for a collection of messages 
> (multipart/digest).  Absent argument to the contrary, I'd rather 
> encourage the use of that than to register one particular local form.

"Encourage" is something I absolutely agree with.

In the meantime, take a look at ftp://ftp.ietf.org/ietf-mail-archive/ ...
The whole world (including the IETF) is already using mbox as the default
interchange format and its becoming more common. Let's give it a
media-type in recognition of the current reality, and so that the current
interchange system can be improved.

> I'm also a little concerned about the EOL issue you allude to.  I
> assume you mean to register these as LF delimitted, which will make
> them binary files, and perhaps more problematic for many users to
> deal with.

I want them to be binary so that the EOL conversion does not occur. The
problems start when conversion occurs.

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

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon May  3 22:58:19 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
Message-ID: <[email-masked]>

As per RFC2048, I'm planning to propose an application/mbox media-type.
The impetus for this is as follows:

  1.      Background and Overview

     UNIX and look-alike operating systems have historically made
     extensive use of "MBOX" mailbox files for a variety of messaging
     purposes. In the common case, these files are used to hold
     collections of electronic mail messages which users manipulate as
     "folders" of a private mail-store. These files are also frequently
     used by a variety of back-end email services, including delivery
     servers, filtering systems, and mailing-list programs. Over the
     last few years, the use of these files has also spread to other
     operating systems, with a variety of messaging tools on numerous
     platforms now providing direct access to MBOX files.

     The increased pervasiveness of these files has led to an increased
     demand for improvements in cross-system, network-wide interchange
     of these files. In turn, this requirement also dictates a need for
     a media-type definition for MBOX files in general.

     For example, some applications allow users to open MBOX files as
     discrete data-objects, but use platform- or product-specific
     mapping techniques to identify these files. Similarly, many
     mailing list archive programs provide access to MBOX files for
     historical messages, but will publish these files as text/plain or
     some other generic media-type, but which causes problematic end-
     of-line conversions when these files are transferred across a
     network, or which does not provide for local actions that should
     be performed against the data (such as prompting the user to
     import the mailbox data into a local mail-store). The definition
     of a standard media-type for these files would facilitate a more
     consistent behavior for these types of actions, and would further
     the cause of interoperability.

     Note that this specification does not define the MBOX data file as
     an authoritative Internet data-type or structure. Instead, it
     merely seeks to define a standard media-type definition for these
     files, so that their transfer may be more consistent.

According to my reading of 2048 this should be pretty straightforward,
although the lack of a clear authoritative spec may be problematic.

Please review and advise.

Thanks

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

-------------- next part --------------
An embedded message was scrubbed...
From: [email-masked]
Subject: I-D ACTION:draft-hall-mime-app-mbox-00.txt
Date: Mon, 03 May 2004 15:54:45 -0400
Size: 4696
Url: http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040503/c22c7f60/draft-hall-mime-app-mbox-00.eml
>From [email-masked]  Mon May  3 23:12:15 2004
From: sdorner at qualcomm.com (Steve Dorner)
Date: Mon May  3 23:14:42 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <a06101107bcbc64a19123@[129.46.158.190]>

At 3:58 PM -0500 5/3/04, Eric A. Hall wrote:
>As per RFC2048, I'm planning to propose an application/mbox media-type.

Hmmmmm.  We already have a type for a collection of messages 
(multipart/digest).  Absent argument to the contrary, I'd rather 
encourage the use of that than to register one particular local form.

I'm also a little concerned about the EOL issue you allude to.  I 
assume you mean to register these as LF delimitted, which will make 
them binary files, and perhaps more problematic for many users to 
deal with.
>From [email-masked]  Mon May  3 23:24:07 2004
From: ehall at ehsco.com (Eric A. Hall)
Date: Mon May  3 23:24:15 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <a06101107bcbc64a19123@[129.46.158.190]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]>
Message-ID: <[email-masked]>

On 5/3/2004 4:12 PM, Steve Dorner wrote:

> At 3:58 PM -0500 5/3/04, Eric A. Hall wrote:
> 
>>As per RFC2048, I'm planning to propose an application/mbox media-type.
> 
> Hmmmmm.  We already have a type for a collection of messages 
> (multipart/digest).  Absent argument to the contrary, I'd rather 
> encourage the use of that than to register one particular local form.

"Encourage" is something I absolutely agree with.

In the meantime, take a look at ftp://ftp.ietf.org/ietf-mail-archive/ ...
The whole world (including the IETF) is already using mbox as the default
interchange format and its becoming more common. Let's give it a
media-type in recognition of the current reality, and so that the current
interchange system can be improved.

> I'm also a little concerned about the EOL issue you allude to.  I
> assume you mean to register these as LF delimitted, which will make
> them binary files, and perhaps more problematic for many users to
> deal with.

I want them to be binary so that the EOL conversion does not occur. The
problems start when conversion occurs.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>From [email-masked]  Mon May  3 23:31:11 2004
From: chris at w3.org (Chris Lilley)
Date: Mon May  3 23:31:23 2004
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <a06101107bcbc64a19123@[129\.46\.158\.190]>
References: <[email-masked]>
	<a06101107bcbc64a19123@[129.46.158.190]>
Message-ID: <[email-masked]>

On Monday, May 3, 2004, 11:12:15 PM, Steve wrote:

SD> At 3:58 PM -0500 5/3/04, Eric A. Hall wrote:
>>As per RFC2048, I'm planning to propose an application/mbox media-type.

SD> Hmmmmm.  We already have a type for a collection of messages 
SD> (multipart/digest).  Absent argument to the contrary, I'd rather 
SD> encourage the use of that than to register one particular local form.

Does mbox format follow the syntactic constraints of a digest?

SD> I'm also a little concerned about the EOL issue you allude to.  I 
SD> assume you mean to register these as LF delimitted, which will make
SD> them binary files, and perhaps more problematic for many users to 
SD> deal with.

I think it just means that they transfer intact.

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: ehall at ehsco.com (Eric A. Hall)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
Message-ID: <[email-masked]>

As per RFC2048, I'm planning to propose an application/mbox media-type.
The impetus for this is as follows:

  1.      Background and Overview

     UNIX and look-alike operating systems have historically made
     extensive use of "MBOX" mailbox files for a variety of messaging
     purposes. In the common case, these files are used to hold
     collections of electronic mail messages which users manipulate as
     "folders" of a private mail-store. These files are also frequently
     used by a variety of back-end email services, including delivery
     servers, filtering systems, and mailing-list programs. Over the
     last few years, the use of these files has also spread to other
     operating systems, with a variety of messaging tools on numerous
     platforms now providing direct access to MBOX files.

     The increased pervasiveness of these files has led to an increased
     demand for improvements in cross-system, network-wide interchange
     of these files. In turn, this requirement also dictates a need for
     a media-type definition for MBOX files in general.

     For example, some applications allow users to open MBOX files as
     discrete data-objects, but use platform- or product-specific
     mapping techniques to identify these files. Similarly, many
     mailing list archive programs provide access to MBOX files for
     historical messages, but will publish these files as text/plain or
     some other generic media-type, but which causes problematic end-
     of-line conversions when these files are transferred across a
     network, or which does not provide for local actions that should
     be performed against the data (such as prompting the user to
     import the mailbox data into a local mail-store). The definition
     of a standard media-type for these files would facilitate a more
     consistent behavior for these types of actions, and would further
     the cause of interoperability.

     Note that this specification does not define the MBOX data file as
     an authoritative Internet data-type or structure. Instead, it
     merely seeks to define a standard media-type definition for these
     files, so that their transfer may be more consistent.

According to my reading of 2048 this should be pretty straightforward,
although the lack of a clear authoritative spec may be problematic.

Please review and advise.

Thanks

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

-------------- next part --------------
An embedded message was scrubbed...
From: [email-masked]
Subject: I-D ACTION:draft-hall-mime-app-mbox-00.txt
Date: Mon, 03 May 2004 15:54:45 -0400
Size: 4696
Url: http://www.alvestrand.no/pipermail/ietf-types/attachments/20040503/c22c7f60/draft-hall-mime-app-mbox-00.mht
>From [email-masked]  Mon May  3 23:12:15 2004
From: sdorner at qualcomm.com (Steve Dorner)
Date: Tue Jan  3 16:22:43 2006
Subject: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <a06101107bcbc64a19123@[129.46.158.190]>

At 3:58 PM -0500 5/3/04, Eric A. Hall wrote:
>As per RFC2048, I'm planning to propose an application/mbox media-type.

Hmmmmm.  We already have a type for a collection of messages 
(multipart/digest).  Absent argument to the contrary, I'd rather 
encourage the use of that than to register one particular local form.

I'm also a little concerned about the EOL issue you allude to.  I 
assume you mean to register these as LF delimitted, which will make 
them binary files, and perhaps more problematic for many users to 
deal with.

From: mark.nottingham at bea.com (Mark Nottingham)
Date: Mon May  3 06:21:04 2004
Subject: For review: draft-baker-soap-media-reg-05
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Chris.

For interoperability. In particular, if any version of XML is allowed, 
it's possible to have a message that contains characters that are 
impossible to re-serialize into a lower version of XML; as a result, 
intermediaries in particular, may be in a difficult situation.

We expect that other versions of XML would be accommodated by other 
media types; there is nothing in SOAP itself that constrains the 
version of XML.

The related errata issues (rec20[1] and rec22[2]) against SOAP 1.2 were 
resolved last week, but unfortunately the result isn't reflected in 
their summaries, and the meeting minutes are not yet available. This 
information should be available very soon.

Regards,

1. http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x20
2. http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x22

On Apr 30, 2004, at 3:28 PM, Chris Lilley wrote:

> On Saturday, May 1, 2004, 12:09:31 AM, Mark wrote:
>
> MN> The only substantive change in this draft is the restriction of the
> MN> content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be 
> identified
> MN> by this media type).
>
> MN> 
> http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt
>
> What motivates this change? Why exclude XML 1.1?
>
> -- 
>  Chris Lilley                    mailto:[email-masked]
>  Chair, W3C SVG Working Group
>  Member, W3C Technical Architecture Group
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: mark.nottingham at bea.com (Mark Nottingham)
Date: Tue Jan  3 16:22:43 2006
Subject: For review: draft-baker-soap-media-reg-05
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Chris.

For interoperability. In particular, if any version of XML is allowed, 
it's possible to have a message that contains characters that are 
impossible to re-serialize into a lower version of XML; as a result, 
intermediaries in particular, may be in a difficult situation.

We expect that other versions of XML would be accommodated by other 
media types; there is nothing in SOAP itself that constrains the 
version of XML.

The related errata issues (rec20[1] and rec22[2]) against SOAP 1.2 were 
resolved last week, but unfortunately the result isn't reflected in 
their summaries, and the meeting minutes are not yet available. This 
information should be available very soon.

Regards,

1. http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x20
2. http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x22

On Apr 30, 2004, at 3:28 PM, Chris Lilley wrote:

> On Saturday, May 1, 2004, 12:09:31 AM, Mark wrote:
>
> MN> The only substantive change in this draft is the restriction of the
> MN> content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be 
> identified
> MN> by this media type).
>
> MN> 
> http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt
>
> What motivates this change? Why exclude XML 1.1?
>
> -- 
>  Chris Lilley                    mailto:[email-masked]
>  Chair, W3C SVG Working Group
>  Member, W3C Technical Architecture Group
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: chris at w3.org (Chris Lilley)
Date: Sat May  1 00:28:27 2004
Subject: For review: draft-baker-soap-media-reg-05
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Saturday, May 1, 2004, 12:09:31 AM, Mark wrote:

MN> The only substantive change in this draft is the restriction of the
MN> content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be identified
MN> by this media type).

MN> http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt

What motivates this change? Why exclude XML 1.1?

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: chris at w3.org (Chris Lilley)
Date: Tue Jan  3 16:22:43 2006
Subject: For review: draft-baker-soap-media-reg-05
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Saturday, May 1, 2004, 12:09:31 AM, Mark wrote:

MN> The only substantive change in this draft is the restriction of the
MN> content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be identified
MN> by this media type).

MN> http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt

What motivates this change? Why exclude XML 1.1?

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

From: mark.nottingham at bea.com (Mark Nottingham)
Date: Sat May  1 00:09:56 2004
Subject: For review: draft-baker-soap-media-reg-05
Message-ID: <[email-masked]>

The only substantive change in this draft is the restriction of the 
content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be identified 
by this media type).

http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: mark.nottingham at bea.com (Mark Nottingham)
Date: Tue Jan  3 16:22:43 2006
Subject: For review: draft-baker-soap-media-reg-05
Message-ID: <[email-masked]>

The only substantive change in this draft is the restriction of the 
content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be identified 
by this media type).

http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems