Re: Proposal for Miffy MIME Headers

I like your proposal, both for its improvements to wording and for having 
been written by someone who knows MIME better than I do.  Notwithstanding 
your wish not to join a protracted debate, do you have any objection to my 
pointing the workgroup to the archived copy of your note?  Thanks.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Graham Klyne <gk@ninebynine.org>
12/18/03 04:33 PM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     www-archive <www-archive@w3.org>
        Subject:        Re: Proposal for Miffy MIME Headers


Noah,

I don't plan to join a long public debate, so I'll pass these comments 
privately, to treat as you will...

(1) Notwithstanding what the MIME spec says about Content_* headers, I 
think it's the HTTP spec that says what HTTP passes is *not* MIME, just 
MIME-like.

I've been working on a header registry spec (with Mark Nottingham and 
Jeffrey Mogul), and part of the feedback we got from Ned Freed (one of the 

MIME spec editors) was that we should be clear about distinguishing MIME 
headers from others.  But I think this is kind-of academic, and shouldn't 
get in the way of the real issues.

(2)  I found some of your proposed wording seemed (to me) a bit 
laboured.  So here's my bite at the problem (feel free to use or ignore 
any 
or all of it):
[[
<newProposal>
MIFFY Documents MUST be valid MIME Multipart/Related documents, as
specified by [rfc2387]. Ordering of MIME parts MUST NOT be considered
significant to MIFFY processing or to the construction of the Target
Infoset.

The root MIME part MUST be an XML 1.0 serialization [xml1.0] of the
Optimized Infoset, and MUST be identified with the [ TBD ] media type.

MIME parts including the root part MUST contain header XXXX and YYYY, and 
Miffy processors may use these to interpret the MIME data.  Other MIME 
headers  may be used and, when used, must be recognized to the extent 
needed to properly decode the MIME structure.  Otherwise, Miffy processing 

does not depend on the presence of any MIME headers other than those 
noted.

For example, Content-Length (RFC 2616) is an optional header:  one or
more parts in a Miffy document may contain a Content-Length header.  If
present, its may be used to optimize buffer management during 
reconstruction of the Infoset, reconstruction of an Infoset should not be 
declined to due to lack of a Content-Length header.
</newProposal>
]]

#g
--

At 10:05 17/12/03 -0500, you wrote:
>Graham Klyne writes:
>
> > I was going to make a similar comment... some MIME
> > headers, when present, must be analyzed to properly
> > interpret the MIME structure.  Noah's comment seemed to
> > focus on headers that were used for other purposes.
>
>Good points.  I was probably being too conservative in my statements for
>at least two reasons:
>
>* Being a real novice in the subtleties of MIME, I didn't
>   want to get into details where I'd add more confusion
>   than insight.
>
>* To some degree we're talking about particular headers
>   that would be used in particular ways by Miffy.  There
>   is indeed ongoing debate about using some such as
>   Content-Encoding, but I didnt' feel that my mandate
>   here was to lock down policy on specific headers,
>   except for Content-length which was specifically
>   discussed at the face-2-face mtg.
>
>So, here's what I think may have been missing from my note.  We can't 
lock
>down proposed text until we've debated the role of specific headers, so
>I'll just refer to headers XXXX and YYYY as placeholders for ones the
>Miffy would specifically use.  Content-encoding might or might not emerge
>as one of those.
>
><yesterdaysProposal>
>MIFFY Documents MUST be valid MIME Multipart/Related documents, as
>specified by [rfc2387]. Ordering of MIME parts MUST NOT be considered
>significant to MIFFY processing or to the construction of the Target
>Infoset.
>The root MIME part MUST be an XML 1.0 serialization [xml1.0] of the
>Optimized Infoset, and MUST be identified with the [ TBD ] media type.
>MIME parts including the root part MAY contain MIME headers as permitted
>by rfc 2387.   Interpretation of Miffy documents to reconstruct an XML
>Infoset (see section 3.2) MUST NOT depend on the presence of such 
optional
>headers.
>For example:  one or more parts in a Miffy document may contain a
>Content-Length header as specified by RFC 2616.  If present, the value of
>the Content-Length may be used by an interpreter to optimize buffer
>management during reconstruction of the Infoset.   An interpreter should
>not decline to reconstruct an Infoset due to lack of a Content-Length
>header.
></yesterdaysProposal>
><newProposal>
>MIFFY Documents MUST be valid MIME Multipart/Related documents, as
>specified by [rfc2387]. Ordering of MIME parts MUST NOT be considered
>significant to MIFFY processing or to the construction of the Target
>Infoset.
>The root MIME part MUST be an XML 1.0 serialization [xml1.0] of the
>Optimized Infoset, and MUST be identified with the [ TBD ] media type.
>
>MIME parts including the root part MUST contain header XXXX and YYYY and
>MAY contain MIME headers as permitted by rfc 2387, including those 
defined
>by additional specifications such as RFC 2616.   Interpretation of Miffy
>documents to reconstruct an XML Infoset (see section 3.2) MUST/MAY
>{depending whether the header is a hint like length or required for
>interpretation like Content-Encoding) depend on the values of XXXX and
>YYYY;  interpretation MUST NOT depend on the presence of other optional
>headers.
>
>For example, Content-Length (RFC 2616) is such an optional header:  one 
or
>more parts in a Miffy document may contain a Content-Length header.  If
>present, the value of the Content-Length may be used by an interpreter to
>optimize buffer management during reconstruction of the Infoset.   An
>interpreter should not decline to reconstruct an Infoset due to lack of a
>Content-Length header.
></newProposal>
>
> > (BTW, Content-length is not strictly a MIME header: it
> > is defined by HTTP, IIRC.)
>
>I think I noted in both my original and new text that it's defined in RFC
>2616, BUT I think it's the MIME RFC (2045) that licenses the use of such
>headers in general and Content-xxxx headers in particular.  It says:
>
>"9.  Additional MIME Header Fields
>
>    Future documents may elect to define additional MIME header fields
>    for various purposes.  Any new header field that further describes
>    the content of a message should begin with the string "Content-" to
>    allow such fields which appear in a message header to be
>    distinguished from ordinary RFC 822 message header fields.
>
>      MIME-extension-field := <Any RFC 822 header field which
>                               begins with the string
>                               "Content-">"
>
>I'm not quick enough reading the RFC's to find it, but presumably there's
>also text in either 2045 or 2387 that specifically licenses the use of
>headers for parts.  So, all of that is independent of RFC 2616, which is
>why I said what I did.  Content-length itself is indeed defined in RFC
>2616.
>
>Hope I haven't scrambled this analysis too much. As I say, it's not my
>area (though I'm learning from this exercise.)
>
>--------------------------------------
>Noah Mendelsohn
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Friday, 19 December 2003 13:18:54 UTC