RE: Propsed new issue: variability of encoding in Miffy

> > I'm being a bit dense here: which 5 encodings are we talking about? 
> > Thanks.
> 
> The ones Anish listed: 7bit, 8bit, binary, quoted-printable, base64 

OK, thanks.

> 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.

Which is exactly why I'm confused.  My assumption was that at the Infoset 
level, we talk of XSD types, and we've so far made a decision to provide 
special-case handling only for xsd:base64Binary.


The encodings above then become a question of how do you serialize what is 
logically binary (value space) but appears to be base64Binary encoding 
(lexical space) in the Infoset.  Like you, I had assumed the answer was: 
as a 'binary' MIME part, typed as either application/octet-stream, or 
perhaps with a type like image/jpeg if we knew that from something like an 
Infoset attribute.  I think we're being challenged to carry the same kind 
of data through transports that support multipart but not Binary.  If 
indeed that's a requirement, then I assume the options include re-encoding 
(not encoding) resulting in a base64 part, but then it's not clear why 
you'd use multipart and MTOM at all.  I'm still a bit puzzled about why 
the 7bit, etc. solve a problem.  Now, if we were trying to do something 
with xsd:string I might understand that, but we're not.

(usual caveat about my lack of MIME expertise)

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 7 January 2004 11:40:03 UTC