PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
draft-ietf-precis-framework-23

[Ballot comment]

Last time this came around I had the comments below.
While Barry no longer has a DISCUSS, I'd still be
interested in chatting a bit about these. (Apologies
that I've not had time to re-read the draft though, so
feel free to just tell me these comments are OBE if
that's the case.)

"
- 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
nicely:-)
"

[Ballot comment]
A nit:

  b.  Comparing two output strings to determine if they equivalent,
                                                        ^are
      typically through octet-for-octet matching to test for "bit-
      string identity" (e.g., to make an access decision for purposes
      of authentication or authorization as further described in
      [RFC6943]).

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-precis-framework-22.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments:

IANA understands that, upon approval of this document, the authors request the creation of three registries in support of the PRECIS Framework. As far as IANA can tell, there have never been registries created for PRECIS in the past. In consultation with the authors, IANA understands that there will be a new PRECIS-specific master registry created on the IANA Matrix to hold the three registries described below.

First, IANA will create a new registry called the PRECIS Derived Property Value Registry. This new registry will contain the Derived Properties for the versions of Unicode that are released after (and including) version 7.0 of Unicode. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the rules specified under Section 8 and Section 9 in the current document. The registry will only be created when a designated expert is made available to assist IANA in the initiation of the registry. Changes to the rules that are used to generate the table of derived property values, and thus the registry itself, are done through IETF Review as defined by RFC 5226.

IANA understands that this new registry will have no initial values when it is first established.

Second, IANA will create a new registry called the PRECIS Base Classes Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through RFC Required, as defined in RFC 5226.

There are two initial registrations in the registry, as follows:

Base Class: FreeformClass.
Description: A sequence of letters, numbers, symbols, spaces, and other code points that is used for free-form strings.
Specification: Section 4.3 of [ RFC-to-be ].

Base Class: IdentifierClass.
Description: A sequence of letters, numbers, and symbols that is used to identify or address a network entity.
Specification: Section 4.2 of [ RFC-to-be ].

Third, IANA will create a new registry called the PRECIS Profiles Registry. This new registry has a registration template in the document submitted for approval. Maintenance of the registry will be through Expert Review, as defined in RFC 5226.

In consultation with the authors, IANA understands that the new registry will have no initial values when it is first established.

IANA understands that these three actions are the only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'PRECIS Framework: Preparation, Enforcement, and Comparison of
  Internationalized Strings in Application Protocols'
  as Proposed Standard

This is a second Last Call. Even though this document has already been
through IESG Evaluation and was approved pending an RFC Editor note to
address some comments, significant enough issues were raised and changes
were made that a new Last Call and IESG Evaluation is prudent.

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 2015-02-19. 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


  Application protocols using Unicode characters in protocol strings
  need to properly handle such strings in order to enforce
  internationalization rules for strings placed in various protocol
  slots (such as addresses and identifiers) and to perform valid
  comparison operations (e.g., for purposes of authentication or
  authorization).  This document defines a framework enabling
  application protocols to perform the preparation, enforcement, and
  comparison of internationalized strings ("PRECIS") in a way that
  depends on the properties of Unicode characters and thus is agile
  with respect to versions of Unicode.  As a result, this framework
  provides a more sustainable approach to the handling of
  internationalized strings than the previous framework, known as
  Stringprep (RFC 3454).  This document obsoletes RFC 3454.




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

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


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

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

UPDATE AFTER DISCUSSION:
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.

[Ballot comment]

- 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
nicely:-)

[Ballot comment]
- 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 (https://tools.ietf.org/html/rfc6020#section-7.3)
IPFIX data types (RFC 7011)
AAA
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.


- https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/
      There is a normative downref to draft-ietf-precis-mappings (an Informative document).
I see that draft-ietf-precis-mappings in the informative references.

[Ballot discuss]
I will move to a strong "yes" on this, once we have some discussion of the registry defined in Section 9.1.

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 general, I see that IANA has asked several questions in its review, and those questions haven't been responded to (and, unusually, the IANA review is in the IESG mailing list archive but *not* in the document history in the datatracker).  They should be given a response.

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?

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

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

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

4.1:

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:

OLD
      fullname = namepart [1*(1*SP namepart)]
      namepart = 1*(idpoint)
NEW
      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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'PRECIS Framework: Preparation and Comparison of Internationalized
  Strings in Application Protocols'
  as Proposed Standard

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 2014-04-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


  Application protocols using Unicode characters in protocol strings
  need to properly prepare such strings in order to perform valid
  comparison operations (e.g., for purposes of authentication or
  authorization).  This document defines a framework enabling
  application protocols to perform the preparation and comparison of
  internationalized strings ("PRECIS") in a way that depends on the
  properties of Unicode characters and thus is agile with respect to
  versions of Unicode.  As a result, this framework provides a more
  sustainable approach to the handling of internationalized strings
  than the previous framework, known as Stringprep (RFC 3454).  This
  document obsoletes RFC 3454.

This document makes a normative reference to RFC 20, which
predates document statuses and therefore may be a downward
reference.

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

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


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

1. Summary

The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick.

Application protocols using Unicode characters in protocol strings
need to properly prepare such strings in order to perform valid
comparison operations (e.g., for purposes of authentication or
authorization).  This document defines a framework enabling
application protocols to perform the preparation and comparison of
internationalized strings ("PRECIS") in a way that depends on the
properties of Unicode characters and thus is agile with respect to
versions of Unicode. 

This document obsoletes RFC 3454.

The document is suitable for Standard Track.

2. Review and Consensus

The approach used by the document is similar to IDNA 2008 approach
(use of Unicode character properties for deciding what to do with characters)
and thus wasn't controversial.

The WG spent some time deciding how many classes need to be defined
and what kind of class is suitable for "profiling" for different purposes.
In particular the discussion of use of spaces in Identifier class took a bit
of time. But the WG converged at the end.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

There is a normative downref to draft-ietf-precis-mappings (an Informative document).

ID-Nits also complains a normative reference to RFC 20, because the RFC status is not known.

1. Summary

The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick.

Application protocols using Unicode characters in protocol strings
need to properly prepare such strings in order to perform valid
comparison operations (e.g., for purposes of authentication or
authorization).  This document defines a framework enabling
application protocols to perform the preparation and comparison of
internationalized strings ("PRECIS") in a way that depends on the
properties of Unicode characters and thus is agile with respect to
versions of Unicode. 

This document obsoletes RFC 3454.

The document is suitable for Standard Track.

2. Review and Consensus

The approach used by the document is similar to IDNA 2008 approach
(use of Unicode character properties for deciding what to do with characters)
and thus wasn't controversial.

The WG spent some time deciding how many classes need to be defined
and what kind of class is suitable for "profiling" for different purposes.
In particular the discussion of use of spaces in Identifier class took a bit
of time. But the WG converged at the end.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

There is a normative downref to draft-ietf-precis-mappings (an Informative document).

ID-Nits also complains a normative reference to RFC 20, because the RFC status is not known.