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:02:30 UTC