- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Wed, 7 Jan 2004 08:17:38 -0800
- To: "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, <noah_mendelsohn@us.ibm.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
I would think that they don't; they're completely transparent to the entity after MIME processing. On Jan 7, 2004, at 7:38 AM, Martin Gudgin wrote: > > 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: xml-dist-app-request@w3.org >> [mailto:xml-dist-app-request@w3.org] On Behalf Of Anish Karmarkar >> Sent: 17 December 2003 19:37 >> To: noah_mendelsohn@us.ibm.com >> 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 >> -- >> >> noah_mendelsohn@us.ibm.com 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 >>> -------------------------------------- >>> >>> >>> >>> >> >>
Received on Wednesday, 7 January 2004 11:24:51 UTC