Hi, Peter-san, I'm so sorry for my late reply. And thank you for your review. Yoneya-san and I discussed your comments. Our comments inline.
On 2013/04/13, at 6:18, Peter Saint-Andre <[email protected]> wrote: > As promised at IETF 86 (and probably IETF 85!), I've reviewed the > issues raised by draft-ietf-precis-mappings. I will also send some > editorial feedback directly to the authors of that document. > > 1. Width mapping has now been moved to the framework document, so I > think Section 2 and Section 3 of the mappings document can be removed. We agree. > > 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. > > 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. > > 4. I think we can just mention RFCs 3748, 4013, 4314, and 4518 in > Section 4.2 and then remove Appendix B, since it is the responsibility > of other specifications to actually define the special mappings (e.g., > this is done in draft-ietf-precis-saslprepbis). We agree. > > 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. > > 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. > > 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 :-) Best regards, Nemo -- Takahiro Nemoto [email protected] > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
