ietf-822
[Top] [All Lists]

Re: Character-set header (was Re: Minutes of the Atlanta 822ext meeting)

1991-09-11 08:36:19
From the bottom up:
Excerpts from transarc.system.ietf-822: 11-Sep-91 Re: Character-set
header (w.. John C Klensin(_at_)infoods(_dot_)m (3681)

 Case 3.1: one is found that specifies "none required"
    the klensin-has-flipped-out header is discarded in the converted 
    message.

The message is bounced if it contains octets with the high bit set. 
Otherwise, the klensin-has-flipped-out header is discarded in the
converted message.

Now, while I love the name of the klensin-has-flipped-out header, and I
hope that John reaches some kind of immortality some day, I really hope
that he has indeed paranoiaed-out, and that he shouldn't worry so much
about what 8-to-7 converters might do.  I think it's perfectly
reasonable for the message source to make a suggestion for a 7-bit
conversion algorithm, but to bounce if the suggestion is absent?

I suppose if a ``Content-suggested-encoding:'' header were made
mandatory for automatic conversions, then message composer who feel as I
do would simply always add such a header.  The only downside is if a
message composer doesn't want to take the trouble of specifying a
conversion algorithm, this removes that flexibility.  How about a
special value for the ``Content-suggested-encoding:'' header of ``ANY'',
meaning that the composer wants to allow an 8-to-7 gateway the freedom
to choose any algorithm.  This adds case 3.4 to John's list:
    Case 3.4: The klensin-has-flipped-out/content-suggested-encoding
    header exists and specifies a value of ANY.  The agent may
    choose any of the standard (specified in RFC-XXXX) transport
    encodings.

Actually, there is another minor downside to this idea.  8-to-7
converters would then *have* to know how to perform all the standard
transport encodings.  Before this suggestion, they would be free to know
only a non-empty subset of them, and choose one.  Given this suggestion,
they would have to know how to use them all for encoding, because any of
them could appear in the
klensin-has-flipped-out/content-suggested-encoding header.  This might
be a considerable burden in terms of the large table space required for
the quoted-readable or quoted-printable encodings.

What do folks feel about making it mandatory for all 8-to-7 gateways to
know all legitimate encodings?  How burdensome is this?

                Craig

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