Thank you for your comments. On 2012/07/19, at 0:12, Peter Saint-Andre wrote:
> 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. "mapped to nothing" may generate zero-length strings and it may cause vulnerabilities for applications. Therefore, I think I just want to give application developers a heads-up about this in the protocol or the security sonsiderations. But, I don't necessarily want to define application-level restrictions in the protocol. So I would like to hear more member's comments about this. > > >> 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 > > nemo -- Takahiro Nemoto [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
