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

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Apr 2015 17:46:33 -0400

I'm getting to the documents I picked up from Pete when he left the
IESG.  While I await the shepherd writeup for
draft-ietf-precis-nickname, here's my AD review of it.  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 1.2 --

   Many important terms used in this document are defined in
   [I-D.ietf-precis-framework], [RFC6365], and [Unicode].

I think that makes 6365 a normative reference.

-- Section 3 --

   The following examples illustrate strings that are not valid
   nicknames because they violate the format defined above.

For this and examples 9 and 10, I'm confused.  The text above does not
tell me that "foo    bar" is not a valid nickname -- only that the
process of preparing it for comparison normalizes it to "foo bar" (and
similarly for " foo ").  Where is it that you say that the application
of rule 2 is different from the application of other rules?

--------
COMMENT

-- Section 2.2 --

   An entity that performs enforcement according to this profile MUST
   prepare a string as described in the previous section and MUST also
   apply the rules specified below for the Nickname profile (these rules
   MUST be applied in the order shown).

Is the first part of that sentence necessary?  Section 2.1 already has
MUSTs; why do we have to repeat that you MUST apply Section 2.1?  I'd
just say:

NEW
   An entity that performs enforcement according to this profile MUST
   apply the rules specified below for the Nickname profile, in the
   order shown below.
END

       2.  Leading and trailing whitespace (i.e., one or more instances
           of the ASCII space character at the beginning or end of a
           nickname) MUST be removed (e.g., "stpeter " is mapped to
           "stpeter").

Most of our protocols consider HTAB to be "whitespace", but it isn't
here (CHARACTER TABULATION isn't in the Zs category).  Is that OK?  Is
it worth specifically mentioning that, considering how common it is?

-- Section 5 --
Why does the text for "case mapping rule" say "for comparison
purposes", while none of the others do?  Nothing in the document text
makes the case mapping rule special.

--
Barry, Applications AD

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 13 Apr 2015 18:13:29 -0600

Hi Barry, thanks for the review.

> I think that makes 6365 a normative reference.

Indeed. We'll want to fix that in draft-ietf-precis-saslprepbis, too.

> of rule 2 is different from the application of other rules?

Right. I suggest that remove the second table, then.

>     apply the rules specified below for the Nickname profile, in the

According to draft-ietf-precis-framework, preparation and enforcement 
are two separate acts. In addition, the preparation rules (§2.1) need to 
be applied first in order for the enforcement rules (§2.2) to be done 
correctly. So I would say that the first part of the sentence is indeed 
necessary.

> here (CHARACTER TABULATION isn't in the Zs category).  Is that OK?

Because U+0009 (CHARACTER TABULATION) is a control character, it is 
disallowed by the PRECIS framework. Therefore I think it is OK to not 
consider it here.

> Is

We could do this to remove the confusion:

OLD

NEW
        2.  Any instances of the ASCII space character at the beginning
            or end of a nickname MUST be removed (e.g., "stpeter " is
            mapped to "stpeter").

> makes the case mapping rule special.

I think that's an artifact of an earlier version and can safely be removed.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Barry Leiba <[email-masked]>
Date: Mon, 13 Apr 2015 20:51:59 -0400

> Hi Barry, thanks for the review.

You're welcome.  And all your answers are perfect.  Please post a
revised I-D, and I'll start last call as soon as I get a shepherd
writeup.

I'm reviewing saslprepbis now, so please hold off on revising that
until I'm done (probably tomorrow).

Barry