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). -- 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). Is my understanding of either Section 3.5 or the valid characters in IdentifierClass incorrect? -- 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)". -------- 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 ...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. 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. -- 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 -- 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 -- Section 3.6 -- Nit: I believe that "eszett" (one "s") is the more customary spelling. -- Barry, Applications AD _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
