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