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? >> 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. >> 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. :-) Peter _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
