Subject: [EAI] Request for publication for draft-ietf-eai-framework-04 as INFORMATIONAL

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Jan 2007 09:23:26 +0100

The EAI WG hereby requests publication of draft-ietf-eai-framework-04 as 
an Informational document.
The EAI WG further requests that an IETF Last Call be performed on the
document prior to approval.

The writeup below is based on draft-ietf-proto-wgchair-doc-shepherding-08.

   (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?

Harald Alvestrand is Document Shepherd. He has reviewed the document.

   (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?

The review in the WG has been thorough, and many people who are not WG
members are aware of the document.
We think that the IETF would benefit from having its attention called to
the document, so that people are aware that the EAI experiment is being
tried, and so that any issues with the general approach taken can be 
raised before the WG settles on final specifications for the technical 
components of the proposal; this is the reason for asking for 
publication of this document before the technical specifications are 
finished.

   (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.
The format of email addresses is embedded in a lot of other 
specifications, and these need to evaluate whether their specifications 
will be affected by this work, but that is a review of their documents, 
not a review of this document.

   (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.

There are some sections in the document that might not reflect a solid
informed consensus in the WG - notably sections 6.5 and 6.6. However, 
the WG has elected not to have further discussion on these in WG Last 
Call, so we can assume that the WG will not object to the text as given 
- the text mostly serves to point out areas where further work might be 
needed, and has limited immediate technical impact.

   (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?

As far as concern has been expressed, the WG seems satisfied with this
document.

   (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
          http://www.ietf.org/ID-Checklist.html 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.

Online id-nits checker complains that the domain name "any.thing.goes" 
does not end in "example"; this is a left-hand side of an email address, 
so does not constitute a break with the I-D checklist.

   (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. All normative references are published.

The document lists the actual technical specifications it is a framework
for as informative references. This is believed to be factually correct -
it is not necessary to have the specifications to interpret the framework,
and since it is a framework, it cannot be implemented.

   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  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 suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  If the document
          describes an Expert Review process has Shepherd conferred with
          the Responsible Area Director so that the IESG can appoint the

Yes.
  (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, there are no such sections.

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Writeup?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

   Full use of electronic mail throughout the world requires that people
   be able to use their own names, written correctly in their own
   languages and scripts, as mailbox names in email addresses.  This
   document introduces a series of specifications that define mechanisms
   and protocol extensions needed to fully support internationalized
   email addresses.  These changes include an SMTP extension and
   extension of email header syntax to accommodate UTF-8 data.  The
   document set also includes discussion of key assumptions and issues
   in deploying fully internationalized email.

        Working Group Summary

          The decision to not provide any means of "automatic
          encapsulation" of UTF-8 email addresses, but instead insist
          that the sender specify an alternate
          address for downgrading purposes, was controversial, but was
          definitely the decision of the working group.

          Document Quality

             This document has helped guide the development of the
             technical specification.
             Having the document stable will facilitate finishing the
             rest.

          Personnel
             The Document Shepherd is Harald Alvestrand.
             The responsible AD is Ted Hardie.

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima