Subject: [precis] shepherd review of draft-ietf-precis-mappings

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 11 Jun 2015 17:04:43 -0600

With my document shepherd hat on, I just reviewed 
draft-ietf-precis-mappings. I have sent some editorial comments to the 
authors. I also found two more substantive issues...

1. The "local case mapping" method specified in Section 2.3 talks about 
locale and context. However, the example in the second paragraph is a 
matter of language, not locale:

    As an example of locale and context-dependent mapping, LATIN CAPITAL
    LETTER I ("I", U+0049) is normally mapped to LATIN SMALL LETTER I
    ("i", U+0069); however, if the case of Turkish (or one of several
    other languages), unless an I is before a dot_above, the character
    should be mapped to LATIN SMALL LETTER DOTLESS I (U+0131).

As I understand it, locale (see Section 8 of RFC 6365) would refer to a 
particular region within a language-speaking community, such as 
Switzerland within the German-speaking areas.

The SpecialCasing.txt file in the Unicode standard talks about 
language-sensitive mappings for the Lithuanian, Turkish, and Azeri 
languages. (It also talks about a language-insensitive mapping, i.e., 
context-dependent mapping, for Greek final sigma.) It does not talk 
about locale-dependent mappings for particular regions within any 
language-speaking communities.

Therefore, I wonder if all mentions of locale in 
draft-ietf-precis-mappings really ought to be mentions of language. On 
reading the text in the document right now, I provisionally concluded 
that this switch would make sense, but I haven't thought carefully about 
every instance. And I would be curious to hear from the authors and 
working group about this issue.

2. Appendix B purports to describe why local case mapping needs to be an 
alternative to Unicode Default Case Mapping instead of being applied 
sequentially (the text mentions the possibility of applying local case 
mapping before Unicode Default Case Mapping - is that the only option, 
or should we say something about applying it after?).

However, Appendix B only mentions eszett (U+00DF) and to my mind does 
not provide a complete argument for why local case mapping needs to be 
an alternative to Unicode Default Case Mapping. At the least, it might 
be valuable to mention the handling of characters other than eszett. I 
suppose the basic argument is already in Section 2.3, but if so then I 
think that Appendix B might have a misleading title.

Other than these two issues, I think the document is in good shape 
(modulo some editorial adjustments).

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 12 Jun 2015 11:25:13 +0200

There might be geographical issues as well, and not only language. Or rather, if the language also have a geographic tag (that I do not remember what its name is) then it might be complete.

Example, in French, one do not have accents on the capital letters (well, one have if it is needed due to distinguish between words, if it is a name etc -- so it is optional), but do in Canada. Of course, one can say maybe that French in France is one language and French in Québéc is another, but...

You get the point.

So, I agree with you that one should probably treat the word "language" as only one example of a parameter in the "locale" definition that changes the behaviour of the function.

   Patrik

On 12 Jun 2015, at 1:04, Peter Saint-Andre - &yet wrote:

> With my document shepherd hat on, I just reviewed draft-ietf-precis-mappings. I have sent some editorial comments to the authors. I also found two more substantive issues...
>
> 1. The "local case mapping" method specified in Section 2.3 talks about locale and context. However, the example in the second paragraph is a matter of language, not locale:
>
> As I understand it, locale (see Section 8 of RFC 6365) would refer to a particular region within a language-speaking community, such as Switzerland within the German-speaking areas.
>
> The SpecialCasing.txt file in the Unicode standard talks about language-sensitive mappings for the Lithuanian, Turkish, and Azeri languages. (It also talks about a language-insensitive mapping, i.e., context-dependent mapping, for Greek final sigma.) It does not talk about locale-dependent mappings for particular regions within any language-speaking communities.
>
> Therefore, I wonder if all mentions of locale in draft-ietf-precis-mappings really ought to be mentions of language. On reading the text in the document right now, I provisionally concluded that this switch would make sense, but I haven't thought carefully about every instance. And I would be curious to hear from the authors and working group about this issue.
>
> 2. Appendix B purports to describe why local case mapping needs to be an alternative to Unicode Default Case Mapping instead of being applied sequentially (the text mentions the possibility of applying local case mapping before Unicode Default Case Mapping - is that the only option, or should we say something about applying it after?).
>
> However, Appendix B only mentions eszett (U+00DF) and to my mind does not provide a complete argument for why local case mapping needs to be an alternative to Unicode Default Case Mapping. At the least, it might be valuable to mention the handling of characters other than eszett. I suppose the basic argument is already in Section 2.3, but if so then I think that Appendix B might have a misleading title.
>
> Other than these two issues, I think the document is in good shape (modulo some editorial adjustments).
>
> Peter
>
> -- 
> Peter Saint-Andre
> https://andyet.com/
>
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 12 Jun 2015 10:49:45 -0600

