Re: [EAI] Publication request of draft-ietf-eai-rfc5335bis-12

["Jiankang YAO" <[e-mail]>]

BTW, this is the shepherd's report that John indicated should be forwarded.

Chairs will give Last Call announcement (for all three core documents) soon.


Jianakng Yao


In your mail:
>From: "Jiankang YAO" <[e-mail]>
>Reply-To: Jiankang YAO <[e-mail]>
>To: [e-mail]
>Subject: [EAI] Publication request of draft-ietf-eai-rfc5335bis-12
>Date:Thu, 06 Oct 2011 09:24:16 +0800
>
>Dear ADs,
>
>This message is a request to publish
>draft-ietf-eai-rfc5335bis-12 on the Standards Track.
>The draft represents the rough consensus of the EAI Working
>Group.
>
>As required by RFC 4858, below is the completed current template for
>the Document Shepherd Write-Up.
>
>
>Best regards,
>Jiankang Yao(Shepherd for this document)
>
>
>--------------------------------------------
>
>DRAFT FILENAME: 
>    draft-ietf-eai-rfc5335bis-12
>TITLE:    
>    Internationalized Email Headers
>
>
>
>  (1.a) Who is the Document Shepherd for this document? Has the
>        Document Shepherd personally reviewed this version of the 
>        document and, in particular, does he or she believe this 
>        version is ready for forwarding to the IESG for publication? 
>
>Jiankang Yao.  Yes, I believe it is ready.
>
>  (1.b) Has the document had adequate review both from key WG members 
>        and from key non-WG members? Does the Document Shepherd have 
>        any concerns about the depth or breadth of the reviews that 
>        have been performed?
>
>There has been a lot of discussions about this draft. An earlier
>version went through WG last call in Nov. 2010. That version received
>a significant number of comments. As a result, an additional author
>was added and the document restructured to address all of the issues
>that the WG considered substantive.  In Sep. 2011, this draft got
>another WG last call to confirm that the revised version had gotten
>rough consensus.  The EAI WG has been talking about this draft for
>very long time.  I believe it has had adequate review.  
>  
>  (1.c) Does the Document Shepherd have concerns that the document 
>        needs more review from a particular or broader perspective, 
>        e.g., security, operational complexity, someone familiar with 
>        AAA, internationalization or XML? 
>
>No.
>
>  (1.d) Does the Document Shepherd have any specific concerns or 
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of? For example, perhaps he 
>        or she is uncomfortable with certain parts of the document, or 
>        has concerns whether there really is a need for it. In any 
>        event, if the WG has discussed those issues and has indicated 
>        that it still wishes to advance the document, detail those 
>        concerns here. Has an IPR disclosure related to this document 
>        been filed? If so, please include a reference to the 
>        disclosure and summarize the WG discussion and conclusion on 
>        this issue. 
>
>The question of whether this document should be identified as updating
>RFC 5322 remains unanswered, partially because neither the IETF nor
>the RFC Editor has a clear rule about the point at which document that
>extend a base specification but do not significant modify it are
>considered to be updated.  Quoting the current lead editor, "we
>change the line length limit from 998 characters to 998 octets". This
>is really an i18n clarification: a count in "characters" and one in
>"octets" are identical for ASCII, but "octets" provides a precise and
>invariant length independent of character set and encoding.  The WG is
>happy to have the IESG resolve this issue as you think appropriate.
>
>People representing the part of the Netnews community who believe that netnews
and
>Internet mail are the same except for transport are still grousing about a
>decision (Message-IDs) that might have been different had the WG considered
>behavior on the other side of gateways as more
>important than smooth operation within the SMTP environment on
>the public Internet. 
>
>There are no other known issues.
>
>
>  (1.e) How solid is the WG consensus behind this document? Does it 
>        represent the strong concurrence of a few individuals, with 
>        others being silent, or does the WG as a whole understand and 
>        agree with it?   
>
>Many WG participants from EAI WG have reviewed this document and
> had reasonably strong WG consensus.  There has been no dissent in the
> last two calls for comment within the WG.
>
>  (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
>        discontent? If so, please summarise the areas of conflict in 
>        separate email messages to the Responsible Area Director. (It 
>        should be in a separate email because this questionnaire is 
>        entered into the ID Tracker.) 
>
>No.
>
>  (1.g) Has the Document Shepherd personally verified that the 
>        document satisfies all ID nits? (See the Internet-Drafts Checklist 
>        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
>        not enough; this check needs to be thorough. Has the document 
>        met all formal review criteria it needs to, such as the MIB 
>        Doctor, media type and URI type reviews? 
>
>Yes, I have checked it. There is one outdated reference: A later
>  version (-13) exists of draft-ietf-eai-rfc5336bis-07
>
>  (1.h) Has the document split its references into normative and 
>        informative? Are there normative references to documents that 
>        are not ready for advancement or are otherwise in an unclear 
>        state? If such normative references exist, what is the 
>        strategy for their completion? Are there normative references 
>        that are downward references, as described in [RFC3967]? If 
>        so, list these downward references to support the Area 
>        Director in the Last Call procedure for them [RFC3967]. 
>
>Yes.  There are normative references to [I-D.ietf-eai-frmwrk-4952bis]
>and [I-D.ietf-eai-rfc5336bis], which are part of this package.  The
>former is already in the RFC Editor queue awaiting approval of this
>document and draft-ietf-eai-rfc5336bis before being published.  This
>document and draft-ietf-eai-rfc5336bis resolve those downward or
>missing references; they do not introduce new ones.
>
>  (1.i) Has the Document Shepherd verified that the document IANA 
>        consideration section exists and is consistent with the body 
>        of the document? 
>
>Yes.
>
>
>        If the document specifies protocol 
>        extensions, are reservations requested in appropriate IANA 
>        registries? Are the IANA registries clearly identified? If 
>        the document creates a new registry, does it define the 
>        proposed initial contents of the registry and an allocation 
>        procedure for future registrations? Does it suggest a 
>        reasonable name for the new registry? See [RFC5226]. If the 
>        document describes an Expert Review process has Shepherd 
>        conferred with the Responsible Area Director so that the IESG 
>        can appoint the needed Expert during the IESG Evaluation? 
>
>No new registries, but IANA is requested to update the registration of 
>the message/global MIME type 
>
> (1.j) Has the Document Shepherd verified that sections of the 
>        document that are written in a formal language, such as XML 
>        code, BNF rules, MIB definitions, etc., validate correctly in 
>        an automated checker? 
>
>Yes.
>
>  (1.k) The IESG approval announcement includes a Document 
>        Announcement Write-Up. Please provide such a Document 
>        Announcement Write-Up? Recent examples can be found in the
>        "Action" announcements for approved documents. The approval 
>        announcement contains the following sections: 
>
>     Technical Summary 
>
>This document specifies an enhancement to the Internet Message Format
>that allows use of Unicode in mail addresses and most header field
>content.
>
>
>
>     Working Group Summary 
>        
>This document has been discussed in EAI WG for a very long time. 
>The WG came to consensus on this document.
>
>
>
>     Document Quality 
>
>The documents have been extensively reviewed by people with mail
>expertise. It is in very good shape.
>
>(end)
>
>
>-------------------------------------------------------------------
>
>
>_______________________________________________
>IMA mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ima