- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Tue, 16 Dec 2003 22:55:42 -0800
- To: noah_mendelsohn@us.ibm.com
- Cc: xml-dist-app@w3.org
noah_mendelsohn@us.ibm.com wrote: > > 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. > By that, you mean that receiver/decoder/reconstructor must not require the presence of such headers, but if they are present then they may have to be taken into account. Right? Specifically, I am thinking of content-transfer-encoding. Thx. -Anish -- > > 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. >
Received on Wednesday, 17 December 2003 01:55:44 UTC