Subject: [precis] registration policy for subclasses

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Sep 2012 07:21:03 -0700

Currently, the RFC 5226 registration policy defined for subclasses is
"First Come, First Served". Do we think that a slightly higher review
standard is needed for subclasses, for instance "Expert Review" or
even "Specification Required"? Although in general I am in favor of
the lowest bar possible for registration, it strikes me that for
subclasses we might want something more than "First Come, First
Served" (IMHO "Expert Review" would be enough). For base class usage
registrations, I think "First Come, First Served" is appropriate,
although I would be open to "Expert Review" for those registrations as
well.)

Peter

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

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 19 Sep 2012 11:33:14 -0400

I think that Expert review is probably the best for any kind. The main reason to me is to have someone to help the "customer", such as: have you really thought about reusing one of the current defined classes instead of creating a new one?  have you thought about the transition problem? …    Kind of a way to interact with the "customer" before too late. We do want to minimize the number of sub-classes (or in general classes), therefore having an "interception" mechanism would be useful.

Marc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 19 Sep 2012 12:42:29 -0700

Hi Marc, that makes sense for subclasses. I'm not as concerned about
uses of the base classes, but there also I think that it would be good
to provide some guidance for our customers ("did you choose the right
Unicode normalization form, casemapping rules, and bidirectional
handling?"), so I'd be fine with Expert Review for both subclass
registrations and usage registrations.

Thanks for the feedback!

Peter

On 9/19/12 8:33 AM, Marc Blanchet wrote:
> I think that Expert review is probably the best for any kind. The
> main reason to me is to have someone to help the "customer", such as:
> have you really thought about reusing one of the current defined
> classes instead of creating a new one?  have you thought about the
> transition problem? …    Kind of a way to interact with the
> "customer" before too late. We do want to minimize the number of
> sub-classes (or in general classes), therefore having an
> "interception" mechanism would be useful.
> 
> Marc.
> 
>> Currently, the RFC 5226 registration policy defined for subclasses
>> is "First Come, First Served". Do we think that a slightly higher
>> review standard is needed for subclasses, for instance "Expert
>> Review" or even "Specification Required"? Although in general I am
>> in favor of the lowest bar possible for registration, it strikes me
>> that for subclasses we might want something more than "First Come,
>> First Served" (IMHO "Expert Review" would be enough). For base
>> class usage registrations, I think "First Come, First Served" is
>> appropriate, although I would be open to "Expert Review" for those
>> registrations as well.)
>> 
>> Peter
>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 20 Sep 2012 09:42:42 +0900

I definitely agree with Peter and Marc. For decisions that essentially 
involve the whole Unicode repertoire, some "customer advice" will be 
appreciated. Ideally, that should happen on a mailing list, so that 
others than the Expert Reviewer him/herself may be able to contribute.

Regards,   Martin.

On 2012/09/20 4:42, Peter Saint-Andre wrote:
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Sep 2012 08:44:38 -0600

I'll post proposed text about the registration policies to this list in
the next few days.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Sep 2012 11:37:08 -0600

Here is proposed text for the IANA considerations related to the
subclasses registry and the usage registry. I've changed the information
requested for subclasses because I noticed (while working on 6122bis)
that there was a lot of overlap between the subclass registrations and
the usage registrations. I've also added bullet lists of topics that
reviewers might focus on. Feedback would be appreciated.

Thanks!

/psa

###

