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

[Julien ÉLIE <[e-mail]>]

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)