Hi Murray,
Thank you for the comments. Some answers below.
On 01/03/2012 04:43, Murray S. Kucherawy wrote:
I have several comments on this draft. But first, this is a big improvement
since the last version I reviewed, so kudos to the authors.
A couple of these refer to issues in the document that need to be resolved
before it can move forward, but you probably already know what they are. The
rest are not showstoppers. It could also use a quick editorial pass, which I'm
happy to do for you separately if you like.
- Section 3, bullet 7: LTMP -> LMTP
Fixed.
- Section 4.1 contains a reference to "esmtp-values" which looks like an ABNF
terminal, but it's not explained. Did you mean an ABNF terminal,
Yes, as defined in Section 4.1.2 of RFC 5321. Clarified.
or did you mean something about ESMTP parameters?
- Section 4.2, bullet 2: "Section 6" should probably be in parentheses, probably preceded
by "see"
Fixed.
- There's a bunch of TBDs that still need to be resolved before this document
moves forward (X.7.TBD3 as an enhanced status code, for example)
No, these are assigned by IANA before publication. RFC Editor will fix
these.
- Section 4.2 makes reference to "the Minimize condition" but the document
doesn't otherwise define it
Yes, I will explain.
- Section 4.3 says "For example, once an MTA accepts a message, the MTA MUST NOT
change a (syntactically valid) priority value if the MTA doesn't support it." There
seems to be a chicken-and-egg going on here: If the MTA doesn't support the extension,
how can it know not to change the priority outbound?
I meant "supports the extension, but doesn't support a particular value
as distinct priority level". Suggestions on how to make this clear would
be appreciated.
- There are lots of SHOULDs in here that might benefit from example situations
in which one might deviate from the normative statement containing the SHOULD.
I will review. I had some discussion with SM about some of these and
argued that not all of them should be explained. But I agree that some
of them need explanation.
- Section 5 and Section 5.1 use "not required", "should", and "may" where
RFC2119 is cited earlier. Should they be in all-caps, or should other language be selected?
Lowercased versions are not used in normative sense. Maybe a note
suggested by Barry would help with this.
- Section 5: "Irrespectively on" -> "Irrespective of"
Changed.
- Section 5: "fine grainer control" -> "finer-grained control"
Changed.
- Section 5.1 makes reference to "the work-in-progress effort extension to RSVP that
prioritizes reservations." This should include a citation even if it references an
I-D that's not published yet.
Ok, I will ask my co-editor about this.
- Section 9: "it is advised that all or none of them SHOULD support the PRIORITY
extension" sounds awfully mushy. I suggest dropping the SHOULD, and rather say something like
"it is advised that either all of them support the PRIORITY extension, or none do".
Ok.
- Section 10 should be resolved before the document advances.
- Section 11: Why use "PRI" and not "priority"? The existing set of Received
clause names are lowercase words, so it seems strange to deviate.
I don't mind to switching to "PRIORITY". But section 4.4 of RFC 5321
uses uppercase variants (and yes, I know they are case insensitive).
- Appendix A: Can STANAG 4406 be listed in the Informative References?
Sure.
- Appendix D: "This appendix and its subsections are informative." I think
that (a) any appendix is informative, because normative text doesn't belong in an
appendix; and (b) the normative stuff uses RFC2119 language and this doesn't. Thus, I
think this sentence should be removed. (I know I've lost this argument before, but I'll
make another stand here anyway.)
I think other people already commented on this :-)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf