Re: Propsed new issue: variability of encoding in Miffy

I hate to break into the discussion, but I think that you guys may be 
over-engineering.

7bit and 8bit are *text* encodings.  As such, they permit padding of 
lines with whitespace, stripping whitespace, and conversion of line 
terminators to NVT ASCII normal form (CRLF).  I do not believe that you 
can safely convert binary to either encoding and back again without the 
possibility of lossage.  base64 was invented to permit transport of a 
complete eight-bit octet over a seven-bit transport (gatewaying to 
five-bit transports or similar crude tricks remains the province of 
unstandardized gateway-specific algorithms).  In other words, I think 
that this is out of scope.  Although it's possible that I've converted 
common practice into a requirement.  I do believe someone should swot 
up the specifics before going further, 'cause I think it's irrelevant 
to transport of binary materials.

Amy!
On Wednesday, January 7, 2004, at 12:04  PM, Martin Gudgin wrote:

>
> 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:[email protected]]
>> Sent: 07 January 2004 16:58
>> To: [email protected]
>> 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
>>
>>
>