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

[Eric A. Hall]

On 1/30/2005 11:24 AM, Bruce Lilly wrote:

> 2. An IANA Considerations section related to establishment of a
>    format value keyword registry (containing the "default" entry),
>    and maintenance of that registry in conjunction with the
>    registration procedure.

Yeah probably.

> 4. Syntax rules and ABNF for the format keyword values, unless
>    "anything goes".
> 
> 5. Semantic rules for format value keywords, e.g. are they
>    case-insensitive.

That's already covered in section 5.1 of RFC 2045.

>>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).
> 
> Since the format differs from canonical message format, and as there
> appears to be provision for encoding parts of the media type (using
> an unspecified encoding algorithm), it appears that several items are
> missing regarding such encoding:
> 
> 1. encoding algorithm(s) and corresponding decoding algorithm(s)

this is just transfer encoding, although I guess this point needs
clarification

> In the registration temple, the magic number could be indicated as
> 0x46726F6D20 ("From ").

good idea

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