Re: Propsed new issue: variability of encoding in Miffy

On Jan 7, 2004, at 8:23 AM, Martin Gudgin wrote:

> Mark, are saying that it is trivial to convert any of the five to
> base64? Or that the 5 are identical 'above' the MIME layer?

The latter.

> It would seem odd to base64 encode something which was already base64
> encoded ( although obviously possible ).

But it isn't; on the wire, it's the binary octets. Some transports are 
capable of handling binary data, hence content-transfer-encoding.

> FWIW, I'd kind of assumed we'd just use binary everywhere.
>
> Gudge
>
>> -----Original Message-----
>> From: Mark Nottingham [mailto:mark.nottingham@bea.com]
>> Sent: 07 January 2004 16:18
>> To: Martin Gudgin
>> Cc: Anish Karmarkar; noah_mendelsohn@us.ibm.com; Xml-Dist-App@W3. Org
>> Subject: Re: Propsed new issue: variability of encoding in Miffy
>>
>> 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:48:29 UTC