Subject: [EAI] WG Co-chair review of 5336bis (SMTP extension)

From: John C Klensin <[email-masked]>
Date: Mon, 29 Nov 2010 02:32:25 -0500

Hi.

While I'd like to consider this a final review before handoff to
the IESG, the document is in rather poor shape in some areas,
causing me to have some concerns about the quality of reviews
performed by those who promised to review it.   Note that all of
the comments below except (5) below are essentially editorial,
rather than substantive.  But we should fix our own editorial
problems (and authors should have them under control before we
reach this point).  While I believe that many of the sorts of
issues pointed out below can and should be left to the RFC
Editor, the IESG has not agreed in recent years, preferring to
have most or all editorial matters settled before handoff to the
RFC Editor.  If we hand the IESG a document and they start
editorial nit-picking, we waste a lot of time (at best).

I have tried to avoid raising issues pointed out in other notes
to the mailing list, so the list below should be largely new.

(1) Abstract: "syntax", not "syntaxes".

(2) The Introduction is incoherent, consisting of a series of
isolated, choppy statements that bear no obvious relationship to
each other.  Most of those statements may not be necessary if
Framework (4952bis) is really prerequisite for reading/
understanding this document.  I'd recommend discarding most of
the first paragraph of the Introduction and merging the rest
with the present Section 1.1.

