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