RE: Propsed new issue: variability of encoding in Miffy

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:23:34 UTC