POP3 Support for UTF-8
draft-ietf-eai-pop-09

[Ballot comment]
My original Discuss read...

> I think it would be valuable (and help with the discussions about an
> Experimental RFC updating a Standards Track one) to document the scope
> of the experiment. That is:
> - why is this an experiment?
> - how is the experiment confined?
> - what are the risks if the experiment escapes?
> - how will you judge the success (or otherwise) of the experiment?

I am going to clear my Discuss because I don't think I should block publication on this issue, but I am not completely happy with the answers.

This document is aimed at being published as an Experimental RFC. It seems to me that this means it is either an experiment in its own right or part of a larger experiment. The former case would have been easy to address by including text to answer my quesitons. The latter case (which I infer from your emails is the actual situation) is even more easily addressed by the inclusion of text such as:
  This document forms part of the larger EAI experiment described
  in RFCxyz (or in the charter of the xyz working group) and will be
  evaluated as part of that experiment.

I detect (from the tone of both Randy and Chris' emails) a slight disatisfaction with the fact that your charter forces you to publish as Experimental. That is a separate discussion that you need to have with your AD. You need to understand and support the limitations of your charter or get them changed.

Personally, I think that Experimental publication is very important and is to be encouraged. Treating the Internet with respect and making changes with caution should be part of the philosophy of the IETF. Introducing new work as Experimental should not delay its development, but should induce appropriate care in how the features are rolled out. Progression from Experimental to Standards Track is not hard, when the time comes.

Nevertheless, I appreciate your efforts to meet me half way, and will clear.

=======

The start of section 2 is a little cryptic! Could you arrange to begin
with some English text that introduces the formal definitions?

Ditto section 3.

---

Agree with Russ that the French needs to be checked, although I disagree
with his interpretation of correct French :-)

[Ballot comment]
The start of section 2 is a little cryptic! Could you arrange to begin
with some English text that introduces the formal definitions?

Ditto section 3.

---

Agree with Russ that the French needs to be checked, although I disagree
with his interpretation of correct French :-)

[Ballot discuss]
I think it would be valuable (and help with the discussions about an
Experimental RFC updating a Standards Track one) to document the scope
of the experiment. That is:
- why is this an experiment?
- how is the experiment confined?
- what are the risks if the experiment escapes?
- how will you judge the success (or otherwise) of the experiment?

I think I agree that while an Experimental RFC can build on Standards
Track work, it cannot "update" it. The meaning of "update" is often not
fully understood, but in my understanding it means "to be conformant
with the base RFC it is now necessary to be conformant with both RFCs."
And that is why "updates" is not appropriate in this case.

[Ballot comment]
Lars Eggert's DISCUSS; as Experimental, this cannot update RFC 1939.

  The Gen-ART Review by Brian Carpenter on 2009-10-17 asks some good
  questions:

  I would have expected a reference to RFC 5198 (PS for UTF-8 in
  protocols) as well as RFC 3629.

  I wonder whether any French person has checked the examples such as
  >
  > La Language commande a ete execute avec success
  >
  "Language" is not a French word. The French word for a specific
  language such as French is "langue".  Also, "success" is not a French
  word. It should be "succès" (that's a grave accent on the e, if UTF-8
  didn't quite get through). There are four other accents missing in the
  sentence.  I know we can't yet use UTF-8 in drafts but in that case, I
  suggest either using the usual U+HHHH notation for the accented
  characters, or choosing an example language that doesn't need accents.
  In any case the examples should be checked by a native speaker.
  (Actually the sentence makes very little sense anyway: "The language
  ordered has been executed with success.")

  The examples as presented would make the IETF look a bit silly in France.

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "POP3 Extension Mechanism" registry at
http://www.iana.org/assignments/pop3-extension-mechanism

CAPA tag CAPA Args Added cmds Affected List Diffs Cmd Valid References
-------- --------- ---------- -------- ---- ----- --------- ----------
LANG none LANG All both no AUTHENTICATION, TRANSACTION
[RFC-eai-pop-07]
UTF8 USER UTF8 USER, PASS, APOP, LIST, TOP, RETR both no
AUTHORIZATION [RFC-eai-pop-07]

We understand the above to be the only IANA Action for this document.

[Ballot discuss]
This document is going for Experimental and updates RFC1939, which is a Full Standard.

In my reading, this document is not mandatory-to-implement for the POP3 standard. As such, it doesn't need to (and IMO shouldn't) update RFC1939.

If it indeed is mandatory-to-implement, I believe we have an issue. When protocols progress up the standards track, we drop pieces what we don't believe have sufficient interoperability testing or that are otherwise thought to be less stable. It's hence problematic to later glue such pieces (i.e., this Experimental spec) onto the original Full Standard protocol.

I'd like to discuss on the call what folks think should be done here.

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

  (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 document had sufficient review by the WG members.

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

No. No IPR disclosure has been filed.

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

The main work of the protocol has been done by a few individuals,
whose distinguishing characteristic is that they know POP very
well. The WG as a whole agrees with it as far as they understand
POP.

  (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, idnits 2.11.14 was used to verify -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].

References are split. No obsolete references are identified.
There is no downref problem for Experimental.

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

The document specifies two IANA actions. They are well documented.

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

  This specification extends the Post Office Protocol version 3 (POP3)
  to support un-encoded international characters in user names,
  passwords, mail addresses, message headers, and protocol-level
  textual error strings.

    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?

  The WG explored a couple of different designs for this
  extension. The path chosen (a global switch to UTF-8 only mode)
  has the consensus of the WG.

    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?

  At least one existing implementation of the document exists.