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