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
