Subject: [precis] WGLC: draft-ietf-precis-problem-statement-05.txt

From: Yoshiro YONEYA <[email-masked]>
Date: Wed, 9 May 2012 10:24:19 +0900

Dear all,

This message starts two weeks Working Group Last Call (WGLC) on 
draft-ietf-precis-problem-statement-05.txt (Stringprep Revision 
Problem Statement).

Please review the document and send comments to the list, the 
co-chairs, or the authors ([email-masked]) 
by the end of WGLC.

The WGLC will end on Friday, May 25th.

Regards,

-- Marc & Yoshiro, co-chairs

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 May 2012 22:37:07 -0600

> draft-ietf-precis-problem-statement-05.txt (Stringprep Revision 

Overall I think this document is in good shape. I have a few small comments.

1. In the Introduction, I think it would be useful to explain a bit more
clearly the difference between an inclusion-based approach (only the
codepoints that are explicitly included will be allowed) and an
exclusion-based approach (all codepoints are allowed unless explicitly
excluded). There's text about this in Section 4.2.4, so perhaps we could
simply move that up.

2. Section 4.2.2 quotes UAX15. To provide a bit more context for the
statement about NFKC perhaps not being appropriate for comparing human
names, I suggest adding a sentence like the following after that quote:
"In general, it can be said that NFKC is more aggressive about finding
matches between codepoints than NFC."

3. In Section 4.2.2, spell out "LDH" on first use (and perhaps cite one
of the DNS specs on the topic).

4. Section 5 states that "Recommendations for handling protocol
incompatibilities resulting from changes to Unicode are required", but
it seems to me that this is a matter for application protocols that use
the replacement for stringprep, not the replacement itself.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 May 2012 11:25:08 +0200

Hi!  Here is my review of the document.  I think it is is in pretty good
shape, I have one major concern but I'm sure it can be resolved.

/Simon

MAJOR:

*) Section 4.3.4 specify three classes of strings.  As a naive reader
that tries to read this document as an introduction, I cannot really
follow how you got to those three categories from the rest of the
document.  Are you trying to match the identifier types discussed in
4.1.1?  If so, I don't think the names are very well chosen.  I think
some more motivational text around how you get to these categories
would be useful.  They appear to be quite guiding of you form the rest
of the technical work (compare appendix A/B).

MINOR:

*)
I'm having trouble parsing the first sentence of the abstract:

   Using Unicode codepoints in protocol strings that expect comparison
   with other strings requires preparation of the string that contains
   the Unicode codepoints.

Isn't there something missing here?  I.e., something like "expect
comparison to work" instead of "expect comparison".  Further, I don't
think the statement is accurate: comparison work when it is implemented
correctly (i.e., Unicode and context aware) -- what will not work is
for example _binary_ comparison, which is what I think you are getting
at.

*)
This sentence in the abstract:

   Internationalizing Domain Names in
   Applications (IDNA2003) defined and used Stringprep and Nameprep.

suggests IDNA2003 was called IDNA2003 at the time.  May I suggest
s/IDNA2003/here called IDNA2003/ instead?  A reader familiar only with
RFC 3490 etc may be confused by the term IDNA2003, and at this point of
this document the IDNA2008 concepts have not been introduced yet.

The same applies to the introduction section where the term IDNA2003 is
used without introduction, and before the IDNA2008 documents are
referenced.

*)
The document refers to some URLs like this:
   However, a review [1] of these protocol specifications found that
...
[1]  <http://www.ietf.org/proceedings/78/slides/precis-2.pdf>

I suspect the RFC Editor will require normal attribution and titles. 
Looking through these references, they all seem quite easy to fix.

*)
Section 3 reads:

   The consensus [4] of the BOF attendees is that it would be highly
   desirable to have a replacement of Stringprep, with similar
   characteristics to IDNA2008.

I am hoping this discussion and consensus guaging went back to the
list. Usually, BOFs doesn't make direct decisions that have bearing on
IETF documents.

*)
Section 4.2.4 contains this observation:

   IDNA2008 may be a poor model for what other protocols ought to do in
   this case, because it is designed to support an old protocol that is
   designed to operate on the scale of the entire Internet.  Moreover,
   IDNA2008 is intended to be deployed without any change to the base
   DNS protocol.  Other protocols may aim at deployment in more local
   environments, or may have protocol version negotiation built in.

I think this is an important observation, and one that applies to
almost all topics of IDNA2008 vs PRECIS, and not only the topic
discussed in section 4.2.4, i.e., prohibited characters.  Could this be
moved or duplicated at a more high-level?  When I look, only the
Introduction section seems appropriate, but there may be other places
too.

A more general thought here: I'd hate to see new protocols use
sub-optimal Unicode behaviour just because they re-use IDNA2008/PRECIS
that have several considerations for older protocols and backwards
compatibility.  Possibly there is room for some recommendations on what
new protocols should do as the state-of-the-art.  I'm not convinced
this is easy to infer from the PRECIS work today.

*) 
   Accordingly, as IDNA2008,a Stringprep replacement that intends to be
                            ^

typo, insert SPC

*)
Spell out 'i18n':
o  Protocols share similar characteristics of strings.  Therefore,
      defining i18n preparation algorithms for the smallest set of
      string classes may be sufficient for most cases, providing
      coherence among a set of related protocols or protocols where
      identifiers are exchanged.

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 May 2012 09:00:52 -0600

> of the technical work (compare appendix A/B).

Hi Simon,

Yes, I think it might be better to let the framework document make an
argument for those three string classes, rather than put it in the
problem statement.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 May 2012 13:22:09 -0400

Hi Simon and Peter,

Thanks for the reviews!  One question:

> > document.

> argument for those three string classes, rather than put it in the

Is the suggestion here to remove the string classes entirely from this
document, and leave it to the framework?  

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 May 2012 11:30:44 -0600

> document, and leave it to the framework?  

I think so. Let the problem statement define the problem and the
framework define the solution.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 May 2012 20:00:02 +0200

> document, and leave it to the framework?

That works for me.  I'm hoping it is well explained in the framework. :-)

Thanks,
/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 May 2012 14:01:14 -0600

> That works for me.  I'm hoping it is well explained in the framework. :-)

I'm pushing hard to submit a revised framework I-D soon!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2012 18:47:47 +0100

I've reviewed the document and didn't find anything beyond what was 
already reported by Peter and Simon. I think the document is in a good 
shape.