Re: [precis] I-D ACTION:draft-nemoto-precis-framework-implement-report-00.txt

[Takahiro Nemoto <[e-mail]>]

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
[e-mail]