(3) In Section 1.1, Framework should be cited (i.e., with
"[RFC4952bis]" when it is first mentioned and probably not again
in the Section 1.   Similarly, a citation to RFC3629 is not
needed each time UTF-8 is mentioned.  

(4) Section 2, third sentence, begins "In order to provide
information that may be needed in downgrading...".  That
sentence is simply false -- there is no alternate address any
more-- and extremely misleading.  This is not the only place
where artifacts of downgrading still appear, see, e.g., the last
sentence of Section 3.6.2 (which might possibly be fixed by
replacing "downgrades" by "rejections").

(5) Section 3.1(3): "Clients MUST ignore any parameters..." was
fine for the experimental protocols.  At this point, we need to
decide what the WG intends about extension models.  "MUST
ignore" implies that any future extension must be optional,
i.e., the system will work in a predictable way if parameters
are supplied and ignored.  "MUST reject" (i.e., behave as if
UTF8SMTPbis had not been supplied at all) means either that
there will be no extensions or that they have to be assumed to
be incompatible.  The latter is _much_ safer -- what does the WG
intend.    Editorially, this bullet item would be much easier to
follow if it made all statements about the server and then all
statements about the client or vice versa: the current form is
server-requirement / client-requirement / server-requirement.

(6) As a specification that will published a year after IDNA2008
was approved, this document should reflect IDNA2008 terminology,
not an odd mix of IDNA2008 terms, IDNA2003 terms, and informal
language.  Specifically (this may not be a complete list), ACE
labels should not be discussed in Section 3.2 especially with a
parenthetical "as specified" note pointing to IDNA Defs on its
first use.  Instead, the term "A-label" should be used with an
appropriate reference.  Unless there is a specific reason for
doing so (in which case it better be explained to the WG), the
text should not talk about domain names in UTF-8 strings but
about U-labels.  It would be desirable to say, once, that any
U-labels are required to be expressed in UTF-8, but that doesn't
make them UTF-8 strings.   The first bullet in 3.3 should refer
to a U-label as well, Section 3.6 should refer to A-labels, and
so on.

(7) I'm not aware of the term "Message User Agent" ever being
used in an Internet mail context: "Mail User Agent (MUA)".

(8) Also in Section 3.2, the next-to-last paragraph ("This
document applies...") is either internally circular or just too
difficult to parse: it is not clear what the clause "which
requires..." points to or why it is useful.

(9) Section 3.4 points to an appendix to the document for a
definition.  There is no such appendix.   I suspect this should
be pointing to Framework.

(10) In the last paragraph of Section 3.4, the term "bounced" is
used.  Given contemporary usage in 5321 and elsewhere,
"rejected" is probably intended.

(11) Section 3.6.1 is hard to follow.  The phrase "any domain
names that appear in this dialogue" would be reasonable if it
were not followed by "or in responses to...".  Please change
this to be clear that the client must send only ASCII (LDH or
A-label) domains in the EHLO command and that, if the server
provides domain names in the EHLO response, they must be
A-labels.  It might be worth noting that this protocol does not
contemplate the server returning any non-ASCII domain names at
all, especially since the UTF8SMTPbis response is forbidden to
have parameters.

(12) In Section 3.6.2, if we are serious about the "Advice for
non-ASCII & ASCII addresses" and/or "Advice for EAI deployment"
documents, a non-normative forward pointer might be appropriate.
Note the "downgrading" comment there and item (4) above.

(13) In Section 3.6.3 and elsewhere, where a requirement is not
new but simply a restatement of an RFC 5321 requirement, it
would probably be useful to make that clear.  For example, the
first sentence of 3.6.3 might be restated as

	"When an SMTP server receives a message for delivery or
	further processing, RFC 5321 requires that it MUST
	insert trace..."

followed by deleting as much of the subsequent text as possible,
i.e., removing all of the discussion that is not directly
relevant to this extension.

(14) Section 3.6.4.1 is titled "MAIL and RCPT Commands" but
discusses only RCPT commands.  Please either discuss MAIL (it is
not clear to me there is anything to say) or edit the title.
It appears to me that the two paragraphs in this section could
be rewritten to be more clear.  As with (5) above, talk about
the client, then the server or vice versa, not a little bit of
one, the other, and then the first again.

(15) In Section 3.6.4.2, I don't recall Alexey's ABNF check
catching this so note that the line

   "User Name < uMailbox>"

is not ABNF.  It is not clear what it is.

(16) Check with Alexey, but I believe that the correct submitter
for the IANA extended code registrations for a standards track
document (if any are needed after the earlier discussion) is
"IETF EAI WG", or can be omitted entirely, and is not the name
of the second author of the I-D.

(17) Several of the References are not used in the text.  Please
run http://fenron.net/~fenner/ietf/xml2rfc-valid/ if your
original is in XML and, in any event,
http://tools.ietf.org/tools/idnits/ in verbose mode.  The latter
will turn up several additional issues, including the use of the
string "RFC" in the Obsoletes and Updates headers, some spacing
problems with citations, as well as a number of non-issues
(e.g., intentional references to obsolete documents, confusion
of section numbers with IP addresses, etc.)

regards,
   john

(14)

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Nov 2010 09:56:12 +0000

>Hi.
Hi John,
A couple of comments on your review.

>RFC Editor.
I am not going to defend IESG, but speaking in general terms - if you 
can't understand something, you can't verify if it is correct or not. 
This is a valid ground for DISCUSS.

>If we hand the IESG a document and they start
So true.

>each other.
I am afraid I have to agree here.

>Most of those statements may not be necessary if
 [...]

>intend.
Can we anticipate any extensions to this extension?

Personally, I don't think that "MUST ignore" is such a bad option. It 
worked reasonably well for SMTP AUTH, albeit SMTP AUTH is a bit special.

>Editorially, this bullet item would be much easier to
 [...]

>is not ABNF.  It is not clear what it is.
Good catch, I missed that.

>of the second author of the I-D.
Actually that is Ok. The Change Controller field (if present) must be 
"IETF" or a specific IETF WG.

Best Regards,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Nov 2010 17:15:56 +0000

Comments on my earlier comments below:

 [...]

> "IETF" or a specific IETF WG.

On a second thought: this field is supposed to be used to ask more 
questions about a registration. So it is better to specify the WG 
mailing list there. That is what we've done in the Sieve WG for all 
registrations.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 29 Nov 2010 17:22:56 +0000

[...]

> worked reasonably well for SMTP AUTH, albeit SMTP AUTH is a bit special.

I checked other SMTP documents and none of them specify that extensions 
to an SMTP extension keyword line is allowed. So I am Ok with following 
what John suggested. Any future extension can advertise another keyword, 
if needed.

---

From: Joseph Yee <[email-masked]>
Date: Mon, 29 Nov 2010 12:34:46 -0500

On 2010-11-29, at 2:32 AM, John C Klensin wrote:

[...]

> server-requirement / client-requirement / server-requirement.

Personal thought (and prediction) on this: extensions or parameters of extension usually act like branching of mechanism like AUTH and SORT (IMAP).  The only possible extension that I could think of now is branching of how headers being managed.  Body has it own extension already.  Encoding is restricted to UTF8 only.  If something "disruptive" like altering behaviour (like downgrade) or slightly incompatible SMTP-like proposed, it may results in a new keyword or a brand new protocol.  So personally I think extending UTF8SMTPbis in future is less likely.

From client perspective, I think 'MUST ignore' is ok, but 'MUST reject' enforce new keyword on extension, which I think is better for long term.  Future drafts may always need a matrix table to help specifying "A & B & C = this; A & !B & C = that", which may be the case regardless extending on UTF8SMTPbis or not :)

> to a U-label as well, Section 3.6 should refer to A-labels, and

+1
Using A-Label and U-label helps explaining in general.

[...]

Thanks
Joseph

> 
> 
> 
> 
> 
> 
> regards,
>   john
> 
> 
> (14)
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima