"SM" == SM <sm(_at_)resistor(_dot_)net> writes:
SM> Hi John,
SM> At 18:09 13-10-2009, John C Klensin wrote:
>> 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
SM> I mentioned to the authors of this draft that the changes I
SM> may suggest for the document to be appropriate as a proposed
SM> standard would make it incompatible with PEC. As you said,
SM> this is one of the cases where we have to consider what kind
SM> of review is appropriate for an I-D.
>> To pick up another element of your comments, RFC 2822 and 5322
>> discourage the use of X-headers. Even if the Xs were removed,
SM> This is again a case where existing implementations will be
SM> used to argue why the X-headers cannot be changed even though
SM> using such headers for messages on the Internet is bound to
SM> cause problems.
>> 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.
SM> I noticed that some RFC 5322 headers are translated in
SM> Spanish. It's difficult to say that headers must be in
SM> English (they are in Italian in the draft). However, if we
SM> are to have a header field name translated for each language,
SM> we will end up with an unworkable situation.
>> 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.
SM> I didn't see Sam's message. I agree that such documents
SM> should reflect the document quality we expect out of Working
SM> Group documents.
It was sent only to the IESG and John. It was clearly an IETF
contribution so it's entirely reasonable that John is discussing it
here. Basically I enumerated a number of reasons that I believe
suggest the document is not ready for last call as standards track.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf