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

WRITEUP for draft-ietf-precis-problem-statement

The following comments were received during IESG evaluation and IETF calls and responses are included within . To note, of all of the comments received, none were blocking, none were asking for substantial changes.


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]


For the understanding of the document, it would require much more than just RFC3454, 5894. It would also
require Unicode understanding, internationalization terms understanding, stringprep profiles, etc… To a point
where most references become normative. So we disagree and did not include any separation of normative
and non-normative. 




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



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

Stringprep Profiles are not necessarily exactly using another profile. They may (and do) have
variations, such as exceptions on their base profile or usage. Therefore, grouping might confuse the reader.
The listing was made by RFC number ordering. We agree that a better ordering would help reading. So we
change the ordering to have the similar profiles all together.




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

done



-- 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 […]"
done



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



-- 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").
done



-- 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.'
done



- 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"
Acronym expanded




- 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.
While 6.1 and 6.2 versions may not differ too much, 6.1 was the one discussed during the work of this draft and given that this work has a lot of dependencies on what Unicode does or not, it is preferable to have the current Unicode version while the work was done to be the referenced one. So we are keeping 6.1 as the reference.




- 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…
Actually, there is a sentence or two on what a profile is. Moreover, the Stringprep RFC is heavily referenced in the document.  We are not sure what else could be added without copying a large amount of text from the Stringprep RFC, which is not really the purpose of the document. So we decline this one.



- 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.
For the interest of a reader, that BOF included various presentations and meeting notes about the state of the protocols using Stringprep profiles. Therefore, the intent of the reference is to point the reader to additional context info useful for the understanding.  The reference points to the Meeting Minutes that can be retreived from the IETF proceedings.



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"?
added "Some" as suggested.



- 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.
This comment also applies to other internationalization terms used through the document. Normalization is defined more completly in RFC6365 ("Terminology Used in Internationalization in the IETF".  Instead of copying multiple paragraphs, we added text and a reference for the reader to 6365.




Section 2 could be dropped as it isn't that important to have RFC
2119 in a problem statement. 

The appendix that contains extracts of reviews and Stringprep profiles RFC do contain RFC2119 keywords. So we are keeping this section.



In Section 4:

"For example, Stringprep is based on and profiles may use NFKC
[UAX15], while IDNA2008 mostly uses NFC [UAX15]."
I suggest reviewing the references to see what background
information is required for the reader to understand "NFKC".


At the least, spelling out these acronyms on first use would be
helpful (e.g., "Unicode Normalization Form KC").


we expanded the acronyms as suggested by the document shepherd



In Section 6:

"The above suggests the following guidance for replacing
Stringprep: o  A stringprep replacement should be defined."

That sounds obvious.
rephrased.



The appendix is more informative than the rest of the draft.  The
text in the Appendix B comes out as rough notes though.


Indeed, that appendix consists of notes copied from a wiki page that
the PRECIS WG used to collect the information.

We agree with the document shepherd. no change to draft



In Section 5.3.3.2:

"It is important to identify the willingness of the protocol-using
community to accept backwards-incompatible changes."

The "tolerance for change" for several "protocol-using communities"
is rated as "not sure".  I understand that it is difficult to get
definitive answers for these questions.  It's doubtful that people
will choose "better support for different linguistic environments
against the potential side effects of backward incompatibility".
It seems that the WG has taken on an intractable problem.


Your conclusion does not follow. Yes, it is true that we're not sure
how willing some developer communities are to upgrade from Stringprep
(based on Unicode 3.2) to PRECIS (version-agile, currently Unicode
6.1). However, we know that some developer communities are in fact
willing to upgrade, and they have been more involved in the PRECIS WG.
Furthermore, in general applications don't have a choice about what
Unicode version is installed on the underlying system, so as time goes
by Stringprep will become more and more problematic. There was strong
agreement at the NEWPREP BoF to work on a common solution that all
Stringprep-using protocols could re-use. The approach taken in the
PRECIS framework specification is closely modelled on IDNA2008 and
follows the recommendations from RFC 4690. If you are going to
maintain that the PRECIS WG has taken on an intractable problem, then
I think you're also arguing that the IDNABIS WG took on an intractable
problem and that IDNA2008 failed to provide a viable solution to the
shortcomings of IDNA2003 and the Nameprep profile of Stringprep.

We agree with the document shepherd. no change to draft

[Ballot comment]
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.

[Ballot comment]
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"?

[Ballot comment]

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

[Ballot comment]
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.'

IANA has reviewed draft-ietf-precis-problem-statement-08, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Stringprep Revision and PRECIS Problem Statement) to Informational RFC


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'Stringprep Revision and PRECIS Problem Statement'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  If a protocol expects to compare two strings and is prepared only for
  those strings to be ASCII, then using Unicode codepoints in those
  strings requires they be prepared somehow.  Internationalizing Domain
  Names in Applications (here called IDNA2003) defined and used
  Stringprep and Nameprep.  Other protocols subsequently defined
  Stringprep profiles.  A new approach different from Stringprep and
  Nameprep is used for a revision of IDNA2003 (called IDNA2008).  Other
  Stringprep profiles need to be similarly updated or a replacement of
  Stringprep needs to be designed.  This document outlines the issues
  to be faced by those designing a Stringprep replacement.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-precis-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

  Informational.

Why is this the proper type of RFC?

  The document does not define any protocol and thus is not
  appropriate for the standards track. Informational is the
  usual type for problem statements.

Is this type of RFC indicated in the title page header?

  Yes.

(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

  If a protocol expects to compare two strings and is prepared
  only for those strings to be ASCII, then using Unicode
  codepoints in those strings requires they be prepared somehow.
  Internationalizing Domain Names in Applications (here called
  IDNA2003) defined and used Stringprep and Nameprep.  Other
  protocols subsequently defined Stringprep profiles.  A new
  approach different from Stringprep and Nameprep is used for
  a revision of IDNA2003 (called IDNA2008).  Other Stringprep
  profiles need to be similarly updated or a replacement of
  Stringprep needs to be designed.  This document outlines the
  issues to be faced by those designing a Stringprep replacement.

Working Group Summary

  The document records the consensus from discussion at the
  NEWPREP BoF (IETF 77, March 2010) and the resulting PRECIS WG
  regarding the problem to be solved in developing a replacement
  for the Stringprep technology in application protocols other
  than IDNA. There has not been controversy about the nature of
  the problem to be solved, and consensus was not rough.

Document Quality

  The document has provided a clear basis for work on the
  proposed PRECIS framework, and thus has served its purpose.

Personnel

  The Document Shepherd is Peter Saint-Andre.

  The Responsible Area Director is Pete Resnick.

###

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

  I have reviewed each iteration of the document while it was
  under development in the working group. I have also more
  carefully reviewed the version (08) being forwarded to the IESG.
  In my opinion, the document accurately reflects the consensus
  of the working group and is ready for publication (although on
  a final reading I noticed some small but obvious linguistic
  errors, suitable for correction by the RFC Editor).

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The document has been reviewed by a number of knowledgeable
  participants within the PRECIS WG. I do not have concerns
  about the depth or breadth of review. Naturally, the protocol
  specifications that attempt to solve the problems outlined in
  this document will require more thorough review.

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

  The entire document discusses internationalization, albeit in
  an informational fashion. Based on my experience with the topic,
  I conclude that the document is well within the bounds of good
  practices for internationalization, for instance by building on
  the work already completed in the IDNA2008 effort. In my opinion,
  no more specialized or broad reviews are needed with regard to
  this informational problem statement.

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

  It is important to publish this document so as to provide a
  foundation for the working group's protocol development. The
  area of work is complex, making a problem statement all the
  more valuable. I was uncomfortable with the fact that a prior
  version of this document foreshadowed the proposed solution by
  recommending particular string classes, but that text was
  removed (appropriately, I think) and thus I am now comfortable
  with the document in its entirety.

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

  As document shepherd I have confirmed that the authors are not
  personally aware of any IPR related to this document.

(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 in relation to this document.

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

  With the caveat that the PRECIS WG (as is true of other working
  groups focused on internationalization) does not contain a large
  number of participants, let alone active participants, I would say
  that the WG consensus for publishing this document is solid.

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

  I am not aware of any threatened appeals or areas of significant
  conflict regarding this document.

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

  The nits triggered by version -07 have been fixed in -08.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No formal reviews were appropriate for this problem statement.

(13) Have all references within this document been identified as
either normative or informative?

  Given that the document itself is informative, no normative
  references were appropriate and all of the references are
  informative.

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

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downward normative references.

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

  This document does not change the status of any existing RFCs.

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

  This document has no actions for the IANA, and that is correct.

(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 registries are to be created by this document.

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

  Not applicable.

END