RE: Propsed new issue: variability of encoding in Miffy

The main thing we need to specify here is how each of the 5 encoding
manifest at the infoset level, that is, what character information items
appear.

Gudge 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Anish Karmarkar
> Sent: 17 December 2003 19:37
> To: [email protected]
> Cc: Xml-Dist-App@W3. Org
> Subject: Re: Propsed new issue: variability of encoding in Miffy
> 
> 
> [Discussion moved to xml-dist-app from xlmp-comments]
> 
> Noah,
> 
> Not sure what you meant by '... labeled as 
> application/octet-stream ...'.
> 
> My understanding is that, we have agreed that the MIME parts 
> may have Content-Type other than application/octet-stream 
> (although that is the default). For example, I may want to 
> indicate that the binary data being sent is image/jpeg or text/plain.
> 
> Looking at RFC 2045, the default value for 
> content-transfer-encoding is "7-bit". If in our spec we are 
> not going to allow variability for content-transfer-encoding 
> (for non-root parts), then we must require that each MIME 
> part that is referenced from the root part must have the 
> content-transfer-encoding MIME header with a value of 
> 'binary' (least restrictive).
> 
> This might be a problem for more restrictive transports that 
> require 7-bit clean data (SMTP). Also, my understand of MIME 
> is that it is very "un-MIME"-like to restrict 
> content-transfer-encoding. But, I am not a MIME expert, so I 
> will let the experts on the list comment on this.
> 
> I am not too worried about interop as there are only 5 
> well-known content-transfer-encodings (7bit, 8bit, binary, 
> quoted-printable,
> base64) + the extensible X-myproprietary-encoding.
> 
> Thanks.
> 
> -Anish
> --
> 
> [email protected] wrote:
> 
> > 
> > 
> > 
> > 
> > This is in fulfillment of an action item that I took on 
> today's call 
> > to request openning of an action item.
> > 
> > I had always assumed that in Miffy, all the parts except the root 
> > would be octet streams, probably labeled as 
> application/octet-stream 
> > and sent in 8-bit format.  Anish mentioned on the call today his 
> > assumption that a range of representations would be allowed on the 
> > wire, providing that content-transfer-encoding would be 
> correctly set 
> > to indicate the representation used.
> > 
> > The tradeoffs appear to be:  a) variability is more flexible b) 
> > variability requires that all receivers/interpreters be capable of 
> > decoding all encodings if universal interop is to be achieved c) 
> > neither of us was sure whether the decision to fix the 
> representation 
> > might be taken as a misuse of MIME.
> > 
> > The purpose of this note is to request that we open an issue to 
> > resolve these questions.
> > 
> > --------------------------------------
> > Noah Mendelsohn
> > IBM Corporation
> > One Rogers Street
> > Cambridge, MA 02142
> > 1-617-693-4036
> > --------------------------------------
> > 
> > 
> > 
> > 
> 
>