Thank you for your comments. Our comments inline. On 2013/04/26, at 11:00, Peter Saint-Andre <[email protected]> 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 protected] >> <mailto:[email protected]>> 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 > > _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
