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