Subject: [precis] AD review of draft-ietf-precis-saslprepbis

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Apr 2015 22:13:27 -0400

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 14 Apr 2015 11:58:23 -0600

> have this one in the queue).

Agreed.

> IdentifierClass.  And that's supported in example 8 in Table 2

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.

> 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).

> something like "maps to <foo bar> (using ASCII space)".

Good catch. Yes, that would be better.

>     this document obsoletes RFC 4013.

+1.

Nit: I'd change "new" to "updated" because eventually this document 
won't be so new anymore. :-)

> and its RFC number in the abstract, without any indication that it's

Yep, that's all good.

> we should be citing RFC 2617 any more, and I think we should pull out

+1

>     perhaps separated by spaces, punctuation, or other non-alphanumeric

Works for me.

> These two profiles differ only in the Case Mapping Rule, and are

That seems good to me.

> 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/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Apr 2015 14:43:46 -0400

Another set of perfect responses, and I see the revised I-D.  Off to
request last call now.

Barry