Paul A Vixie writes:
to that end :-), let me spec a little of this out:
message :: headers blank-line body
headers :: header [...]
body :: line [...]
Sounds like RFC822 to me. I don't think anyone is proposing that RFC822
be changed in an incompatible way, only extended. Since RFC822 covers this
spec as well as a lot of other stuff, why not just say we're sticking with
the framework defined there?
i'd like to keep the name part of the header (everything to the left of the
colon) spec'd to 7-bit ASCII. i'd like all the reserved words in complex
headers like "received:" to 7-bit ASCII. actual text (like the subject
field or the full-name/comment parts of to/cc/from) should somehow be
allowed to be 8-bit. i don't know what to suggest for the stuff inside of
<brackets> in to/cc/from. the restrictions on domain names (anything to
the right of an @) should be whatever DNS spec's, which is probably 7-bit
ASCII.
While the business about holding header labels to 7 bit is not
explicitly mentioned in RFC-XXXX, it is implicitly there, since the
existing standards say they have to be 7 bit and RFC-XXXX does not
extend this.
without saying anything about body parts or encodings, i'm already into
an 8-bit transport. if a message that has 8-bit data in its Subject: field
needs to be sent over a 7-bit transport, it has to be encoded. this
encoding needs to be something that a user or user-agent can make sense
of, since it may never reach another 8-bit transport and even if it does
i'm not sure it should be decoded back into 8-bit data. we can argue that
one. an encoding like \NNN where NNN is an octal number would suit those
of us in the UNIX(tm) community pretty well but we aren't the whole world
and no doubt a Norwegian recipient would rather not see a \221 where an
accented character would normally appear.
This has been hashed out endlessly; to separate the requirements from the
implied implementation, we obviously want these capabilities, and this
sort of approach seems generally like the right direction to be heading.
we may want to consider a new
encoding enumeration which is painful to generate or tear down but which
has equivilences which are chosen to be readable in their encoded form.
like i said, this can be argued.
See RFC-XXXX's scheme for doing this.
the headers will have to have some kind of magic cookie added to them
when a message (headers and/or body) has 8-bit data in it. this cookie
can be munched slightly when/if a transport or user-agent needs to
encode it into the "readable 7-bit" notation i mentioned earlier. i
believe that the presence of this magic cookie (really "a new header")
should tell anyone who cares about the distinction, that this message
conforms to the newer mail RFC's and all else that that may imply.
RFC-XXXX uses one approach that meets these criteria; without exception
all the counter-proposals for alternate approaches I've seen differ only
in the details (Charset: header, charset in first Content-Type field,
charset as a part of first Content-Type field, etc.)
let's try to agree on a framework with arguable variables, and then
argue about the variables. does anyone think that what i've said above
will work? (it's a restatement of what several other people have said,
so i know that *somebody* thinks it's reasonable). does anyone know a
reason why we cannot or should not start with the above framework?
Not only is it a restatement, I think almost all the proposals and
amendments currently being debated meet these criteria as well. In other
words, I think there's tacit acceptance of your set of criteria already,
and in fact there's general acceptance of considerably more than what you've
laid out, and we're well into the discussion of how the various details
get resolved.
If anyone disagrees with this broad outline, I'd like to hear about it.
(This assumes that the SMTP extensions discussion is separate,
which presently it is -- there's no general acceptable of much of anything
at that level.)
Paul Vixie
DEC Western Research Lab <vixie(_at_)pa(_dot_)dec(_dot_)com>
<paul(_at_)vixie(_dot_)sf(_dot_)ca(_dot_)us>
Palo Alto, California, USA ...!decwrl!vixie ...!vixie!paul
Ned