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
