Hi Barry-san,
Thank you for your review and helpful comments.
My comments are inline.On 2013/11/12, at 13:37, Barry Leiba <[email protected]> wrote: > I promised to do a review of draft-ietf-precis-mappings this week; > here it is. I have never looked at this document before, so these are > new eyes on it. > > -- Section 2.1 -- > > The second paragraph is pretty hard to understand. I couldn't > understand the beginning at all until I got to the end, and then I had > to read it again to pick up what I'd missed. I think I have it now, > and I think I can offer a re-wording that'll help: > > OLD > Delimiter mapping is supposed to map delimiter characters that have > compatible characters to canonical characters. For example, '@' in > mail address or ':' and '/' in URI has width compatible character. > And '+', '-', '<' and '>' may be such character. Another example is > the FULL STOP character (U+002E) which is a delimiter in the visual > presentation of domain names. Some IMEs generate semantic or width > compatible character of FULL STOP such as IDEOGRAPHIC FULL STOP > (U+3002) when a user types FULL STOP on the keyboard. Such FULL STOP > compatible characters need to be mapped to the FULL STOP before > passing the string to the protocol. > NEW > Delimiter mapping is used to map characters that are similar to > protocol delimiters into the canonical delimiter characters. For > example, there are width-compatible characters that correspond to the > '@' in email addresses and the ':' and '/' in URIs. The '+', '-', > '<' and '>' characters are other common delimiters that might require > such mapping. For the FULL STOP character (U+002E), a delimiter in > the visual presentation of domain names, some IMEs produce a character > such as IDEOGRAPHIC FULL STOP (U+3002) when a user types FULL STOP on > the keyboard. In all these cases, the visually similar characters > that can come from user input need to be mapped to the correct protocol > delimiter characters before the string is passed to the protocol. > END I'll try to revise the mappings document according to your suggestion. > > -- Section 4 -- > > This section doesn't make much sense to me. I think I know what it's > trying to say, but it needs to explain it better: WHY might these > mappings confuse some users, and why might that create a security > consideration? I wrote it in the same way as RFC5895, but the concrete details are not clearly mentioned. So, I want to revise it as the mappings that are targeted towards people who have no/little familiarity with local case mappings that depend on locale and context. > > -- Appendix A -- > > I found the table hard to follow, as well. I think it would be helped > by including the protocol name in the first column; something like > this: > > OLD > +----------------------+ > | \ Type of mapping | > | RFC \ | > +----------------------+ > | 3490 | > | 3491 | > | 3722 | > | 3748 | > | 4013 | > | 4314 | > | 4518 | > | 6120 | > +----------------------+ > NEW > +----------------------+ > | Protocol and | > | mapping RFC | > +----------------------+ > | IDNA (RFC 3490) | > | IDNA (RFC 3491) | > | iSCSI (RFC 3722) | > | EAP (RFC 3748) | > | SASL (RFC 4013) | > | IMAP (RFC 4314) | > | LDAP (RFC 4518) | > | XMPP (RFC 6120) | > +----------------------+ > END > > Because the text makes it clear that the table is about mapping types, > I don't think you need the "Type of mapping" row heading. I do think > the text should be clearer about "each protocol". Maybe say, "each > protocol for which mapping is defined." Thank you for your advice. I'll try to modify the table. > > -- Appendix B -- > > Where did this list come from? Did the working group figure it out? > Or was it derived from or retrieved from some other source? It was taken from the comparison between SpecialCasing.txt and CaseFolding.txt, based on the calculation condition of strings that are targets of local-case mapping. > > Barry > _______________________________________________ > precis mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/precis
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
