On 4/7/14, 11:40 AM, Pete Resnick wrote:
At long last, I finally completed my review of the framework document.
My personal feeling here is that I should go ahead and do the IETF Last
Call and consider the below equivalent to Last Call comments, and we can
discuss them here during Last Call. If anyone has any concerns about
that and thinks we really need to discuss something before I issue the
Last Call, please say so now (i.e., in the next 24 hours). Otherwise,
the Last Call will go out tomorrow.
Great, thanks Pete!
-----
Substantive issue:
-----
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: RFC 5893 exists because IDNs want to use "." as a
label separator yet have text display work in a context that is unaware
of labels. Neither using 5893 nor considering any RTL character making
the whole string RTL is a good recommendation for most cases. Not sure
what to do about this.
See:
http://www.ietf.org/mail-archive/web/precis/current/msg00553.html
and
http://www.ietf.org/mail-archive/web/precis/current/msg00557.html
I am not sure how helpful it is to distinguish between processing
challenges and presentation challenges.
I will ponder this further and reply again.
-----
Editorial issues:
-----
Throughout: Change "Informational Note:" to "Note:". I don't see any of
them for which it makes a difference.
Sure.
3.1:
I would move the first paragraph down further in the section.
Seems we could delete it altogether.
I would delete the parenthetical at the end of "Contextual Rule
Required"; no need to introduce undefined terms here.
Sure.
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.
Works for me.
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".
That's better, yes.
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
Noted.
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.
Will do.
That's it.
Excellent, thanks.
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
