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

[Peter Saint-Andre <[e-mail]>]

-----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-----