Re: Proposal for Miffy MIME Headers

[email protected] wrote:

> Anish Karamarker writes:
> 
> 
>>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.
> 
> 
> Well, I'm not sure.  The only way we get legal MIME parts into a Miffy 
> document is if they are encoded in the way our specification mandates. The 
> responsibility of any Miffy "interpreter" is to understand that 
> representation, whether or not content-transfer-encoding is specified.

Agreed.
But if content-transfer-encoding is not specified then it defaults to 
7-bit. Which won't apply to most of the Miffy use cases (at least what I 
envision as to where Miffy would result in the most benefit). In most 
cases, the content-transfer-encoding would  be 'binary' (unless a 
transport such as SMTP is used, in which case it prabably will be 'base64').

> I 
> certainly agree that if specified the content-transfer-encoding must not 
> lie, and I think it might be of use to generalized non-Miffy-aware tools. 
> I'm not sure I see how its presence would affect the processing that would 
> otherwise be done by a Miffy interpreter.
> 

If the content-transfer-encoding is 'base64' then the Miffy interpreter 
would have to apply the correct decoding.

> I think this may boil down to reconfirming that Miffy offers no 
> optionality in the encoding used, regardless of whether the header is 
> present.  Agreed?  Thanks.

Pl see my other email (sent in response to your email sent to 
xmlp-comments).

Thanks for raising the issue on xml-comments.

> 
> BTW:  I think the term "interpreter" is somewhat confusing, but that's 
> what the current Miffy draft calls it.
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
>