ietf-822
[Top] [All Lists]

Re: Lessons Learned from a Foreign Culture

1994-10-28 08:51:18
That was the way I always understood it.  If the transport is free to mess
with the contents then we will be stuck with base64-grottiness forever.

I believe that the transport's "freedom to mess with the contents" is
limited to the appropriate canonicalizations and decanonicalizations as
required by the content-type/content-subtype.
 
        Help me out,  Steve.   I've deleted a bunch of mail, 
so I might have missed something.   To transfer agents now act upon the 
Content-Type?   The whole reason why MIME was created was  (I thought) 
to save ourselves from the evils that the transfer agents might do. 
 
        Over in the WWW world everyone's saying  "we're 8-bit clean" 
and other things.   There the server really does interpret the CT value. 
So in WWW some people want to "loosen" MIME a bit.   But that's there. 
 
I do not believe that the CTE: should have any effect on
canonicalization/decanonicalization of a data type.  Text encoded in base64
gets canonicalized first.  Why should text "encoded" in "binary" not also?
 
        The canonicalization of  CT text/plain  with  CTE Base64 
must be handled by the user agent.   The transfer agent is oblivious. 
There's another canonicalization that *is* handled by the transfer agent 
when you're sending from or to a CDC Cyber.   (what was the name of that 
character set?)   CT text/plain  with an absent CTE leaves canonicalization 
completely in the hands of the transport agents  (of which there will 
always be more than one). 
 
        I got the feeling that  CTE binary  was an attempt to either 
shift responsibility for canonicalization from the user agent to the 
transfer agent  -or-  just shut off canonicalization altogether. 
The former will not give the desired results.   The latter cannot be 
accomplished because it is out of the user agents' control. 
 
I'd like to see a gradual progression to a world that can send real
binary parts, labelled as such, and avoid encodings which add 33% to the
size of the message.
 
        Rhys,  is that all you're after?   A 33% savings?   Don't get me 
wrong,  there's nothing bad about that objective.   But you're going to 
be disappointed if you continue pursuing CTE binary.   Maybe what you 
want is SIFT/UFT.   Now there's a transport that can do binary without 
the 33% overhead,  as well as multiple files, both mail and non-mail, 
print.   It's kind-of like the inverse of HTTP or Anonymous FTP. 
Too bad the only implementation is by some kid in Houston with ADD. 
 
That's not at all incompatible with what I'm saying.  I'm not saying that
CTE: binary is *always* subject to newline canonicalization; I'm saying it
is only subject when the type itself is subject.  CRLF in, say, image/gif
is unaffected.
 
        This isn't going to happen because the transfer agent will do 
newline canonicalization  whether the user agent likes it or not. 
 
--
Steve Dorner, Qualcomm Incorporated.  "Oog make mission statement."
 
-- 
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems 
"People respond, then they fall away.   Just want your help for a day" 
        -- Bob and Jayne