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
>>>>>
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
