Re: Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard

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

 



>>>>> "SM" == SM  <sm@xxxxxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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