Re: Propsed new issue: variability of encoding in Miffy

I disagree. This would make it impossible to transport MIFFY documents 
across non-binary transports interoperably; while this isn't a problem 
for HTTP, it certainly will be for SMTP and other MIME-like transports. 
While it's true that it can be direct base64 in the documents, 
mandating this would require SMTP gateways to be MIFFY-aware, even when 
they aren't doing anything to the document.

I could entirely see this restriction in the MTOM HTTP binding, however.

Regards,


> I believe MIFFY should mandate the content-transfer-encoding to be
> binary because that is the whole point of the optimization. If the data
> has to be transcoded, it can as well be in base64 form directly in the
> XML document.
>
> With wishes of a happy year 2004,
>
>                    Jacek Kopecky
>
>                    Systinet Corporation
>                    http://www.systinet.com/
>
>
>
>
> On Thu, 2003-12-18 at 18:43, noah_mendelsohn@us.ibm.com wrote:
>> Anish Karamarkar writes:
>>
>>> 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.
>>
>> I suspect your memory is right.  Mine is surely unclear.  I don't 
>> think
>> this much affects the rest of the discussion.
>>
>>> 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.
>>
>> Thank you, that's helpful.  I'm not a MIME expert.  I think there are 
>> (at
>> least) two reasonable design options from which we should choose:
>>
>> * Say that for Miffy it's fixed at binary and that, as you suggest, 
>> you
>> must specify the content-transfer-encoding.  The consequence will be 
>> less
>> code for Miffy-specific receivers and perhaps better interop with
>> receivers that are too lazy to follow the rules and implement all the
>> common forms.  Presumably, this decision would make Miffy 
>> inappropriate
>> for less capable transports.
>>
>> * Allow any content-transfer-encoding at the Miffy level, but fix it 
>> at
>> binary in our HTTP level.  This means that there may be legal Miffy
>> serializers that cannot be used to generate content for our HTTP 
>> binding,
>> but at least all receivers would accept all legal content.
>>
>> I remain reluctant to burden minimal SOAP implementations with dealing
>> with a variety of these.  This is code one will wish to optimize with
>> respect to things like sharing buffers between the I/O system and
>> applications, at least in certain cases.  There may also be 
>> optimizations
>> necessary to make DSig perform.  I am reluctant to burden SOAP
>> implementors with having to get this stuff right for a variety of
>> encodings, unless there is real value.  I think MIME is designed at a
>> broader and often less performance-critical set of applications than 
>> MTOM.
>>
>>> 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
>>
>> Thank you.  I found your note very helpful.  Does the above sound at 
>> least
>> like the right short list of alternatives?
>>
>> Noah
>>
>> --------------------------------------
>> Noah Mendelsohn
>> IBM Corporation
>> One Rogers Street
>> Cambridge, MA 02142
>> 1-617-693-4036
>> --------------------------------------
>>
>>
>>

Received on Monday, 5 January 2004 18:26:32 UTC