-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: > 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 protected] 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 protected] 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)? > > ### > > On 9/21/12 8:44 AM, Peter Saint-Andre wrote: >> I'll post proposed text about the registration policies to this >> list in the next few days. >> >> On 9/19/12 6:42 PM, "Martin J. Dürst" wrote: >>> 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: >>>> 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. >>>>> >>>>> Le 2012-09-19 à 10:21, Peter Saint-Andre a écrit : >>>>> >>>>>> 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 >>>>>> -----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----- _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
