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

[[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)?

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.

> * Can an internationalized message contain a multipart content-type
> 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
> to the document?

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.

> > 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"?

Seems reasonable.

> > 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.

That's just a typo.

> >   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.

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.)

> >   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"?)

Yes, I'll fix that.

> [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)

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

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

> The first "is" should be removed.

Fixed.


> >      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"?

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