ietf-822
[Top] [All Lists]

Re: RFC 2047 and gatewaying

2003-01-10 16:07:48

D. J. Bernstein wrote:
Bruce Lilly writes:

But that is only for display -- hardly a critical issue.


Display is a critical issue. The reason that we aren't satisfied with
ASCII is that it doesn't let us display most of the glyphs that people
want to see.

I didn't say it was unimportant; I said it was not critical in the
same way that transmission protocol issues are critical. Display
issues can be resolved largely independently from other issues and
infrequently involve compatibility or interoperation issues
(unfortunately due to differences in utf-8 specifications and Unicode
versions, such issues *do* affect utf-8 encoded Unicode, but
they do not affect transmission protocol issues in Internet text
messages).

user-defined fields are required to begin with "X-"


False. See RFC 822.

False only if one is willing to have a user-defined field pre-empted
by a properly-standardized extension field with the same name. "X-"
is used specifically to prevent name space clashes of that sort. And
the distiction between user-defined and extension fields is not
present in RFC 2822.

> Anyway, this is irrelevant to the discussion. As
you've now admitted, the locations of RFC 2047 encoded words are not
stable: they are affected by RFCs specifying new header fields.

So what's your point? If a newly-defined Internet text message header
field isn't recognized by a particular reader UA but contains 2047/2231
encoded-words:
1. no transmission issues are affected
2. there are no gateway issues
3. that UA can be upgraded without affecting any other software,
   without affecting message delivery, gateway operations, etc.
4. since 2047 applies only to comments and phrases for display,
   there can be no adverse effect on any protocol-related issues;
   parameters in currently-defined header fields which permit
   parameters and can use encoded-words aren't supposed to be
   automatically used for anything (i.e. w/o user confirmation),
   and it would be unwise for any newly defined header to set
   such a precedent.
5, The reader UA can either assume the field is unstructured and look
   for encoded-words accordingly or it can present the header field
   text verbatim. Or (mind you, we're talking about for *display* only)
   it could even use a Charles Lindsey-style heuristic. It's not
   *critical*.
6. the (human) reader can in any event look at the raw content and
   determine (a) the charset, (b) the language (where applicable),
   (c) the encoding method, and (d) the encoded text.  In raw
   (untagged) presumed-utf-8, he only can determine the encoded-text
   which might not be utf-8 at all.
7. Congratulations -- you have just added to the argument that the
   Usefor draft is unworkable; every time a new field is introduced
   all gateways would have to be instantly updated for the Usefor
   draft proposal to be workable, and that is clearly impossible.

How frequently are new structured fields that might use encoded
words standardized?  Not terribly often -- certainly a subset
of structured fields (e.g. Content-Features cannot have encoded-words),
which in turn is a subset of all new fields.  How frequently are
ambiguities w.r.t. 2047/2231 encodings introduced by such new structured
field definitions? Rarely -- the only example I can think of which *might*
be ambiguous is RFC 3335's Received-Content-MIC field, which uses the ABNF
element "value" (by way of RFC 1847 "micalg") outside of a MIME
parameter (for which "value" was defined in the MIME base RFCs and
changed by RFC 2231; "micalg" is not used elsewhere other than in
MIME parameters); as such "value" as modified by RFC 2231 might include
an RFC 2231 extended values.  Does Received-Content-MIC affect Usenet? No.
Is it likely that an RFC 2231 extended value will have to be used in a
Received-Content-MIC field due to (a) charset for a micalg, (b) langauge,
or (c) parameter length? No, no, and no.  Is it likely that an end user
(as opposed to a developer of application software using Received-Content-MIC
fields) will need to display Received-Content-MIC fields decoded? Never.


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