Re: Proposal for Miffy MIME Headers

[email protected] 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.
>