Re: Propsed new issue: variability of encoding in Miffy

Anish, Noah, others,

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 Sunday, 4 January 2004 09:39:00 UTC