Hi Patrik,

On 6/12/15 3:25 AM, Patrik Fältström wrote:
> There might be geographical issues as well, and not only language. Or
> rather, if the language also have a geographic tag (that I do not
> remember what its name is) then it might be complete.
>
> Example, in French, one do not have accents on the capital letters
> (well, one have if it is needed due to distinguish between words, if
> it is a name etc -- so it is optional), but do in Canada. Of course,
> one can say maybe that French in France is one language and French in
> Québéc is another, but...
>
> You get the point.

Yes, I see your point, and fr-fr vs. fr-ca is a good example that Marc 
could tell us all about. :-)

> So, I agree with you that one should probably treat the word
> "language" as only one example of a parameter in the "locale"
> definition that changes the behaviour of the function.

Agreed. However, it's important to note that right now the alternative 
case mapping method defined in this document doesn't cover modifications 
based on geographic location or political jurisdiction, only language 
(see my previous note) and in one case context (Greek final sigma).

By the way, the more I think about it, the less I like the term "local 
case mapping" because "local" sounds like "locale" and also could be 
confused with localization. I suggest that we might want to change it to 
"alternative case mapping" (as opposed to "default case mapping" as in 
Unicode Default Case Folding).

Peter

>> draft-ietf-precis-mappings. I have sent some editorial comments to
>> the authors. I also found two more substantive issues...
>>
>> 1. The "local case mapping" method specified in Section 2.3 talks
>> about locale and context. However, the example in the second
>> paragraph is a matter of language, not locale:
>>
>> As an example of locale and context-dependent mapping, LATIN
>> CAPITAL LETTER I ("I", U+0049) is normally mapped to LATIN SMALL
>> LETTER I ("i", U+0069); however, if the case of Turkish (or one of
>> several other languages), unless an I is before a dot_above, the
>> character should be mapped to LATIN SMALL LETTER DOTLESS I
>> (U+0131).
>>
>> As I understand it, locale (see Section 8 of RFC 6365) would refer
>> to a particular region within a language-speaking community, such
>> as Switzerland within the German-speaking areas.
>>
>> languages. (It also talks about a language-insensitive mapping,
>> i.e., context-dependent mapping, for Greek final sigma.) It does
>> not talk about locale-dependent mappings for particular regions
>> within any language-speaking communities.
>>
>> draft-ietf-precis-mappings really ought to be mentions of language.
>> On reading the text in the document right now, I provisionally
>> concluded that this switch would make sense, but I haven't thought
>> carefully about every instance. And I would be curious to hear from
>> the authors and working group about this issue.
>>
>> 2. Appendix B purports to describe why local case mapping needs to
>> be an alternative to Unicode Default Case Mapping instead of being
>> applied sequentially (the text mentions the possibility of applying
>> local case mapping before Unicode Default Case Mapping - is that
>> the only option, or should we say something about applying it
>> after?).
>>
>> However, Appendix B only mentions eszett (U+00DF) and to my mind
>> does not provide a complete argument for why local case mapping
>> needs to be an alternative to Unicode Default Case Mapping. At the
>> least, it might be valuable to mention the handling of characters
>> other than eszett. I suppose the basic argument is already in
>> Section 2.3, but if so then I think that Appendix B might have a
>> misleading title.
>>
>> -- Peter Saint-Andre https://andyet.com/
>>
>> _______________________________________________ precis mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/precis

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 12 Jun 2015 18:57:27 +0200

On 12 Jun 2015, at 18:49, Peter Saint-Andre - &yet wrote:

> I suggest that we might want to change it to "alternative case mapping" (as opposed to "default case mapping" as in Unicode Default Case Folding).

Sounds like a good plan to me.

   Patrik