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

["Martin J. Dürst" <[e-mail]>]

On 2013/10/09 10:59, Peter Saint-Andre wrote:
> 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.

Me to. I haven't thought about how to organize the hierarchy much, but I 
have realized that at least it should be better documented.

That starts with the Abstract! It says:
                                                                  A
    specification that reuses this framework can either directly use the
    PRECIS string classes or subclass the PRECIS string classes as
    needed.

"the PRECIS string classes" implies that these have been mentioned 
before, but that didn't happen. I suggest something like:

This document defines several PRECIS string classes. Other 
specifications can either directly use such string classes or can 
subclass a string class defined here.

(please note the change from "reuse" to "use", this document doesn't use 
the classes, so there's no need for "re").

The abstract could then also talk about profiles (or whatever we end up 
if the changes below are adopted).

While we are at it, please shorten the abstract (one way to do this is 
to move historical/motivational stuff to the Intro or some other place 
like an appendix because it won't be very relevant anymore in a few 
years' time), or at least split it up into more than one paragraph.

Also, please explain the hierarchy (class-subclass-profile or whatever) 
in a bit more detail in the introduction, with pointers to examples that 
the WG is publishing in parallel.

Regards,   Martin.


> 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
>
>
>
>