Document Shepherd Writeup - draft-ietf-eai-5738bis-07 (EAI-IMAP)
Date: 2012-08-22
Shepherd: John C Klensin, john-ietf@jck.com
1.
What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?
Proposed Standard. This set of documents are all protocol
specifications, following up earlier Experimental treatment of POP3
and IMAP access to messages with internationalized envelopes and/or
header fields.
2.
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
Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication
that there are deficiencies in the abstract or introduction.
These documents make up a set of four that are interdependent and
should be reviewed, evaluated, and understood together. Their
abstracts have been examined and verified to sufficiency to
describe the individual documents.
The abstract for this particular document reads:
This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support UTF-8 encoded
international characters in user names, mail addresses and
message headers. This specification replaces RFC 5738.
Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or were
there decisions where the consensus was particularly rough?
Short answer: No. Longer answer: The WG had extensive and
constructive discussions about the role of "downgrading" (e.g.,
converting a message stored on the server that contains non-ASCII
header or envelope information) in the transition to an all-i18n
environment. Some of those issues and tradeoffs are discussed in
draft-ietf-eai-popimap-downgrade and
draft-ietf-eai-simpledowngrade. In some cases, the best strategy
may be to "hide" those messages that cannot be delivered without
change to legacy clients either with or without some attempt at an
error message. A complete treatment of those options is
impossible because the optimal strategies will depend considerably
on local circumstances. Consequently the base IMAP and POP3
documents are no longer dependent on particular downgrading
choices and that two methods presented are, to a considerable
extent, just examples. They are recommended as alternative
Standards Track documents because they are protocol specifications
and their sometimes-subtle details have have been carefully worked
out, even though the WG has no general recommendation to make
between them (or other strategies).
While opinions differ in the WG about which downgrading mechanisms
are likely to see the most use, if any, consensus is strong that
these four documents represent the correct output.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to implement
the specification? Are there any reviewers that merit special
mention as having done a thorough review, e.g., one that resulted
in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or
other expert review, what was its course (briefly)? In the case
of a Media Type review, on what date was the request posted?
Some development and interoperability testing has occurred and is
progressing. There are strong commitments in various countries to
implement and deploy the EAI (more properly, SMTPUTF8) messages
and functions specified in RFCs 6530 through 6533. Those messages
will be inaccessible to many users without POP3 and IMAP support,
so these specifications are quite likely to be implemented and
deployed in a timely fashion.
Reviewers who made particular contributions prior to IETF Last
Call are acknowledged in the documents. See Section 3 for
additional information.
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
Document Shepherd: John C Klensin
Responsible Area Director: Pete Resnick
Note that Pete Resnick is listed as a co-author on one of these
documents as a result of contributions well before he became AD
(and primarily to its the Experimental predecessor. He has not
been actively involved in an author or editor role since
joining the IESG.
3.
Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded
to the IESG.
The document shepherd, with assistance from the other co-chair, did
extensive, line by line and paragraph by paragraph reviews during the
WG LC window with the intention of identifying and eliminating as
many issues that might otherwise be spotted during IETF review as
possible. Those reviews were posted to the WG mailing list; the
documents being submitted include changes made on that basis.
4.
Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
This particular document shepherd has almost always been concerned
about breadth and quality of reviews in the IETF. HOwever, the co-
chairs have identified areas of expertise and perspective needed for
reviews of the specifications in these documents and their
relationship to the widely-deployed and well-tested IMAP and POP3
specifications and are confident that the reviews are adequate.
Although considerable improvements have been made in readability and
editorial and technical quality, the base IMAP
(draft-ietf-eai-5738bis) and POP (draft-ietf-eai-rfc5721bis)
documents represent an orderly and uncontroversial evolution from
their Experimental predecessors.
It is probably worth pointing out, as draft-ietf-eai-5738bis does,
that the transition to general adoption of SMTPUTF8 mail will not be
an easy one in many environments. In the case of the transport and
mail header specifications of RFCs 6530ff, the model that permits a
sender to test whether the potential receiver can handle the message
is clear, as is an orderly response if it is not (even if that
response may not be completely satisfactory from the user's
standpoint. That same relationship does not apply to these
specifications because, for many environments, a POP3 or IMAP server
must be prepared to deal with clients who do not have the needed
capabilities and there is no completely satisfactory way with either
protocol to either tell a client that it cannot access a message that
is known to be waiting nor to deliver an intact version of the
message (where "intact" includes, e.g., being able to pass signature
verification on body parts and/or headers).
5.
Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA,
DNS, DHCP, XML, or internationalization? If so, describe the review
that took place.
It is our strong belief that all such issues and perspectives have
been addressed by the WG and reviews already obtained.
6.
Describe any specific concerns or issues that the Document Shepherd
has 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.
All such substantive issues have been identified and resolved within
the WG and incorporated into the documents. I do expect that IETF
Last Call will turn up demands to solve problems that the WG has
concluded are impossible (some discussed above) but it is unlikely
that any will be a significant surprise.
The WG has strong consensus that some interoperability difficulties
can be anticipated during the period in which these protocols are
deployed. Those difficulties are inevitable in the absence of an
effective flag day (possible for POP and IMAP in some installations
but not generally). The alternative is to not deploy changes of this
sort at all, but the adoption of RFCs 6530-6533 eliminated that
possibility. To the extent possible, the transitional issues have
been removed from this document, discussed briefly in this document
and treated at more length in the two "downgrade" documents. That
strategy should most easily permit the transitional issues and
protocols to be put aside once the base IMAP and POP two protocols
(and the internationalization of email envelope and header field
protocols more generally) are widely deployed.
The WG has an outstanding question about the status of this document
(and draft-ietf-eai-rfc5721bis) relative to whether or not they
update the base IMAP and POP specifications. The WG's conclusion is
that they do not -- these specifications are extensions, not required
changes to the base specifications -- and the documents for IETF Last
Call were produced on that basis. The WG also notes that SMTP
extensions and mail header field additions have generally not been
identified as updating the base email specifications. However, the
topic raises a more general issue that we believe the IESG should
address. If the IESG concludes that all such extension documents
should be listed as updating the corresponding base specifications,
the WG has no objection to these documents being modified
accordingly.
7.
Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why.
Authors of all four documents have been queried to verify that they
have examined BCP 78 and 79 and are in compliance with them. The
three authors who have not yet replied are expected to be in
Vancouver and acknowledgments will be extracted from them there.
8.
Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
No IPR disclosures have been filed on any of the four documents.
9.
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?
The WG's meeting participants and mailing list have included a rather
large proportion of people who are anxious to see well-defined
standards in this area agreed upon and deployed, but who behave as if
they have little interest or expertise in the details of the
technology (some of them are probably correct about the latter). Of
those who have participated technically and more actively, the
consensus that these documents are ready to go seems rather solid.
In particular, multiple inquiries and WG Last Calls have not turned
up any significant controversy or unresolved issues.
10.
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 publicly
available.)
No
11. ID Nits
Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-
Drafts Checklist). Boilerplate checks are not enough; this check
needs to be thorough.
o The "Obsoletes" line in the header contains the string "RFC", not
just the numbers. This should be corrected when a version is
produced subsequent to IETF Last Call or is easily fixed by the
RFC Editor. This document shepherd fails to understand why issues
of this sort should take up the time of the WG, document shepherd,
or IESG.
o The nits checker complains that the abstract indicates that this
document obsoletes RFC 5738 but the document header does not
indicate this. In fact, the relationship is noted in the headers,
but obscured for the nits checker by the presence of "RFC". This
is believed to be a bug in the nits checker.
o For consistency with the other documents in the set (see
explanation in the Shepherd's report for
draft-ietf-eai-rfc5721bis), the sentence and the principle that
abstracts should contain only important information, the sentence
"This specification replaces RFC 5738." should be removed from the
Abstract when the document is updated after IETF Last Call.
o The document contains an abbreviated version of the RFC 2119 text
that lists only terms actually used. If the IESG or RFC Editor
prefer, that text can be changed to the more complete (but more
misleading) version when the document is updated after IETF Last
Call.
o The document references draft-ietf-eai-simpledowngrade-05 but the
current correct version is -07. Because
draft-ietf-eai-simpledowngrade is being put through IETF Last Call
concurrent with this document and the reference will be replaced
by the RFC Editor with an RFC number, the discrepancy is
considered trivial.
12.
Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
No such review criterial apply to any of these four documents.
13.
Have all references within this document been identified as either
normative or informative?
Yes
14.
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 plan for their completion?
There are no normative references to unpublished documents.
15.
Are there downward normative references references (see RFC 3967)?
These documents are intended for Proposed Standard. There are no
normative references to Experimental or Informational documents.
16.
Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.
See discussion of nits checking above. RFC 5738 is obsoleted by this
document. That status is shown in the header (albeit with the error
mentioned above) and mentioned in the Introduction.
17.
Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of
the document. Confirm that all protocol extensions that the document
makes are associated with the appropriate reservations in IANA
registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC
5226).
???
18.
List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
No new IANA registries are created by any of this set of documents.
19.
Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
The very small amount of ABNF in this document has been hand-checked.
Automated checks did not seem to be either necessary or appropriate.