Subject: Re: [precis] mappings

From: Takahiro Nemoto <[email-masked]>
Date: Thu, 2 May 2013 00:44:57 +0900

Thank you for your comments. Our comments inline.

On 2013/04/26, at 11:00, Peter Saint-Andre <[email-masked]> wrote:

> Thanks for your reply. I provide a few more comments inline (removing
> areas where we have agreement).
> 
> On 4/25/13 7:50 PM, Takahiro Nemoto wrote:
>> 
>> On 2013/04/13, at 6:18, Peter Saint-Andre <[email-masked]
>> <mailto:[email-masked]>> wrote:
> 
>>> 2. I think it would be helpful to mention some examples of delimiters
>>> other than FULL STOP.
>> We are supposing delimiter mapping for width compatible characters 
>> that like '@' in mail address and ':' or '/' in URI. Even though it may
>> be non-existent as for now, 
>> but I'm thinking that in the future there may be protocols that use '+',
>> '-', '<' or '>' as delimiters.
> 
> OK. Do you think it would be helpful to mention examples other than FULL
> STOP?
Yes. We'll mention that.

> 
>>> 3. This text is a bit confusing:
>>> 
>>>  One of the most useful case of delimiter mapping is when FULL STOP
>>>  character (U+002E) is a delimiter as well as domain name.
>>> 
>>> I am not a DNS expert, but my understanding is that FULL STOP is not
>>> part of the domain name but is a delimiter between the labels of a
>>> domain name. I think the sentence quoted above means that in certain
>>> protocols FULL STOP is used as a delimiter within protocol strings (such
>>> as identifiers) in addition to being used as a delimiter between domain
>>> name labels.
>> That's right. There is no FULL STOP in DNS packet.
>> But when comparing domain name strings outside of DNS protocol, 
>> FULL STOPs are used as delimiters and width problem should be considered.
>> 
>> For example, in web browser, FULL STOPs are considered when 
>> inputting words in comparing them with the page history list.
> 
> Agreed. I think it would be good to mention that example in the text.
OK. We will explain it in the text.

> 
>>> 5. I think Appendix C could be moved into Section 4.3.
>> Because we thought that it's not proper to move a table 
>> that has a unicode version dependency in the section, 
>> we place in the Appendix.
> 
> That seems reasonable.
> 
>>> 6. The big open issue here is the order of mappings. RFC 5895 defines an
>>> order of case mapping, width mapping, NFC, and the IDNA protocol. I'm
>>> not sure why we would do width mapping before case mapping in PRECIS,
>>> because we want to do local case mapping before non-locale-specific case
>>> mapping. Therefore I suggest the following order:
>>> 
>>>  1. Width mapping
>>>  2. Additional mappings (draft-ietf-precis-mappings)
>>>     a. delimiter mapping
>>>     b. special mapping
>>>     c. local case mapping
>>>  3. Case mapping (i.e., non-local-specific)
>>>  4. Normalization
>>>  5. PRECIS protocol
>>> 
>>> Does anyone see a reason to move width mapping after case mapping (as in
>>> RFC 5895)?
>> We agree about this order.
> 
> Great! I'll update the framework specification accordingly.
> 
>>> For the record, I think we need to specify the order of operations in
>>> both draft-ietf-precis-mappings and draft-ietf-precis-framework so that
>>> there is no ambiguity. Once we have consensus, I will be happy to update
>>> the framework accordingly.
>> We will, too :-)
> 
> Excellent. That will enable us to close one of the only open issues with
> the framework. :-)
That's good!! We think we can close open issues that we discussed 
at the last meeting in mapping document, too.

Best Regards,
Nemo

> Peter