Re: Propsed new issue: variability of encoding in Miffy

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 Thursday, 18 December 2003 12:44:21 UTC