Quoting: John C Klensin <KLENSIN(_at_)infoods(_dot_)mit(_dot_)edu>
Allowed Header-Tranfer-Encoding types are:
....
- 8-bit
This would, of course, require agreement (however that is determined)
on an 8-bit transport arrangement.
Surely, we forgot to mention that.
- ISO-10646
Out of date. (We suppose ISO-10646-ACU will be used instead)
Again, I don't think we disagree but, since minor misunderstandings on
this list have periodically led to major explosions, (i) there never has
been an ISO 10646, there has only been First DIS 10646. The latter is
obsolete, the former has not yet existed. See above for remarks on the
AUC (I assume that is what you meant) proposal.
Correct, we don't disagree. (We were referring to the "ISO-10646"
subtype of text in RFC-XXXX.)
(5) Quoted-readable/Mnemonic
Your proposal says...
Note that we only have to introduce extra quoting because of the character
set only arise if we use Quoted-Readable, ISO-2022 and ISO-10646-AUC.
I don't understand the problem in this situation with Mnemonic.
What we meant was that when using Mnemonic, there are glyphs which
contain characters of the RFC822-lexical-type "specials", for example
"," and which then have to be quoted. In quoted-printable-encoded
ISO-Latin-1 there are no such problems, except for the "specials"
glyphs themselves.
Headers:
Subject:
Comments:
Content-Description:
Summary: (from RFC-1036)
Organization: (from RFC-1036)
I would appreciate a comment from the chair on this, but I think IETF
should be quite reluctant to authorize, or specify treatment for, header
fields for which Internet standard, or at least standards-track,
descriptions, do not exist in a standards-track proposal. An
I suppose you are referring to the last to. Ok, remove them!
(... and consider it as a suggestion for the RFC-1036-update people)
...and all user-defined fields in RFC-822.
I don't understand what this is intended to mean. If you are
referring to the X- fields, the comments above apply even more strongly:
I don't know how one can specify things one hasn't seen, and whatever
agreements govern the use of these fields can also include their
interpretation.
But can you not have a default treatment of them, for example that
they are "*text" and covered by the two new "Header-"-fields, if
nothing else is agreed upon?
At the beginning we had RFC-822. It defined the characters in the headers
to be 0-127. Some parts of the headers included special characters.
No, it didn't. This has been the source of much of the confusion and
criticism of the last few days. It defined the characters in the
headers to be [US] ASCII, ANSI X3.4, not semi-arbitrary patterns of 7
bits.
Well, it has been the source of lots of misunderstandings! By "special
characters" above, Patrik meant the RFC822-lexical-type "specials".
When I said...
The users will naturally want to continue to use our special
characters, as they allways have.
...I meant special glyphs, as a diaeresis, so far stored in 7-bit
ISO 646.
We have *never* *ever* tried to justify the use of anything other than
7-bit characters in (pre-RFC-XXXX) mail!
When we start to use more characters that the 0-127 we have to encode
them in some way. Why not do that in the same, or at least equivalent way,
as the Body of the mail. We therefore saw the possibility to introduce
the Header-Transport-Encoding and the Header-Type.
Strictly speaking, the first sentence above should begin "When we
start to use any characters, or interpretations of character positions,
that are not in [US] ASCII (ANSI X3.4), we have to encode...". In other
words, while no implementation has been able to detect the violation or
enforce the rule (perhaps fortunately), use of a national variation on
ASCII has technically always required some encoding.
I agree, but what should we have done, back in the beginning of the
1980'ies? Communicated in english until some RFC let us do it in
swedish ;-) ?
---
Peter