On 2013/10/09 18:02, "Martin J. Dürst" wrote:
On 2013/10/09 5:55, Peter Saint-Andre wrote:
On 9/11/13 8:06 PM, Joseph Yee wrote:
Reviewed the draft, think the approach is good. Just one minor comment.
Same as Florian, had the 'hmm' reaction when reading about
directionality and application behaviour at Section 3.1. It seems that
the only application behaviour is permitted pattern. It doesn't deal
with visual appearance I believed. Maybe replace 'application
behaviour' with 'permitted patther of the string' (or 'allowed
combination of the string')?
Hmm, I see why you and Florian don't like that text. :-)
How about this?
OLD
Directionality: defines application behavior in the presence of code
points that have directionality, in particular right-to-left code
points as defined in the Unicode database (see [UAX9]).
NEW
Directionality: defines which strings are to be considered
left-to-right (LTR) and right-to-left (RTL), and the allowable
sequences of characters in LTR and RTL strings.
That may be an improvement, but it's missing the fact that LTR and RTL
strings are the only two alternatives allowed.
Also, it would be good to somewhere say that there is currently no
widely accepted and implemented solution for the display of constructs
with mixed pieces (e.g. domain names with LTR and RTL components
(labels), because the problem is inherently extremely hard.
In addition, in the introduction, there is a paragraph:
5. Leave various mapping operations (e.g., case preservation or
lowercasing, Unicode normalization, mapping of certain characters
to other characters or to nothing, handling of full-width and
half-width characters, handling of right-to-left characters) as
the responsibility of application protocols, as was done for
IDNA2008 through an IDNA-specific mapping document [RFC5895].
where "handling of right-to-left characters" is described as a mapping
operation. That doesn't make sense to me, I think it should be moved out
to a separate point.
Regards, Martin.
Regards, Martin.
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
