--On Tuesday, October 13, 2009 15:35 -0700 SM <sm@xxxxxxxxxxxx> wrote: > Hi John, > At 13:24 13-10-2009, John C Klensin wrote: >> Before trying to embark on an in-depth review of this long and >> complex document, could the IESG explain to the community why >> it is being processed as a Proposed Standard? After reading >> quickly through its first few pages, and despite containing a >> standard IPR clause rather than a "no derivative rights other >> than to publish" one, it appears to be a translation and >> adaptation of an existing national standard and set of >> regulations, with no provisions for transferring change >> control to the IETF, etc. >... > It may seem like the document is about S/MIME. However, most > of the specification, in my opinion, relates to RFC 5321 and > RFC 5322. The document re-purposes some email concepts. This is the part of the review that I don't want to do unless it is clear that it really belongs on Standards Track. If it is an informational translation or report about a standard adopted in Italy, then I'm fine with it. If I remember the rules, publication of such a document in the IETF track merely requires an IESG decision that it would be useful. It doesn't require IETF Last Call at all unless the IESG concludes that would be useful (and presumably tells us why. If is is going to be standards track, it needs to pass scrutiny as consistent with the various relevant mail standards, as you point out, as well as responding to the sorts of security issues of which Sam gave examples and the more general issues, such as change control, that I raised in my earlier note. > From Section 2.1: > > "Both "From:" and "Sender:" fields MUST contain the same > value." > > Quoting Section 3.6.2 of RFC 5322: > > "The "Sender:" field specifies the mailbox of the agent > responsible > for the actual transmission of the message." > > That's not to be confused with the author of a message. Yes. Clear violation of the intent of having those two fields since RFC 822 (or earlier). > In Section 3.1.1: > > "sender's address, specified in the SMTP reverse path, > coincides > with the one in the message's "From:" field;" > > The address in the reverse path doesn't always coincide with > the address from the "From:" header field. Yes. Clear violation of notions about envelopes since RFC 821. To pick up another element of your comments, RFC 2822 and 5322 discourage the use of X-headers. Even if the Xs were removed, it is not clear to me that the relevant headers are clearly enough defined for a header registry. And, perhaps as part of your "internationalization considerations" remark, I note that we have never standardized a header field name that is based on Italian, rather than English, words. I can't think of any particular reason why we should not (although there are lots of reasons to not have standard header field names that require non-ASCII strings) but it is a major step that needs some serious consideration... not slipping in the back door via a "security" document. > These are quick comments and should not be considered as a > review of the draft. Yes, I think the things that you, Sam, and I spotted on very quick inspection are probably the tip of the proverbial iceberg, all of which will have to be examined if the document is really standards track. But I also agree with Sam's other main point: if the document is to be processed as an Individual Submission Standards Track spec, it should reflect _at least_ the document quality we expect out of WG documents being similarly processed. It doesn't. So my personal recommendation to the sponsoring AD and IESG is that this Last Call should be withdrawn (immediately or Real Soon Now to avoid wasted effort) and, when appropriate, replaced by either: -- a revised form of the document that conforms better to expectations for standards-track documents and a Last Call that is much more specific about what this is, why it belongs on the Standards Track, what the change control situation is, etc. or --if it is deemed necessary, a Last Call for Informational publication of a standard from another standards body, ideally accompanied by an explanation of what the IESG wants the community to look at (since such documents are normally not IETF-change-controlled and often have very restrictive modification or derivation rights). john _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf