Re: [precis] WGLC: draft-ietf-precis-mappings-07.txt

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/18/2014 12:14 AM, Yoshiro YONEYA wrote:
> Dear all,
> 
> As discussed on the mailing list in recent months, the latest
> mappings document seemed to address issues raised in Vancouver, and
> seemed to have good relation with the latest framework well, so
> co-chairs decided to perform WG LC again to the document.
> 
> This message starts two weeks Working Group Last Call (WGLC) on 
> draft-ietf-precis-mappings-07.txt (Mapping characters for PRECIS
> classes). 
> <http://www.ietf.org/id/draft-ietf-precis-mappings-07.txt>
> 
> Please review the document and send comments to the list
> ([e-mail]), the co-chairs ([e-mail]), or
> the authors ([e-mail]) by the end
> of WGLC.

Overall it looks very good. Here are a few relatively small comments...

First, I think this document should be standards track. It defines
technical rules that could be subject to testing and further
improvement, and thus does not seem completely informational to me.

ABSTRACT

   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.

I think this would be a bit clearer:

   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
   alternative to Unicode Default Case Folding, which is the case
   mapping rule specified in the PRECIS framework.

The same text can be found in Section 1.

SECTION 2.3

I suggest...

OLD
   characters, targeting characters which mapping depends on locale or
   locale and context.
NEW
   characters, targeting characters for which case mapping depends on
   locale or on locale and context.

There is a small typo here: "if the case of Turkish" should be "in the
case of Turkish". (There are also a few instances of subject-verb
disagreement and such, but I assume those will be fixed during
processing by the RFC Editor team.)

This section says:

   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.

I have been thinking about this further. The PRECIS framework says
that Unicode Default Case Folding is RECOMMENDED. The framework also
says that a PRECIS profile needs to specify which case mapping rule to
apply. The choices are Unicode Default Case Folding, the "local case
mapping" rule from this document, or something else. The nature of
this "something else" is not mentioned. I think it might be simpler to
say "either use Unicode Default Case Folding as recommended by the
PRECIS framework, or use local case mapping as defined by the PRECIS
mapping document, but never both".

If we go in that direction, then I would suggest the following
modified text:

   This local case mapping provides an alternative to Unicode Default
   Case Folding, which is recommended by the PRECIS framework. Because
   these methods are strictly alternatives, if a PRECIS profile
   specifies the use of local case mapping then it MUST NOT also apply
   Unicode Default Case Folding.

APPENDIX A.1

I am not quite sure about the purpose of this table, but in any case I
suggest the following clarification.

OLD
   This table is the mapping type list for each protocol.
NEW
   This table is the mapping type list for each protocol mentioned in
   the PRECIS problem statement document [RFC6885].

Thanks!

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTA/z/AAoJEOoGpJErxa2p/BkP/2+RvFAl9zTWfsQRL89YqTee
jbiCTnOdBo+EF0xTkDM4XhXV+dYOgsWCsoJxdWo7a5fONJ0ARIbbRhy+WSVHLgdA
XJc9wBMpMZO6zyC99nSFQMAP8ABMlgP0yTolG5Qjj1FWnHjRrBBMNQT+RXxptcbw
I0+yarsRehbUW1/mvS1WobEhpEQ/wkYmSEf47aJGbyszLd8DQY3yjOCRw4o9VVRz
I9sC8DlVmEnJ8zhIWIKccpcHAPbOOq5ypHetFb6i1Ydj+q6ti+7Wu3RKj0SPjQbi
dCt7SpRKn20/FmgBMfTY4zdFrpKyPFKQoWpj6Ys/rEt2reX8G4bbZuaiecrOBlys
hQs7uh2c08CAKmkF4gDwCx7m5LDKZAzoOKRDYC2TjNIvDsdnF21zpvDSnN2LebuI
eR1l2rNnQe7oaw3lrI4+nja+IVCppBcmQcDUpuj3dTonMrOFWzYEk47FukPz1gcc
H7mikM35eqAFjeUeS87cqsixTGAmzJXEiwBhqUj7RM5nO/fKd56YfmkxAsOLmkho
2NOxgm1GJDmrSimuAJ5iKc7WCTxCeF2KBvEHt6mDgFQgidYHqI1qwpI9Ftzwhvw+
JRN67kKaso+kp900FIuW6FM2sYf55Uu6qB1WQ4dUpBX2wzbNy1iyMIy6o9t1WnRV
SwmezOR7CJ5VJUHWqyt2
=OLgj
-----END PGP SIGNATURE-----