Mark Nottingham | 2 May 02:35 2004
X-Face

Re: For review: draft-baker-soap-media-reg-05

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).
>
(Continue reading)

Eric A. Hall | 3 May 22:58 2004

[Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]


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
(Continue reading)

Steve Dorner | 3 May 23:12 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]

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.

Eric A. Hall | 3 May 23:24 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]


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/
(Continue reading)

Chris Lilley | 3 May 23:31 2004
Picon

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]

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:chris <at> w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Steve Dorner | 3 May 23:32 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]

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.

ned.freed | 4 May 00:15 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]

> 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
(Continue reading)

Eric A. Hall | 4 May 00:32 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]


On 5/3/2004 5:15 PM, ned.freed <at> mrochek.com 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/

ned.freed | 4 May 00:33 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]


> On 5/3/2004 5:15 PM, ned.freed <at> mrochek.com 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

(Continue reading)

Eric A. Hall | 4 May 00:51 2004

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]


On 5/3/2004 5:33 PM, ned.freed <at> mrochek.com 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/


Gmane