Subject: [precis] Pete Resnick's Yes on draft-ietf-precis-framework-15: (with COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Fri, 18 Apr 2014 16:08:18 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-precis-framework-15: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The following are all items I mentioned in my AD Eval, but we decided
none was a show-stopper and all could be held until the end of Last Call.
The only substantive point is on 4.1.5, and the world will not end if I
end up in the rough on this point. (We don't expect a whole lot of
feedback during Last Call; the document got a good deal of review by a
lot of experts, but the topic is pretty esoteric for anyone else to have
much of a strong opinion.)

Throughout: Change "Informational Note:" to "Note:". I don't see any of
them for which it makes a difference.

3.1: I would move the first paragraph down further in the section. And I
would delete the parenthetical at the end of "Contextual Rule Required";
no need to introduce undefined terms here.

3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't
say that a string with a Disallowed character "SHALL be rejected". If it
were me, I'd simply say:

   Any code points that are not yet designated in the Unicode character
   set are considered Unassigned for purposes of the XXXClass, and such
   code points are to be treated as Disallowed.

4.1:

Change "MUST register" to "are registered". MUSTs for registration seem
silly. (If you want to say, "Implementations MUST NOT use unregistered
classes", you could, but I don't think you want to do that.)

Change "It is RECOMMENDED for profile names to be of the form" to "The
naming convention for profile names is to use the form".

4.1.5: I'm not thrilled with this section in general, but in particular
I'm not sure what "mixed-direction strings are not supported" means. We
do know how to process strings that contain characters with a mix of
directionality. Such strings are sometimes a visual challenge, but not a
processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to
be visually stable in either an LTR or RTL context, and because IDNs use
"." as a label separator yet want to have text display consistent in a
context that is unaware of labels. There are perfectly reasonable cases
where none of these hold true, so I think this section could be softened
so that it's not overtly pushing that protocols never allow mixed
direction text or that they should always lean toward using RFC 5893. 

4.2: A bit of ABNF neatening:

OLD
      fullname = namepart [1*(1*SP namepart)]
      namepart = 1*(idpoint)
NEW
      fullname = namepart *(1*SP namepart)
      namepart = 1*idpoint

9.2: It might be nice to add section numbers (3.2 and 3.3) to the
registrations for IdentifierClass and FreeformClass.

9.3: It might be nice to note the naming convention from 4.1 in the
template.