On 3/23/14, 7:31 PM, Takahiro Nemoto wrote:
Dear all,
I am trying to reflect comments from the discussion in a last WG in London.
I would like you to review the following modifications and give your
comments/suggestions.
Abstract & 1. Introduction
OLD
This document
provides guidelines for authors of protocol profiles of the PRECIS
framework and describes several mappings that can be applied between
receiving user input and passing permitted code points to
internationalized protocols. The mappings described here are
expected to be applied as an additional mapping and alternative to
Unicode Default Case Folding as case mapping in the PRECIS framework.
NEW
This document
provides guidelines for authors of protocol profiles of the PRECIS
framework and describes several mappings that can be applied between
receiving user input and passing permitted code points to
internationalized protocols. The delimiter mapping and special mapping
rules described here are applied as "additional mappings" beyond those
defined in the PRECIS framework, whereas the "local case mapping" rule
is applied as an option of methods that handles some locale-dependent
and context-dependent mappings, which is the case mapping rule
specified in the PRECIS framework.
I think this is a bit clearer:
whereas the "local case mapping" rule
provides an alternative to the case mapping rule
specified in the PRECIS framework since it
handles some locale-dependent and context-dependent
mappings.
One thing that I *thought* I heard in London is "the case mapping text
in the framework document handles internationalization and the case
mapping text in the mappings document handles localization". I tried to
capture that in the framework with this text:
Informational Note: Unicode Default Case Folding is not designed
to handle various localization issues (such as so-called "dotless
i" in several Turkic languages). The PRECIS mappings document
[I-D.ietf-precis-mappings] describes these issues in greater
detail and defines a "local case mapping" method that handles some
locale-dependent and context-dependent mappings.
Two questions:
1. Is that accurate?
2. Do we want to capture this in the mappings document as well?
2.3. Local case mapping
OLD
If a codepoint is a target, the case folding method for the codepoint
is mapping into lower case as defined in SpecialCasing.txt. On the
other hand, if a codepoint is not a target, the case folding method
for the codepoint is the same with case mapping in PRECIS framework.
This local case mapping provides alternative case folding method to
Unicode Default Case Folding as case mapping in the PRECIS framework,
therefore if a PRECIS profile chooses local case mapping, it should
not choose case mapping. The reason for this is written in the
Appendix B.
NEW
The case folding method for a target character is to map into lower case
as defined in SpecialCasing.txt. The case folding method for all other,
non-target characters is as specified in Section 4.1.3 of the PRECIS
framework (i.e., Unicode Default Case Folding SHOULD be used for all
non-target characters). If an application supports users' locale and/or
context and gets them information from user input, local case mapping
can increase the probability of getting matching-results from the comparison
between strings.
I would strike "and gets them information from user input" because I
don't think that text adds anything to the sentence.
3. Order of operations
OLD
The mappings described in this document are expected to be applied as
additional mappings and alternative to Unicode Default Case Folding
as case mapping in the PRECIS framework. The mappings described in
this document could be applied in any order. This section specifies
a particular order to minimize the effect of codepoint changes
introduced by the mappings. This mapping order is very general and
has been designed to be acceptable to the widest user community.
NEW
The mappings described in this document are expected to be applied as
additional mappings in the PRECIS framework. The mappings described in
this document could be applied in any order. This section specifies
a particular order to minimize the effect of codepoint changes
introduced by the mappings. This mapping order is very general and
has been designed to be acceptable to the widest user community.
That looks fine to me.
Thanks for working on this.
Peter
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
