PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols

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

Barry Leiba (was Discuss) Yes

Comment (2014-04-24 for -16)
No email
send info
After discussion, I'm moving this to a non-blocking comment.  I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future.

The registry created in Section 9.1 is very odd indeed.  I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be.  In the IANA review, it's clear that they're not sure what's going to happen here.

But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately.  Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry.

It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely.

Why was it done this way, and what is the plan to get the registry content specified in a reasonable time?  Should approval of the document wait for that content to be specified?  Or are we really expecting to approve the document with the content of the registry left open?

The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome.

It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document.  The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert.  That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture.  When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again.  It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now.

As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed.

(Pete Resnick) Yes

Comment (2014-04-18 for -15)
No email
send info
The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.)

Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference.

3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here.

3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say:

   Any code points that are not yet designated in the Unicode character
   set are considered Unassigned for purposes of the XXXClass, and such
   code points are to be treated as Disallowed.


Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.)

Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form".

4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 

4.2: A bit of ABNF neatening:

      fullname = namepart [1*(1*SP namepart)]
      namepart = 1*(idpoint)
      fullname = namepart *(1*SP namepart)
      namepart = 1*idpoint

9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass.

9.3: It might be nice to note the naming convention from 4.1 in the template.

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Comment (2014-04-24 for -16)
No email
send info
- More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here.

You have identified IdentifierClass and FreeformClass.
As OPS AD, I'm wondering whether future OPS data models should take these classes into account.
Let me explain. We have:
	SMI Textual Convention (RFC 2579). For example: SnmpAdminString
	YANG typedef (
	IPFIX data types (RFC 7011)
Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? 
I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. 

      There is a normative downref to draft-ietf-precis-mappings (an Informative document).
I see that draft-ietf-precis-mappings in the informative references.

Alissa Cooper No Objection

Comment (2014-04-21 for -15)
No email
send info
Nice work. I have one comment in Section 4.3, which says:

One consequence of disallowing space characters in the
   IdentifierClass might be to effectively discourage the use of ASCII
   space (or, even more problematically, non-ASCII space characters)
   within identifiers created in newer application protocols; given the
   challenges involved in properly handling space characters in
   identifiers and other protocol strings, the Working Group considered
   this to be a feature, not a bug.

I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence:

One consequence of disallowing space characters in the
   IdentifierClass might be to effectively discourage the use of ASCII
   space (or the even more problematic non-ASCII space characters)
   within identifiers created in newer application protocols;

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-04-22 for -16)
No email
send info
Not my area of expertise, but ... :-)

Why isn't BCP18 an important reference?

(Stephen Farrell) No Objection

Comment (2014-04-24 for -16)
No email
send info
- I agree with Bary's discuss - it seems weird to not
have the initial registries in hand when the RFC is
being issued. People will, I guess, implement from
Appendix A here anyway, so why not either delete this
and get the registry in place, or else make Appendix A
be the initial registry content.

7.7: This uses the empty set, which is puzzling. I think
you mean that this set is to be populated by the DE in
the IANA registries but if so, saying so would be good.

10.5: This says that a) its all too hard but also b)
"Nevertheless, specifications for application protocols
that use this framework MUST describe how confusable
characters can be abused to compromise the security of
systems that use the protocol in question, along with any
protocol-specific suggestions for overcoming those
threats." That seems like a 6919 MUST (but we know you
won't) to me. Is that a good plan? 

10.6: Prompted by the secdir review, it might be worth a
few words on password hashing, which is very common.  E.g.
say that the canonical form is input to hashing and
therefore just can't be mucked about with. (But say that

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

Comment (2014-04-23 for -16)
No email
send info
In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7.

Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice.

(Kathleen Moriarty) No Objection

Comment (2014-04-22 for -16)
No email
send info
Thanks for addressing the SecDir comments so quickly!

(Martin Stiemerling) No Objection