Proposal for Miffy MIME Headers

This note is in fulfullment of an action that I was assigned to propose
text regarding the handling of headers in Miffy.  Specifically, the
proposal is to allow encoders by allowed to apply headers permitted by the
multi-part related specification (RFC 2387), but to require that receivers
be capable of decoding miffy documents that lack such headers.

Note that I am not expert in MIME or related matters, so there is a real
risk that the following misses some nuances.

<original>
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.
</original>
<proposed>
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.
</proposed>

Is that close?  Thanks.

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

Received on Tuesday, 16 December 2003 17:29:03 UTC