Re: Proposal for Miffy MIME Headers

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
--------------------------------------

Received on Wednesday, 17 December 2003 10:07:45 UTC