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 _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
