RE: Propsed new issue: variability of encoding in Miffy

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?

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, 7 January 2004 11:48:30 UTC