W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2004

Re: Propsed new issue: variability of encoding in Miffy

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 7 Jan 2004 08:17:38 -0800
Message-Id: <02B45C42-412D-11D8-8FD6-00039396E15A@bea.com>
Cc: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, <noah_mendelsohn@us.ibm.com>, "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
To: "Martin Gudgin" <mgudgin@microsoft.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC