1 Sep 2010 11:37
Re: Last Call: <draft-ietf-eai-frmwrk-4952bis-07.txt> (Overview and Framework for Internationalized Email) to Proposed Standard
Alexey Melnikov <alexey.melnikov <at> isode.com>
2010-09-01 09:37:17 GMT
2010-09-01 09:37:17 GMT
The IESG wrote: >The IESG has received a request from the Email Address >Internationalization WG (eai) to consider the following document: >- 'Overview and Framework for Internationalized Email' > <draft-ietf-eai-frmwrk-4952bis-07.txt> as a Proposed Standard > > A minor clarification about IETF process: Chairs asked me if this document should be Proposed Standard or Informational. I decided to initiate the IETF Last Call as if it is going to Proposed. The document might end up being Informational based on IESG review, but the document status change from Proposed Standard to Informational can be done during IESG review and no additional Last Call would be needed.
* Abstract
This document specifies an variant of Internet mail
=> "a variant" I think.
This specification Updates section 6.4 of [RFC2045]
=> "updates" in lowercase, "Section" in upercase.
* Section 1.1
This document specifies an variant of Internet mail
=> "a variant" I think.
* Sections 1.2 and 4.2
blanket ban on applying a content-transfer-encoding to all subtypes
of message/.
=> I do not find it satisfying to read "message/." at the end of
a sentence. I believe it should be quoted. RFC 2045 uses
quotes for "message/rfc822".
Anyway, it is just a remark, and it should be homogenized
according to the current trend for that.
* Section 1.2
This document also updates [RFC5322] and MIME ([RFC2045]), and people
who participate in the experiment have to swich to this document.
=> "switch"?
Message/global (see
Section 4.6) permits use of a content-transfer-encoding.
=> I also do not find it satisfying to have an uppercase initial letter
for "Message/global"!
I believe quotes and a lowercase letter would be fine at the beginning
of the sentence.
* Section 2
text (such as in the Subject: field) to be encoded (as required by
=> Wouldn't "Subject:" with quotes be better? It is the way it is
written in RFC 5322.
change described in the associated document
[I-D.ietf-eai-frmwrk-4952bis] and [I-D.yao-eai-rfc5336bis]
=> "documents" in plural?
* Section 3
Unless otherwise noted, all terms used here are defined in [RFC5321],
[RFC5322], [I-D.ietf-eai-frmwrk-4952bis],or [I-D.yao-eai-rfc5336bis].
=> Missing space.
* Section 4.1
%xE1-EC 2(UTF8-tail) /
%xF4 %x80-8F 2( UTF8-tail )
=> It should be homogenized: with spaces or without spaces.
* Section 4.3
FWS = <see [RFC5322], folding white space>
CFWS = <see [RFC5322], folding white space>
=> why "folding white space" for both of them, and not "Section 3.2.2"
or its title?
timezone in the Date: headers are still expressed in ASCII. And
=> Same as before. Quotes for "Date:"?
* Section 4.5
"For" fields containing internationalized addresses are allowed, by
use of the new uFor syntax. UTF-8 information may be needed in
Received fields.
=> If not "Received:" fields (with a colon), the wording should be
"Received header fields".
The "Return-Path" header field provides the email return address in
=> Same thing.
email address in the "For" field. <angle-addr> is augmented to
include UTF-8 email address.
=> Missing space (it should be doubled after the final dot).
* Section 4.6
o it contains UTF-8 header values as specified in this document, or
o it contains UTF-8 values in the headers fields of body parts.
=> Hmm... Is it clear regarding RFC terminology?
Isn't it "UTF-8 values in header field bodies" for the first and
I-don't-know-how-to-name-it (for "For" if I understand well?)
for the second?
different properties. Systems unaware of international headers
Email clients which forward messages with international headers as
=> "internationalized"?
Regards,
RSS Feed