ietf-822
[Top] [All Lists]

another potential content-type suffix convention

2000-03-14 21:02:45
for what it's worth (which might not be much)

just as a strawman example of another possible content-type suffix:
(I thought of this a few years ago, but it's taken awhile to remember it
in the context of recent dicsussion.)

some binary-transparent mail transports are LF-native, others are CRLF-native.

by binary-transparent I mean that all the bits will go from source to
destination undisturbed.

by LF-native I mean that when using this transport, unencoded
text objects use LF as a line terminator.  UUCP and UNIX mailbox
files fall in this category.  

by CRLF-native I mean that when using this transport, unencoded
text objects use CRLF as a line terminator.  BINARY SMTP falls
in this category.

now if you have a MIME message with some of its contents labeleled
with content-transfer-encoding: binary, and it traverses the boundary
between an LF-native and CRLF-native transport, some of the 
"binary" objects may need to be converted from LF to CRLF or
vice versa. 

you can safely convert the text/* objects, because (IIRC) the definition
of text/* specifies that bare LF should not appear.  but what
about application/*, audio/*, etc objects that just happen to
use text as an underlying format?  can you convert these or not?

if you do convert, you will corrupt some objects that are not text.
if you don't convert, the recipient will get some objects that
are not in the right format for his platform.

the problem is that even though MIME specifies canonical format,
in practice, some content types use different canonical formats depending 
on the transmission medium.  you can gloss over these differences
unless you're using binary MIME.

one idea to solve this problem (not necessarily a good one)
was to define a content-type suffix (say -text) to denote
content-types that used text as their underlying format.

that way, the gateway between CRLF-native and LF-native
would know to convert line endings for text/* and */*-text
but would not convert line endings for other content types.


now if we also had -xml then the gateway might need to know
about -xml (with slightly different conversion rules)
in addition to -text.  or should XML objects be -xml-text? 

Keith

p.s. IIRC the rule we eventually agreed on (not sure whether
it's documented anywhere) was "don't send binary MIME over
LF-native transports".   much simpler and vastly preferable.
another good rule would be "nobody but the recipient 
can convert things into binary"

<Prev in Thread] Current Thread [Next in Thread>