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

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

Martin, I agree with all of your points.

On 10/9/13 3:24 AM, "Martin J. Dürst" wrote:
> 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
>>