Subject: [EAI] Terminology "UTF8SMTP messages"

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 30 Mar 2007 20:00:47 +0200

Please note the following text from -framework:

   In this document, an address is "all-ASCII", or just an "ASCII
   address", if every character in the address is in the ASCII character
   repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address",
   if any character is not in the ASCII character repertoire.  Such
   addresses may be restricted in other ways, but those restrictions are
   not relevant to this definition.  The term "all-ASCII" is also
   applied to other protocol elements when the distinction is important,
   with "non-ASCII" or "internationalized" as its opposite.

   The umbrella term to describe the email address internationalization
   specified by this document and its companion documents is "UTF8SMTP".
   For example, an address permitted by this specification is referred
   to as a "UTF8SMTP (compliant) address".

By symmetry, the term "UTF8SMTP message" should be reserved for the set of 
messages that encompasses both RFC 2822 compatible messages and messages 
which make use of the extensions defined in the memos we are discussing).

Unless people want to reopen the -framework document and change this 
terminology, I'm declaring the issue of the term "UTF8SMTP message" a 
closed one.

But that's not the end of naming.

For the headers, talking about "ASCII header" and "non-ASCII header" makes 
sense, but for the whole message, it seems to be a bad fit, given the wide 
range of non-ASCII stuff that goes into message bodies.

Better suggestions?

                 Harald

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 31 Mar 2007 12:09:01 +0200

Harald Tveit Alvestrand wrote:

> the term "UTF8SMTP message" should be reserved for the set of

> terminology, I'm declaring the issue of the term "UTF8SMTP message" a

Either we're in violent agreement, or I've no clue what you're talking
about.  A _valid_ message/rfc822 is always also a valid "message/utf-8"
or "UTF8SMTP message".

1: Maybe "UTF8SMTP message" is more general, if it covers more subtypes
   than only "utf-8", i.e. other subtypes specified in the DSN draft.
   These other subtypes are only used as MIME parts, they are unrelated
   to the "Internet Message format" (= message objects transported by
   UTF8SMTP or similar protocols, UTF8NNTP, UTF8UUCP, etc.)

2: Because message/rfc822 is a proper subset of message/utf-8, there's
   another proper subset "non-rfc822 message/utf8".  Apparently we have
   no shorthand for this yet.

3: An "invalid" message/rfc822 with raw 8bit characters in its header,
   using an unknown 8bit charset, is also interesting.  So far I claimed
   that this is never a valid message/utf-8, and therefore more or less
   irrelevant for us.

4: "Some" folks - where "some" could be anybody but me here - extend the
   concept of "UTF8SMTP messages" also to MIME version 1.0 part headers,
   and define that messages with UTF-8 in Content-* header fields are
   also implicitly message/utf-8.  Others - maybe only me - claim that
   that's implicitly a new MIME version, and tagging it explicitly in
   a MIME version header field could make sense.

   Implicit or explicit, the MIME version doesn't propagate into or out
   of embedded message parts, a traditional message/rfc822 can contain
   message/utf-8 parts without changing its top level MIME version 1.0.
   And v.v.  Of course a 7bit message can't contain 8bit / binary parts.

> But that's not the end of naming.

Getting the terminology right could help to get the drafts ready.  The
"framework" RFC doesn't go into these MIME details,  The "headers" I-D
should do this, or outsource the question to a separate I-D with a 100%
clear message/utf-8 definition.  Most technical details are already
worked out, IFF message/utf-8 implicitly allows UTF-8 in Content-* and
any MIME part header fields, then identifying a message/utf-8 requires
to parse the MIME structure - maybe including the internal structure of
"well-known" subtypes of embedded message parts.

I'd like a separate draft:  The other drafts could build on it, and to
some degree they're not affected by the fine print of this definition.

Possibly we'll arrive at a "MAY declare an explicit MIME version 2.0"
for message/utf-8, and a SHOULD for other message subtypes using UTF-8
in their internal MIME part headers.  Or a SHOULD / MUST solution.

> Better suggestions?

Get some external MIME experts.  Let's use "invalid message/rfc822"
for anything with unknown 8bit octets in its header (or "headers" for
folks wanting an implicit MIME upgrade), and let's decree that this
(= unknown 8bit) is out of scope.

How about "non-ASCII message/utf-8" for a valid message/utf-8 that's
not a valid message/rfc822, because it uses raw UTF-8 in its header
(or its "headers" resp.) ?

Let's say that "message/utf8" and "UTF8SMTP message" are synonyms in
most cases, unless the use of UTF8SMTP is limited to the envelope at
a particular UTF8SMTP hop.

Frank