
The ADs for the applications area are going to move this into last-call again, but we all want to run it back up the flagpole one more time. This version departs from earlier releases by specifying a "format" parameter to the application/mbox media-type, by defining a "default" value for the parameter, and by defining a default mbox database format that must be supported. The use of a format parameter allows different implementations to be documented, and for them to be specified in the transfer (eg, a "SunOS" format might specify the use of content-length and other things). Unrecognized formats are to be treated as application/octet-stream. The "default" format uses a sequence of 822 messages, with the exception that line-endings are LF instead of CR/LF (this only applies to the canonical database, and doesn't affect the transfer protocol or anything else). Inheriting 822 rules means that email addresses must be qualified, encodings must be specified, etc. All implementations have to support this default format, and unspecified formats must be treated as "default" (this is mostly for the benefit of protocols like HTTP, where parameters are not always (or even usually) defined. Another thing that is specified here is that separator lines (at the least) must be encoded to prevent local collisions, when an mbox attachment is saved into an existing local folder (messages can become irreversible mingled if some kind of escaping is not performed). There's one problem in this that I caught after submission, which is that ">From" escaping is specified, but shouldn't be. ">From" escaping is not needed for transfers, and it's mostly a local matter anyway (having to do with local parsing), and it's damn near impossible to deal with all the potential exceptions (such as doubled escapes against quoted text, for example), so it's really best not to specify anything. I'll roll this change into any other comments that I get for the -04 version. Anyway, any other comments are appreciated, as usual. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/