On 4/13/15 8:13 PM, Barry Leiba wrote:
As with the other document, the items marked "DISCUSS" below are
things I think we need to resolve before I request last call. It'd be
nice to sort out the others before then too, but I won't hold things
up for them.
--------
DISCUSS
-- Section 2 --
Many important terms used in this document are defined in
[I-D.ietf-precis-framework], [RFC5890], [RFC6365], and [Unicode].
I think this makes 5890 and 6365 normative references (you already
have this one in the queue).
Agreed.
-- Section 3.5 --
This says that identifiers can look like "Firstname Middlename
Lastname", "because the PRECIS IdentifierClass allows any ASCII7
character, because spaces can be used to separate userpart instances".
But when I look at the definition of IdentifierClass in
precis-framework, my reading says that spaces are not valid in the
IdentifierClass. And that's supported in example 8 in Table 2
(Section 3.6).
Correct. U+0020 is not allowed in IdentifierClass, but you can create
"foo bar" as an application-layer construct if both "foo" and "bar" are
separate instances of the IdentifierClass (or a profile thereof). Such a
construct is not a PRECIS profile because you treat each instance
separately and then place a space between the two instances.
Is my understanding of either Section 3.5 or the valid characters in
IdentifierClass incorrect?
Section 3.5 is, perhaps, not as clear as it could be.
I suggest:
OLD
Both the UsernameCaseMapped and UsernameCasePreserved profiles allow
an application protocol, implementation, or deployment to create
application-layer constructs such as "user@domain" or "Firstname
Middlename Lastname". One example of the former is the Network
Access Identifier specified in [I-D.ietf-radext-nai]. (Such
constructs are possible because the PRECIS IdentifierClass allows any
ASCII7 character, because spaces can be used to separate userpart
instances, and because domain names as specified in [RFC5890] and
[RFC5892] are a subset of the PRECIS IdentifierClass.)
NEW
Both the UsernameCaseMapped and UsernameCasePreserved profiles enable
an application protocol, implementation, or deployment to create
application-layer constructs such as a space-separated set of names
like "Firstname Middlename Lastname". Although such a construct is
not a PRECIS profile (since U+0020 SPACE is not allowed in the
IdentifierClass), it can be created at the application layer because
U+0020 SPACE can be used as a separator between instances of the
PRECIS IdentifierClass (or a profile thereof).
-- Section 4.3 --
Example 16 in Table 4 seems wrong: non-ASCII spaces are allowed in
FreeformClass, and enforcement rule 2 maps them all to ASCII space.
It would seem that example 16 should be in Table 3, with a note
something like "maps to <foo bar> (using ASCII space)".
Good catch. Yes, that would be better.
--------
COMMENT
In the Abstract it's unfortunate that you mention 3454 without being
able to say that it's been obsoleted by the precis framework doc.
Because precis framework is a normative reference from here, maybe
it's best to put in a placeholder for that, to be resolved at AUTH48.
I'm also concerned that non-native readers might be uncertain that
you're saying that SASLprep and Stringprep are "the previous approach"
(rather than the "more sustainable approach"), and some re-wording
could make that clearer. Maybe like this?:
OLD
This document describes methods for handling Unicode strings
representing usernames and passwords. The methods specified in this
document provide a more sustainable approach to the handling of
internationalized usernames and passwords than the previous approach,
known as SASLprep (RFC 4013) and based on Stringprep (RFC 3454).
This document obsoletes RFC 4013.
NEW
This document describes new methods for handling Unicode strings
representing usernames and passwords. The previous approach was
known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).
The methods specified in this document provide a more sustainable
approach to the handling of internationalized usernames and
passwords. The precis framework, RFC XXXX, obsoletes RFC 3454, and
this document obsoletes RFC 4013.
END
+1.
Nit: I'd change "new" to "updated" because eventually this document
won't be so new anymore. :-)
...and then add an RFC Editor note to the beginning of the
Introduction that asks them to replace "RFC XXXX" in the abstract with
the RFC number of the precis framework document.
I wouldn't normally say we need to repeat what precis framework
already says, but you otherwise have a direct mention of Stringprep
and its RFC number in the abstract, without any indication that it's
now obsolete.
Yep, that's all good.
In the Introduction (and elsewhere), httpauth-basicauth-update is in
the RFC Editor queue and is only waiting on this document.
httpauth-digest is also almost in the RFC Editor queue, and all these
documents will be published together. Because of that, I don't think
we should be citing RFC 2617 any more, and I think we should pull out
that reference.
+1
-- Section 2 --
As used here, the term "password" is not literally limited to a word;
i.e., a password could be a passphrase consisting of more than one
word, perhaps separated by spaces or other such characters.
What "such" characters? Maybe this works?:
NEW
As used here, the term "password" is not literally limited to a word.
A password could be a passphrase consisting of more than one word,
perhaps separated by spaces, punctuation, or other non-alphanumeric
characters.
END
Works for me.
-- Section 3.4 --
In order to accomodate the widest range of username constructs in
applications, this document defines two username profiles:
UsernameCaseMapped and UsernameCasePreserved.
It's a tiny point, and I'm OK if the WG doesn't want to do this, but I
think it would be useful to add the following to this paragraph, to
eliminate any question:
NEW (append)
These two profiles differ only in the Case Mapping Rule, and are
otherwise identical.
END
That seems good to me.
-- Section 3.6 --
Nit: I believe that "eszett" (one "s") is the more customary spelling.
Right you are!
Thanks for the thorough review.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
