RE: Propsed new issue: variability of encoding in Miffy

OK, I think I get it. Let's see...

I have a jpeg with at the binary level is a bunch of octets and at the
Infoset level is a bunch of base64 characters.
when this goes over an 8-bit clean transport, it can go as binary and
everything is fine. If it has to go over a none 8-bit clean transport
then it will be CTEed to 7-bit ( or possible base64 or quoted-printable
). But at the binary level it's still the same bunch of octets and at
the Infoset level it's the same bunch of base64 characters.

So I think what it happening here is that when things are sent a binary
( and 8-bit? ) no encoding/decoding occurs at the MIME level. For 7-bit.
base64 and quoted-printable encoding/decoding happens at the MIME layer.
In all cases the octets at the layer above MIME are the same.

Is this correct?

Gudge

> -----Original Message-----
> From: Mark Nottingham [mailto:mark.nottingham@bea.com] 
> Sent: 07 January 2004 16:58
> To: noah_mendelsohn@us.ibm.com
> Cc: Martin Gudgin; Anish Karmarkar; Xml-Dist-App@W3. Org
> Subject: Re: Propsed new issue: variability of encoding in Miffy
> 
> An example:
> 
> I want to send a MIFFY-optimized SOAP message to Bob using a 
> Mail binding. To get to him, it'll have to go through the 
> following message
> path:
> 
> Me
> --[SMTP]-->MyLocalServer--[SMTP]-->BobExternalServer--
> [PrivateMailProtocol]-->BobInternalServer--[POP]-->Bob
> 
> Furthermore, let's imagine that the PrivateMailProtocol 
> between BobExternalServer and BobInternalServer can't handle 
> binary data; i.e., it's not 8-bit clean. Such things do 
> exist, especially in legacy enterprise mail systems.
> 
> So, I can send a MIFFY-encoded document to my local server as 
> a multipart MIME message with binary attachments, and it will 
> work just fine. It can forward it to BobExternalServer 
> without any changes to the encoding.
> 
> However, BobExternalServer is in a bit of a pickle; it's 
> acting as an SMTP gateway to a legacy system that can't 
> handle that message. In MIME, there's an easy solution to 
> this; Content-Transfer-Encoding, which allows you to encode 
> parts of the message so that they're safe for transport.
> 
> If we disallow CTEs other than binary, BobExternalServer will 
> be forced to either refuse the message, or to understand 
> MIFFY and encode the message as an XML Infoset. Given that 
> deployment of MIME Content-Transfer-Encoding is pretty 
> universal (thanks to literally decades of coordination in the 
> IETF), and the footprint of MIFFY is currently exactly zero, 
> I think it's an easy choice. :)
> 
> This isn't a problem in HTTP, because it doesn't have this 
> legacy. Of course, if HTTP gateways to another protocol, that 
> restriction won't apply, and I think that's a good thing (see above).
> 
> --
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
> 
>

Received on Wednesday, 7 January 2004 12:04:32 UTC