RE: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: Alexey Melnikov [mailto:alexey.melnikov@xxxxxxxxx]
> Sent: Monday, March 05, 2012 4:00 AM
> To: Murray S. Kucherawy
> Cc: ietf@xxxxxxxx
> Subject: Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple
> Mail Transfer Protocol extension for Message Transfer Priorities) to
> Proposed Standard
> 
> > - 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.

OK, I've just never seen that approach taken before.

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

Suggest:

For example, once an MTA accepts a message, the MTA MUST not change a (syntactically valid) priority value if that value is not supported by the MTA's implementation of this extension.

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

There are some that are in more need of this than others, and I know lately that I've been thanked by ADs during IESG evaluation for providing this kind of text, so it can only help where it's possible to provide it.

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

Sure, and I sympathize with your reply that it triggers an ID nit.  I wonder if the IESG could agree on some text like what Barry suggested and add it to the ID nit checker as a valid exception.  Maybe 2119 should also be updated accordingly.

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

I don't think I've ever seen them in the wild, which is why it caught my attention.

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

Those people are also no longer on my Christmas list.  :-)

Thanks,
-MSK

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]