--On Tuesday, October 13, 2009 15:35 -0700 SM <sm(_at_)resistor(_dot_)net>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf