Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)
RFC 6885

Note: This ballot was opened for revision 08 and is now closed.

Barry Leiba Yes

Comment (2012-10-20 for -08)
No email
send info
Well done.  I've a number of non-blocking comments:

The shepherd writeup says this:
   Given that the document itself is informative, no normative 
   references were appropriate and all of the references are 
   informative. 

I think this is wrong.  Normative references are those that are necessary to the understanding of the document at hand, and they exist even for Informational documents.  In this case, I think the following are normative:
Stringprep [RFC3454]
IDNA Rationale [RFC5894]

You should probaby scrub this for consistent use of "Stringprep" (vs "stringprep").

-- Section 1 --
In the list of known Stringprep uses, I would find it easier to read and more convenient if items based on the same profile were grouped in sub-bullets.  Something like this (significantly abbreviating here):

o  The Nameprep profile
   o  IAX using Nameprep
o  NFSv4 and NFSv4.1
o  The iSCSI profile
o  The Nodeprep and Resourceprep profiles
o  The SASLprep profile
   o  IMAP4 using SASLprep
   o  Plain SASL using SASLprep
   o  NNTP using SASLprep
o  The LDAP profile
   o  PKIX subject identification using LDAPprep
   o  PKIX CRL using LDAPprep
o  The unicode-casemap Unicode Collation

Then you can also note that in the following paragraph like this:
NEW
   Moreover, many reuse the same
   Stringprep profile, such as the SASL one,
   as can be seen from the groupings above.

OLD
   This algorithm is based
   on an inclusion-based approach
NEW
   This algorithm uses
   an inclusion-based approach

-- Section 4 --
   For example, Stringprep is based on and profiles may
   use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15].

Because of the citations and because it's not central to what you're saying, I don't think it's necessary to expand NFKC and NFC.  But it might be helpful to say something like, "for example, for normalization Stringprep [...]"

   a localpart which is similar to a username and used
   for authentication, a domainpart which is a domain name and a
   resource part which is less restrictive than the localpart.

Because of the complexity of this and the imbedded "and" in the first item, this list really demands the Oxford comma, "domain name, and".  I'm not sure the RFC Editor will get it right.

-- Section 5.2.6 --
Is "phishing" now a sufficiently common and lasting term that we can use it without explanation?  In any case, in the next sentence the issue *is* to be considered (not "are").

-- Section 7 --
To address the SecDir review comment, you might add something like this: "See the Stringprep Security Considerations, [RFC3454] Sevtion 9.  See also the analyses in the subsections of Appendix B, below.'

(Pete Resnick) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-10-23 for -08)
No email
send info
No objection to the publication of this document, but I would like to have the following points discussed

- Why do you have a temporary WG name in the draft title? Who will remember what PRECIS is in 10 years from now?
Proposal:
1. either explain PRECIS in the draft. At the very minimum the acronym.
2. Or remove PRECIS: Stringprep Revision Problem Statement
3. Alternatively, replace PRECIS: maybe "Stringprep Revision and IDNA2008 Problem Statement"

- Why don't you refer to the latest version of the unicode, i.e. version 6.2?
The draft still refers to version 6.1.

- You actually never explained what a (Stringprep) profile is, and what it contains.
For new comers who don't have the full IDNA background, a couple of extra sentences would be welcome...

EDITORIAL:
- What's the point to have a reference to [NEWPREP], since you don't mention where they are?

  During IETF 77 (March 2010), a BOF discussed the current state of the
   protocols that have defined Stringprep profiles [NEWPREP].

   [NEWPREP]  "Newprep BoF Meeting Minutes", March 2010.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-10-22 for -08)
No email
send info
- 5.2.2 might have been a good place to explain what
normalization means. You can sort of get it from the
text, but might be nicer to add a definition.

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Robert Sparks) No Objection

Comment (2012-10-22 for -08)
No email
send info
The list of Known IETF Specifications in the introduction is presented as a complete list. I believe it is already a little stale (see RFC6063 for example). Should the list be updated to those known specifications at the time the RFC is published (and a datestamp added to qualify the statement), or should the statement be softened to "Some known"?

(Martin Stiemerling) No Objection

(Sean Turner) No Objection