On 2/3/15 10:04 PM, Bjoern Hoehrmann wrote:
I think the text to be added is very clear that implementations should
disallow all characters whose implications are not actually understood.
So, if you read the text below again, you'll see that it says that the
*rest of the document* says that implementers need to be careful in
certain ways. It is referring to advice in 4.1 and 12.3 regarding
free-form class, to give two particular examples, as well as by
reference the discussion in the IDNA document. Perhaps you are saying
that the text I proposed does not properly capture what's in the
document; that's a fine thing to discuss. Let's just not get off on the
tangent of confusables.
Note that I have reviewed the
document before and did not come across the advice the proposed text
claims to be there, and I've checked section 12.5 right now and do not
see it there either.
I mentioned 12.5 in reference to your discussion of confusables, which
is not part of what this text is meant to point to.
Regardless, as an example, if, instead of saying
Even so, implementations that are sensitive to the advice given in
this specification (to be careful to only allow characters whose
implications they actually understand and, especially for the
LetterDigit case, characters that actually are used to write
relevant human languages) are unlikely to run into significant
problems as a consequence of these issues or potential changes.
the specification were to say something like
Implementations that heavily restrict which characters they allow,
like limiting the set of permissable characters to a single script,
are unlikely to run into significant problems as a consequence of
these issues or potential changes.
I would find that much less objectionable.
Your suggestion I think is making too strong a claim, but I see where
you're going. You needn't limit to a single script or otherwise heavily
restrict to stay clear of potential problems; you simply have to stick
to the more restrictive classes provided, or if you need to use
free-form, then restrict to something more limited. So perhaps this
would be clearer, and capture your concern:
Even so, implementations that are sensitive to the advice given in
this specification (to use the more restrictive String Classes, or
otherwise to only allow a restricted set of characters, particularly
ones whose implications they actually understand) are unlikely to
run into significant problems as a consequence of these issues or
potential changes.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
