Skip to main content

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


(Pete Resnick)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

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

Barry Leiba Former IESG member
Yes (2012-10-20 for -08)
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 

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:
   Moreover, many reuse the same
   Stringprep profile, such as the SASL one,
   as can be seen from the groupings above.

   This algorithm is based
   on an inclusion-based approach
   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 Former IESG member
Yes (for -08)

Adrian Farrel Former IESG member
No Objection
No Objection (for -08)

Benoît Claise Former IESG member
No Objection
No Objection (2012-10-23 for -08)
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?
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...

- 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.
Brian Haberman Former IESG member
No Objection
No Objection (for -08)

Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -08)

Martin Stiemerling Former IESG member
No Objection
No Objection (for -08)

Robert Sparks Former IESG member
No Objection
No Objection (2012-10-22 for -08)
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"?
Ron Bonica Former IESG member
No Objection
No Objection (for -08)

Russ Housley Former IESG member
No Objection
No Objection (for -08)

Sean Turner Former IESG member
No Objection
No Objection (for -08)

Stephen Farrell Former IESG member
No Objection
No Objection (2012-10-22 for -08)
- 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.
Stewart Bryant Former IESG member
No Objection
No Objection (for -08)

Wesley Eddy Former IESG member
No Objection
No Objection (for -08)