[Top] [All Lists]

Re: Content types and encodings

1991-08-28 04:56:30
Vincent, Bill, and others...
  I want to add one comment to the remarks from Ned and Mark, without 
agreeing (or disagreeing) with those remarks:
  We have a controversial mess in the 8bit transport area.  We may -- or 
may not -- be on the verge of resolving that mess with an approach that 
people can live with.  But the proposed agreement there (relative to what 
"transport encodings" are permitted and where they are applied) is 
critically dependent on an assumption of RFC-XXXX.  And that assumption 
is that there are a rather small, and very closed, set of types.  
Similar problems apply to gateways, especially into networks who native 
character sets are different from that of the Internet.
  If the number of types is small and closed, it is possible to conceive 
of gateways and converting relays doing their conversions one body part 
at a time, understanding (at the "type" level) what they need to do.  If 
it becomes large and/or open, then one must do one of the following
(there are really no other alternatives) 
  -- learn to live with "encapsulation" models instead of message 
conversion that preserves text as text.  These "encapsulation" modes are 
worse than what most people have been thinking about when they talk 
about nested encoding.
  -- include (and require) additional fields or header lines in RFC-XXXX 
that provide explicit advice or direction to converters, gateways, etc.  
The hypothesis is that this information would either closely resemble 
the current primary content-type subfield (including the "small number" 
and "closed" parts, or that it would quickly become very complicated.
  -- adopt a variant on an X.400-like model in which parts of messages 
that were not recognized at any point in the transport process were 
simply discarded.
   My impression--which could easily be wrong--is that there is general 
agreement that each of the above three options is pretty abhorrent.

So, reopening this issue has significant implications all over the email 
landscape, not just in how UAs interpret things.

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