Le 2014-04-07 à 13:40, Pete Resnick <[email protected]> a écrit :
> 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. my take from your comments below is that we can manage them during the IETF last call, so I suggest we proceed with IETF Last call. Regards, Marc. > > ----- > 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. > > ----- > Editorial issues: > ----- > > 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. > > 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.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. > ----- > > That's it. > > pr > > -- > Pete Resnick<http://www.qualcomm.com/~presnick/> > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
