At 9:52 PM 10/27/94, Mr Rhys Weatherley wrote:
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.
Canonicalization is not a transport issue to begin with. Canonicalization
occurs before transport begins and decanonicalization happens after it ends.
I realize that in practice some transports perform these operations during
transport, and most especially with text material. However, this is not part of
the model and as such any transport that undertakes to do this must insure that
it re-does anything it un-did.
In the case of binary a transport I believe the tradeoffs are such that the
content is best left alone and never transformed. But this is just
implementation advice and nothing more. It is both impossible and inappropriate
to mandate this. For example, some message queues encrypt their contents. Are
we going to forbid this because of our insistence on no transformations? And if
we do forbid it, what check can we devise that will tell the difference
between, say an implementation that ROT13s and un-ROT13s everything that passes
through and one that doesn't?
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?
I completely agree. And this is not limited to text -- I may have a specialized
way of storing GIF files on my system that doesn't correspond to the canonical
format for GIF. (This is a real world example, unfortunately.) I don't care if
the GIF file arrives over base64 or binary or whatever, when I go to store it
in local form I have to transform it into what the local applications expect.
And similarly, when I mail out a GIF file I have to canonicalize the damn thing
before it reaches the transport.
All this happens, however, during the initial posting operation and either
during the final delivery or viewing operation. As far as the standards are
concerned it doesn't happen in the middle of transporting the message. And if
it does happen it has to be done invisibly.
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.
CRLF maybe, but in general you can't assume that all non-text types are
automatically not subject to some form of canonicalization. The world is simply
too heterogenous for this approach to be viable on all platforms!
Ned