Subject: [precis] Review of draft-ietf-precis-mappings

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Nov 2013 23:37:12 -0500

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

---

From: Takahiro Nemoto <[email-masked]>
Date: Mon, 25 Nov 2013 15:25:39 +0900

Hi Barry-san,
         
Thank you for your review and helpful comments.
My comments are inline.

>   delimiter characters before the string is passed to the protocol.
I'll try to revise the mappings document according to your suggestion.

> mappings confuse some users, and why might that create a security
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.

> by including the protocol name in the first column; something like
Thank you for your advice. I'll try to modify the table.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/precis