Subject: Re: [yam] Request for comments: draft-ietf-yam-5321bis-smtp-pre-evaluation-00

From: Alexey Melnikov <[email-masked]>
Date: Sun, 06 Dec 2009 00:14:28 +0000

I think it would better to explicitly state that examples are not going 
to be changed to use example.com/example.net domains.

Some extra comments based on running IDnits (which report downrefs and 
few other things):

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:
     
     When an SMTP server returns a permanent error status (5yz) code
     after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
     any subsequent attempt to deliver the message.  As with temporary error
     status codes, the SMTP client retains responsibility for the message, but
     SHOULD not again attempt delivery to the same server without user review
     of the message and response and appropriate intervention.

   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
         August 1982.

Is this reference truly Normative? It looks Informative to me.

---

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 02:43:12 -0800

At 16:14 05-12-2009, Alexey Melnikov wrote:
>Some extra comments based on running IDnits (which report downrefs 
>and few other things):
>

The "SHOULD not" is a typo.

>Is this reference truly Normative? It looks Informative to me.

It is Informative because of the discussion about other transports in 
the Appendices in RFC 821 (Section 1.1), the history (Section 1.2) 
and Section 4.5.3.1.10.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Sun, 06 Dec 2009 11:52:11 -0800 (PST)

> The "SHOULD not" is a typo.

Yes, this has been noted a couple of times now. It's clearly a typo.

> the Appendices in RFC 821 (Section 1.1), the history (Section 1.2)

Agreed - these are the only references to RFC 821 [1], and they're all
informative, not normative, in nature.

				Ned