Subject: [EAI] Question about draft-ietf-eai-rfc5335bis-12.txt

From: Julien ÉLIE <[email-masked]>
Date: Wed, 05 Oct 2011 21:45:50 +0200

Hi all,

I have a few remarks about draft-ietf-eai-rfc5335bis-12.txt:

* Shouldn't a way to distinguish currently suggested UTF-8 from
a possible upcoming suggested encoding (UTF-32, UTF-128 or anything
that could be standardized in a few years) be provided?
Is "message/global" the way to know UTF-8 is expected?  Isn't it
necessary to mention UTF-8 somewhere (in a "charset" value)?

* Can an internationalized message contain a multipart content-type
using an UTF-8 "boundary" value?

* Can an example of internationalized message be added
to the document?

> 3.3.  Use of 8-bit UTF-8 in Message-Ids
>
>   Implementers of message-id generation algorithms MAY prefer to
>   restrain their output to ASCII since that has some advantages, such
>   as when constructing References fields in mailing-list threads where
>   some senders use EAI and others not.

Shouldn't "References: header fields" be written instead of
"References fields"?

> 3.4.  Effects on Line Length Limits
>
>   Section 2.1.1 of [RFC5322] limits lines to 998 characters and
>   recommends that the lines be restricted to only 78 characters.  This
>   specification changes the former limit to 988 octets.  (Note that in
>   ASCII octets and characters are effectively the same but this is not
>   true in UTF-8.)  The 78 character limit remains defined in terms of
>   characters, not octets, since it is intended to address display width
>   issues, not line length issues.

I am a bit puzzled.  Why does the specification changes the limit
to 988 octets?  I would have understood if it were 998 octets.

>   Background: Normally, transfer of message/global will be done in
>   8-bit-clean channels, and body parts will have "identity" encodings,
>   that is, no decoding is necessary.

Two spaces after ":", as it is already the case in the rest of the document.

>   This is expected to be rarely seen in practice, and the potential
>   complexity of other ways of dealing with the issue are thought to be
>   larger than the complexity of allowing nested encodings where
>   necessary.

Shouldn't it be in singular form?
("the potential complexity […] is thought"?)

[Section 3.7]
>   Encoding considerations:  Any content-transfer-encoding is permitted.
>      The 8-bit or binary content-transfer-encodings are recommended
>      where permitted.
[…]
>   Restrictions on usage:  This is a structured media type that embeds
>      other MIME media types.  The 8-bit or binary content-transfer-
>      encoding SHOULD be used unless this media type is sent over a
>      7-bit-only transport.

Shouldn't "content-transfer-encoding" be written similarly?  (either
in plural form or in singular form)

>  The normalization process is
>  described in Section 3.1 is recommended to minimize these issues.

The first "is" should be removed.

>      This media type provides
>      functionality similar to the message/rfc822 content type for email
>      messages with international email headers.

and:

>      Email clients that forward messages with international headers as
>      attachments.

"internationalized"?

-- 
Julien ÉLIE

« Rien, ce n'est pas rien ! La preuve, c'est que l'on peut le
  soustraire. Exemple : rien moins rien = moins que rien ! »
  (Raymond Devos)

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 5 Oct 2011 23:17:38 +0200

On 5 October 2011 21:45, Julien ÉLIE wrote:

Hi, I pick your easiest question:

>   a possible upcoming suggested encoding (UTF-32, UTF-128 or
>   anything that could be standardized in a few years) be provided?

All UTFs unsuited for MIME including those with NUL-octets like
UTF-32 will never be used for Internet messages.  All new Internet
protocols already MUST support at least UTF-8, that is an IETF
policy since 1998 stated in RFC 2277 (= BCP 18).

In theory UTF-7 and BOCU-1 are suited for MIME, but if you MUST
support UTF-8, and the protocols or document formats (= here the
message header fields) offer no way to negotiate something else,
it will be UTF-8.   It can be limited to subsets such as NFC; see
RFC 5198 for the details affecting all protocols remotely related
to Telnet (incl. WHOIS, SMTP, FTP, HTTP, NNTP).  Actually HTTP is
a special case, HTTP embraced Latin-1 before UTF-8 and RFC 2277
existed:  The HTTPbis WG has "fun" with this issue, but they are
certainly also trying to adopt UTF-8, not something else.

In other words, as far as the Internet is concerned we will get
UTF-8 everywhere, anything else would be science fiction.  In a
bold statement RFC 2277 predicts that this transition will take
at least 50 years.

> Is "message/global" the way to know UTF-8 is expected?  Isn't
> it necessary to mention UTF-8 somewhere (in a "charset" value)?

The message/global business is about the message header fields;
for message/rfc822 it is ASCII.  The content (message body) is
still default ASCII unless there is a MIME header field saying
something else:  Something else can be anything (not limited to
UTF-8) encoded for 7bit (MIME B or QP) or 8bit (for UTF8SMTP,
does not require an encoding for MIME-compatible charsets such
as UTF-8, BOCU-1, Windows-1252, etc.)  UTF8SMTP does not allow
"unencoded binary" or charsets such as UTF-16, UTF-32, or SCSU
in the message body.

> * Can an internationalized message contain a multipart
>   content-type using an UTF-8 "boundary" value?

Good question, without cheating (= looking into the EAI drafts
if they cover MIME Content-* header fields somewhere) I don't
know the answer.

-Frank

---

From: [email-masked]
Date: Wed, 05 Oct 2011 14:45:00 -0700 (PDT)

> necessary to mention UTF-8 somewhere (in a "charset" value)?

Short answer: No, no, and no.

Longer answer: There is no expectation that the current use of utf-8 will ever
be "upgraded" to utf-16, utf-32, or anything else. Utf-8 is where we're headed.
See RFC 2277.

> using an UTF-8 "boundary" value?

No. Nothing in this specification updates MIME's ABNF for boundaries, which
clearly restricts them to a subset of printable ASCII. (I note that utf-8 and
even binary MIME parameter values have been allowed for many years - see RFC
2231, so that hasn't been a limiting factor on boundaries in a long time.)

> * Can an example of internationalized message be added

The closest we could get is a message/global encoding of a message containing
UTF-8, which IMO would be much more confusing than helpful.

> Shouldn't "References: header fields" be written instead of

Seems reasonable.

> to 988 octets?  I would have understood if it were 998 octets.

That's just a typo.

> Two spaces after ":", as it is already the case in the rest of the document.

I just checked; there is no other place where two spaces are used. I dislike
this sort of double spacing and so don't use it. (If the RFC Editor disagrees
that's fine too.)

> ("the potential complexity […] is thought"?)

Yes, I'll fix that.

> in plural form or in singular form)

No, this one looks right to me as-is.

> The first "is" should be removed.

Fixed.

> "internationalized"?

There are places where we use one and places where we use the other. *shrug*
I guess I'll make them all internationalized for consistency, but either
is really fine.

				Ned

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 06 Oct 2011 22:02:10 +0200

Hi Ned,

> be "upgraded" to utf-16, utf-32, or anything else. Utf-8 is where we're headed.

OK, thanks for your answer.
Also many thanks to Frank for his detailed history on this subject.

    Encoding considerations:  Any content-transfer-encoding is permitted.
       The 8-bit or binary content-transfer-encodings are recommended
       where permitted.
    Security considerations:  See Section 4.
[…]

>> [Section 3.7]
>>>    Encoding considerations: […]
>>>    Restrictions on usage: […] The 8-bit or binary content-transfer-

The same construction "The 8-bit or binary content-transfer-encoding(s)" 
is used in the quoted paragraphs above.  I thought it should be homogenized.

-- 
Julien ÉLIE

« – C'est un drôle de nom, HCL.
   – C'est son immatriculation d'espion. Son vrai nom, c'est
     Acidcloridrix… » (Astérix)

---

From: [email-masked]
Date: Thu, 06 Oct 2011 14:52:35 -0700 (PDT)

>     Security considerations:  See Section 4.

I'm talking about the source file, not the xml2rfc output. I have no control
over whether or not xml2rfc double spaces after colons or periods.

> is used in the quoted paragraphs above.  I thought it should be homogenized.

And I disagree. The mistake is the choice of article, not the use of singular
or plural.

				Ned