-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/18/12 4:24 AM, Takahiro Nemoto wrote: > Thank you so much for the reviews. > > On 2012/07/17, at 6:19, Peter Saint-Andre wrote: > >> On 7/5/12 10:14 PM, Takahiro Nemoto wrote: >>> Dear Peter-san and all, >>> >>> Thank you for introducing our I-D. Please read and give your >>> comments/suggestions. >> >> First, thank you for working on this document. >> >> I agree with you that "the file describing derived property >> value table for precis should be generated". It is also good to >> know that you have worked on an implementation that generates the >> tables. I am also working on an implementation (unfortunately I >> did not have time to finish it before IETF 84, but I plan to do >> that in August) and would like to "compare notes" with you. I >> recognize that the tables in draft-ietf-precis-framework are >> quite likely incorrect in some places since I created them by >> hand, so I will work to make more accurate tables next month. > > I'd like to compare notes with you too, and I'm happy if I can > co-work with you :-)
Yes, let's chat about that off-list. >> You mention the need to do string validity checking, for example >> to make sure that string length is non-zero. Do you think that is >> a PRECIS check or a check at the application layer? I've always >> thought this is something that the application would do, not >> PRECIS. > > I think that maybe some checks are included at PRECIS. I think if > PRECIS does not define any checks in the protocol and an > application developer forget to implement some checks in an > application, this application may cause vulnerabilities. So we can advise applications to prohibit zero-length strings in identifiers. :) It seems to me that PRECIS only tells you how to perform all the i18n handling, and doesn't define application-level restrictions such as string length. >> As to special mappings like "Map to SPACE" and "Map to Nothing", >> it seems to me that in a post-stringprep system we can handle >> those by more carefully defining the string classes. > > Sorry, but I don't get it. What does a post-stringprep system > mean? A system that uses PRECIS. Because PRECIS uses an inclusion model (only characters / code points / codepoint classes that are explicitly allowed can be included in a conformant string), I don't see any reason to have these "mapped to space" or "mapped to nothing" rules in PRECIS-based systems. For example, just allow space (U+0020) but not other space characters. >> You make a good point about the order of processing >> (normalization then validity in IDNA2008 vs. validity then >> normalization in SASLprep-bis). It does seem preferable to have a >> consistent order. Let's make sure we have discussion about this >> at the meeting two weeks from now. > > Yes, we do. I think that It is preferable to have a consistent > order. Different results from the order of processing can now only > be found in Hangul. If you know any examples, please let us know. OK, I will add this to our list of open issues for the framework document and include it in our discussion at IETF 84. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAG0lwACgkQNL8k5A2w/vzwfwCg9aWpBih+2bsET7xONSoNYFCw Mw8An2ht+RMrta9UG+MQVUlWLzWsAttT =fbkF -----END PGP SIGNATURE----- _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
