Re: Propsed new issue: variability of encoding in Miffy

Jacek Kopecky wrote:

> Let's keep in mind that usually (at least in optimized SOAP
> implementations) if binary was used, nothing would be encoded in base64.
> So we wouldn't be recoding into base64 something which was already
> base64 encoded.
> 
> I still wonder if MIFFY would be used in environments which are not
> 8-bit safe. I first suggested that we mandate binary, and somebody
> replied that such packages couldn't be transmitted over email. True, but
> if it's the binding that chooses to use MIFFY, why couldn't email
> binding just choose to base64-encode the binary data into the XML? 
> 
> Or is there a value of having the big binary data outside the envelope
> even if it's not optimized in size? Is that where MIFFY should be used?
> 

There certainly are cases where the total size of the message is not 
issue, but the size of the optimized MIFFY Infoset is. For example, 
consider an intermediary processing a message which has a header 
(targeted toward the ultimate destination) containing a large chunk of 
binary data.

> Interesting discussion... 8-)
> 
>                    Jacek Kopecky
> 
>                    Systinet Corporation
>                    http://www.systinet.com/
> 
> 
> 
> 
> On Wed, 2004-01-07 at 17:23, 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? Or something
>>else.
>>
>>It would seem odd to base64 encode something which was already base64
>>encoded ( although obviously possible ).
>>
>>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, 14 January 2004 04:39:00 UTC