10.3.  PRECIS Subclasses Registry

   IANA is requested to create a registry of subclasses that use the
   PRECIS base string classes.  In accordance with [RFC5226], the
   registration policy is "Expert Review".  This policy was chosen in
   order to ensure that "customers" of PRECIS receive appropriate
   guidance regarding the sometimes complex and subtle
   internationalization issues related to subclassing of PRECIS base
   classes.

   The registration template is as follows:

   Subclass:  [the name of the subclass]
   Base Class:  [which base class is being subclassed]
   Exclusions:  [a brief description of the specific code points that
      are excluded or of the properties based on which characters are
      excluded, e.g., "Eight legacy characters in the ASCII range." or
      "Any character that has a compatibility equivalent, i.e., the
      HasCompat category."]
   Specification:  [a pointer to relevant documentation, such as an RFC
      or Internet-Draft]

   In order to request a review, the registrant shall send a completed
   template to the [email-masked] list or its designated successor.

   There are several factors to focus on while reviewing subclass
   registrations:

   o  Is the problem well-defined?
   o  Is it clear what applications will use this subclass?
   o  Would an existing base class or subclass solve the problem?
   o  Are the defined exclusions a reasonable solution to the problem
      for the relevant applications?
   o  Is the subclass clearly defined?
   o  Does the subclass reduce the degree to which human users would be
      surprised by application behavior (the "principle of least user
      surprise")?
   o  Is the subclass based on an appropriate dividing line between user
      interface (culture, context, intent, locale, device limitations)
      and the use of conformant strings in protocol elements?
   o  Does the subclass introduce any new security concerns (e.g., false
      positives for authentication or authorization)?

10.4.  PRECIS Usage Registry

   IANA is requested to create a registry of application protocols that
   use the base string classes.  The registry will include one entry for
   each use (e.g., if a protocol uses both the NameClass and the
   FreeClass then the specification for that protocol would submit two
   registrations).  In accordance with [RFC5226], the registration
   policy is "Expert Review".  This policy was chosen in order to ensure
   that "customers" of PRECIS receive appropriate guidance regarding the
   sometimes complex and subtle internationalization issues related to
   use of PRECIS base classes.

   The registration template is as follows:

   Applicability:  [the specific protocol elements to which this usage
      applies, e.g., "Localparts in XMPP addresses."]
   Base Class:  [the base string class that is being used or subclassed]
   Subclass:  [whether the protocol has defined a subclass of the base
      class and, if so, the name of the subclass, e.g., "Yes,
      LocalpartNameClass."]
   Normalization:  [which Unicode normalization form is applied, e.g.,
      "NFC"]
   Casemapping:  [the behavioral rule for handling of case, e.g., "Map
      uppercase and titlecase characters to lowercase."]
   Additional Mappings:  [any additional mappings are required or
      recommended, e.g., "Map non-ASCII space characters to ASCII
      space."]
   Directionality:  [the behavioral rule for handling of right-to-left
      code points, e.g., "The 'Bidi Rule' defined in RFC 5893 applies."]
   Specification:  [a pointer to relevant documentation, such as an RFC
      or Internet-Draft]

   In order to request a review, the registrant shall send a completed
   template to the [email-masked] list or its designated successor.

   There are several factors to focus on while reviewing usage
   registrations:

   o  Does the specification define what kinds of applications are
      involved and the protocol elements to which this usage applies?
   o  Is there a base class or subclass that would be more appropriate
      to use?
   o  Are the normalization, casemapping, additional mappings, and
      directionality handling appropriate for the intended use?
   o  Does the usage reduce the degree to which human users would be
      surprised by application behavior (the "principle of least user
      surprise")?
   o  Is the usage based on an appropriate dividing line between user
      interface (culture, context, intent, locale, device limitations)
      and the use of conformant strings in protocol elements?
   o  Does the usage introduce any new security concerns (e.g., false
      positives for authentication or authorization)?

###

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Sep 2012 12:53:14 -0600

One further thought: would it make sense to capture the fact that some
new precis usages obsolete a old stringprep profiles?

For example:

   Applicability:  Localparts in XMPP addresses.
   Base Class:  NameClass
   Subclass:  Yes, LocalpartNameClass.
   Obsoletes:  Nodeprep profile of stringprep.
   [...]

Peter

On 9/21/12 11:37 AM, Peter Saint-Andre wrote:
> subclasses registry and the usage registry. I've changed the
> information requested for subclasses because I noticed (while
> working on 6122bis) that there was a lot of overlap between the
> subclass registrations and the usage registrations. I've also added
> bullet lists of topics that reviewers might focus on. Feedback
> would be appreciated.
> 
> Thanks!
> 
> /psa
> 
> ###
> 
> Subclass:  [the name of the subclass] Base Class:  [which base
> class is being subclassed] Exclusions:  [a brief description of the
> specific code points that are excluded or of the properties based
> on which characters are excluded, e.g., "Eight legacy characters in
> the ASCII range." or "Any character that has a compatibility
> equivalent, i.e., the HasCompat category."] Specification:  [a
> pointer to relevant documentation, such as an RFC or
> Internet-Draft]
> 
> In order to request a review, the registrant shall send a
> completed template to the [email-masked] list or its designated
> successor.
> 
> o  Is the problem well-defined? o  Is it clear what applications
> will use this subclass? o  Would an existing base class or subclass
> solve the problem? o  Are the defined exclusions a reasonable
> solution to the problem for the relevant applications? o  Is the
> subclass clearly defined? o  Does the subclass reduce the degree to
> which human users would be surprised by application behavior (the
> "principle of least user surprise")? o  Is the subclass based on an
> appropriate dividing line between user interface (culture, context,
> intent, locale, device limitations) and the use of conformant
> strings in protocol elements? o  Does the subclass introduce any
> new security concerns (e.g., false positives for authentication or
> authorization)?
> 
> IANA is requested to create a registry of application protocols
> that use the base string classes.  The registry will include one
> entry for each use (e.g., if a protocol uses both the NameClass and
> the FreeClass then the specification for that protocol would submit
> two registrations).  In accordance with [RFC5226], the
> internationalization issues related to use of PRECIS base classes.
> 
> Applicability:  [the specific protocol elements to which this
> usage applies, e.g., "Localparts in XMPP addresses."] Base Class:
> [the base string class that is being used or subclassed] Subclass:
> [whether the protocol has defined a subclass of the base class and,
> if so, the name of the subclass, e.g., "Yes, LocalpartNameClass."] 
> Normalization:  [which Unicode normalization form is applied,
> e.g., "NFC"] Casemapping:  [the behavioral rule for handling of
> case, e.g., "Map uppercase and titlecase characters to
> lowercase."] Additional Mappings:  [any additional mappings are
> required or recommended, e.g., "Map non-ASCII space characters to
> ASCII space."] Directionality:  [the behavioral rule for handling
> of right-to-left code points, e.g., "The 'Bidi Rule' defined in RFC
> 5893 applies."] Specification:  [a pointer to relevant
> documentation, such as an RFC or Internet-Draft]
> 
> In order to request a review, the registrant shall send a
> completed template to the [email-masked] list or its designated
> successor.
> 
> involved and the protocol elements to which this usage applies? o
> Is there a base class or subclass that would be more appropriate to
> use? o  Are the normalization, casemapping, additional mappings,
> and directionality handling appropriate for the intended use? o
> Does the usage reduce the degree to which human users would be 
> surprise")? o  Is the usage based on an appropriate dividing line
> between user interface (culture, context, intent, locale, device
> limitations) and the use of conformant strings in protocol
> elements? o  Does the usage introduce any new security concerns
> (e.g., false positives for authentication or authorization)?
> 
> ###
> 
>> I'll post proposed text about the registration policies to this
>> list in the next few days.
>> 
>>> I definitely agree with Peter and Marc. For decisions that
>>> essentially involve the whole Unicode repertoire, some
>>> "customer advice" will be appreciated. Ideally, that should
>>> happen on a mailing list, so that others than the Expert
>>> Reviewer him/herself may be able to contribute.
>>> 
>>> Regards,   Martin.
>>> 
>>>> Hi Marc, that makes sense for subclasses. I'm not as
>>>> concerned about uses of the base classes, but there also I
>>>> think that it would be good to provide some guidance for our
>>>> customers ("did you choose the right Unicode normalization
>>>> form, casemapping rules, and bidirectional handling?"), so
>>>> I'd be fine with Expert Review for both subclass 
>>>>> I think that Expert review is probably the best for any
>>>>> kind. The main reason to me is to have someone to help the
>>>>> "customer", such as: have you really thought about reusing
>>>>> one of the current defined classes instead of creating a
>>>>> new one?  have you thought about the transition problem? …
>>>>> Kind of a way to interact with the "customer" before too
>>>>> late. We do want to minimize the number of sub-classes (or
>>>>> in general classes), therefore having an "interception"
>>>>> mechanism would be useful.
>>>>> 
>>>>> Marc.
>>>>> 
>>>>>> Currently, the RFC 5226 registration policy defined for
>>>>>> subclasses is "First Come, First Served". Do we think
>>>>>> that a slightly higher review standard is needed for
>>>>>> subclasses, for instance "Expert Review" or even
>>>>>> "Specification Required"? Although in general I am in
>>>>>> favor of the lowest bar possible for registration, it
>>>>>> strikes me that for subclasses we might want something
>>>>>> more than "First Come, First Served" (IMHO "Expert
>>>>>> Review" would be enough). For base class usage
>>>>>> registrations, I think "First Come, First Served" is 
>>>>>> appropriate, although I would be open to "Expert Review"
>>>>>> for those registrations as well.)
>>>>>> 
>>>>>> Peter
>>>>>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 22 Sep 2012 20:08:19 +0900

On 2012/09/22 3:53, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

What does "obsoletes" mean here? Is the result still the same (just a 
different framework), or are changes to the definition allowed?

Regards,   Martin.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBct5oACgkQNL8k5A2w/vy/JwCeOuSYD6Pb6qkxjhDjXa7aPOqU
> 8JsAoJQj8n5SO2FAOckN63yUEXGWM6Sa
> =ekNz
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 23 Sep 2012 11:09:25 -0600

On 9/22/12 5:08 AM, "Martin J. Dürst" wrote:
> On 2012/09/22 3:53, Peter Saint-Andre wrote: One further thought:
> would it make sense to capture the fact that some new precis usages
> obsolete a old stringprep profiles?
> 
>> What does "obsoletes" mean here? Is the result still the same
>> (just a different framework), or are changes to the definition
>> allowed?

Good question. I mean "replaces" or "supersedes", where going forward
the new Precis usage is intended to be used instead of the old
Stringprep profile when handling the relevant protocol elements. For
example, the Precis profiles we're defining in draft-ietf-xmpp-6122bis
for XMPP localparts and resourceparts are intended to be used in the
future instead of the Nodeprep and Resourceprep profiles of Stringprep
first defined in RFC 3920. Although in the XMPP community we are
working to make sure that the new Precis profiles have very similar
output to the old Stringprep profiles (i.e., the same result using a
different framework), I think any changes to the definition are a
matter for the application protocol and not the Precis framework.

Another way to handle this matter is to make sure that the application
protocol specs contain an IANA action to change the status of the
relevant Stringprep profile(s):

http://www.iana.org/assignments/stringprep-profiles/stringprep-profiles.xml

Peter

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 24 Sep 2012 16:06:02 +0900

Given that there are quite a lot of ways in which this "obsoletion" can 
happen, I think an entry of the form

Obsoletes: foo

is totally inappropriate. It should be replaced by some more detailled 
description, such as (just an example):

Historical Relationship: This registration is intended to replace the 
"foo" stringprep profile wherever possible. It the data has been 
carefully checked to avoid any changes from the "foo" profile, with the 
exception that this profile is no longer based on a fixed version of 
Unicode and therefore includes more characters. Also, the two characters 
BAR and BAZ were excluded because they lead to heavy ... in practice. 
Specifications are recommended to update their references to this 
registration after a careful analysis of the consequences.

As I said, this is just an example, but I hope it shows the idea.

Regards,    Martin.

On 2012/09/24 2:09, Peter Saint-Andre wrote:
> iEYEARECAAYFAlBfQkUACgkQNL8k5A2w/vzGSACgtudyUwkQ48ssylX2LjC9OLja
> Oi8AoNG6xUGKCHBKnk2M1qNa4OckcQRl
> =QnFO

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Sep 2012 08:41:33 -0600

You're probably right. Those "in the know" who actually read the
relevant specs are well aware of these historical relationships.
Tracking which PRECIS usages replace which Stringprep profiles might
be something that is better left to a wiki, not an IANA registry.

On 9/24/12 1:06 AM, "Martin J. Dürst" wrote:
> Given that there are quite a lot of ways in which this "obsoletion"
> can happen, I think an entry of the form
> 
> Obsoletes: foo
> 
> is totally inappropriate. It should be replaced by some more
> detailled description, such as (just an example):
> 
> Historical Relationship: This registration is intended to replace
> the "foo" stringprep profile wherever possible. It the data has
> been carefully checked to avoid any changes from the "foo" profile,
> with the exception that this profile is no longer based on a fixed
> version of Unicode and therefore includes more characters. Also,
> the two characters BAR and BAZ were excluded because they lead to
> heavy ... in practice. Specifications are recommended to update
> their references to this registration after a careful analysis of
> the consequences.
> 
> On 2012/09/24 2:09, Peter Saint-Andre wrote: On 9/22/12 5:08 AM,
> "Martin J. Dürst" wrote:
>>>> On 2012/09/22 3:53, Peter Saint-Andre wrote: One further
>>>> thought: would it make sense to capture the fact that some
>>>>> What does "obsoletes" mean here? Is the result still the
>>>>> same (just a different framework), or are changes to the
>>>>> definition allowed?
> 
> Good question. I mean "replaces" or "supersedes", where going
> forward the new Precis usage is intended to be used instead of the
> old Stringprep profile when handling the relevant protocol
> elements. For example, the Precis profiles we're defining in
> draft-ietf-xmpp-6122bis for XMPP localparts and resourceparts are
> intended to be used in the future instead of the Nodeprep and
> Resourceprep profiles of Stringprep first defined in RFC 3920.
> Although in the XMPP community we are working to make sure that the
> new Precis profiles have very similar output to the old Stringprep
> profiles (i.e., the same result using a different framework), I
> think any changes to the definition are a matter for the
> application protocol and not the Precis framework.
> 
> Another way to handle this matter is to make sure that the
> application protocol specs contain an IANA action to change the
> status of the relevant Stringprep profile(s):
>