Re: [precis] WGLC: draft-ietf-precis-framework-09.txt

[Peter Saint-Andre <[e-mail]>]

On 10/08/2013 05:03 PM, Peter Saint-Andre wrote:
> On 10/07/2013 04:21 AM, "Martin J. Dürst" wrote:
>> On 2013/10/05 12:07, Andrew Sullivan wrote:
>>
>>> The paragraph in section 3.1 starting, "Although members of the
>>> community discussed the possibility of defining other PRECIS string
>>> classes " read oddly to me.
>>
>> Same here, but for different reasons. The WG is publishing a document 
>> with user name and password profiles at (roughly, at least?) the same 
>> time as this one. Why are we saying "two is enough" but then doing 
>> more? Maybe the user name/password ones aren't classes, or whatever, 
>> but a slight rewording would go a long way here to help avoid the 
>> impression that the WG is at odds with itself.
>
> That raises the question of whether our layering of classes and 
> subclasses and profiles is really all that helpful. During the NEWPREP 
> BoF, we had fairly strong agreement that we wanted to define a very 
> limited number of classes (say, two or three) that could be re-used by 
> application protocols. At the least, I think we need to more clearly 
> describe the relationship between classes and profiles. I'll look at 
> the existing text and propose better text on the list.
OK, I've thought about this further.

Currently we distinguish between classes, subclasses, and usages 
(although we often use the word "profiles" instead of "usages" because 
that seems to feel more natural). I think we can remove a layer here by 
defining classes and profiles, thus deleting subclasses. Right now, the 
only difference between a subclass and a usage is that a subclass can 
restrict the range of allowable codepoints beyond the range for a given 
class, whereas a usage doesn't restrict the codepoints but does define 
the rules for width mapping, additional mappings, case mapping, 
normalization, and directionality. This might be a distinction without a 
difference.

So far we have defined the following usages (where * indicates that the 
usage restricts the range of codepoints):

usernames
passwords
nicknames
localparts *
resourceparts

I suggest that we can simplify matters by using the current naming 
scheme for subclasses and applying it to profile names:

UsernameIdentifierClass (i.e., the Username profile of the IdentifierClass)
PasswordFreeformClass
NicknameFreeformClass
LocalpartIdentifierClass
ResourcepartFreeformClass

This way, each profile has a name, which might make it easier for future 
protocols to re-use what we've defined so far.

Peter