RE: i18n comments:

This doesn't make any sense to me. I think you are over-thinking this.

The author element contains the author's *NAME*. It can also include an href and an email attribute. UTR#36 refers explicitly to IRIs and IDNA addresses, which would be the values of these attributes. However, it does NOT refer to plain text (the body of the element 'author') which is what the 'dir' attribute really applies to. To not provide bidirectional overrides for the author's name strikes me as incredibly short sighted, given that you can override any higher-level element. To have one place in your configuration document that requires controls is not to improve security, it is to reduce usability.

It would make far more sense for you to cite UTR#36 with regard to an implementations presentation of the href or email attributes, suggesting (or forbidding) the application of the dir attribute to these values. But the body of the <author> element needs the bidi markup and should not depend on Unicode bidi controls.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: Marcos Caceres [mailto:marcosc@opera.com]
> Sent: Monday, March 29, 2010 4:35 AM
> To: "Martin J. Dürst"
> Cc: Felix Sasaki; Arthur Barstow; Phillips, Addison; public-i18n-
> core@w3.org; public-webapps; Richard Ishida
> Subject: Re: i18n comments:
> 
> Hi Martin,
> 
> On 29/03/10 10:01 AM, "Martin J. Dürst" wrote:
> > [comments below]
> >
> > On 2010/03/27 18:49, Marcos Caceres wrote:
> >
> >> Thanks Felix, I will update the schema. However, the BIDI spec
> warns,
> >> for security reasons, to avoid the overrides so I didn't include
> them
> >> into our spec. Should I put lro and rlo into the spec regardless?
> the
> >> spec now contains a note about this in the dir section:
> >>
> >> Note:
> >> Under the guidance of the [BIDI] specification, the values that
> would
> >> allow directional overrides in this specifications, namely Left-
> to-Right
> >> Override (LRO) and Right-to-Left Override (RLO), have
> deliberately been
> >> left out of this specification because of security concerns (see
> >> [UTR36]). Authors wanting to override the [BIDI] algorithm can
> do so by
> >> using [XML] entities and the appropriate Unicode directional
> markers.
> >
> > Reading this note, it seems to make NO sense whatever for me to
> leave
> > out the lro/rlo values. Essentially, the Note tells you that
> there is a
> > security problem that apparently was addressed, and then it goes
> on to
> > tell you how to circumvent the solution. Or did I get something
> wrong?
> 
> Your reading of the note is correct. My intention with excluding
> overrides was to make it slightly harder for authors (so they would
> not
> be used by accident). The spec may benefit from advisory for user
> agents
> - like warning end users if BDOs are used or making a visual
> distinction
> when an override occurs (particularly if they affect URIs).
> 
> I've adapted the following from TR36 as a straw-man, please feel
> free to
> improve:
> 
> "In the case where the BIDI algorithm has been explicitly
> overridden by
> the author, a user agent may use coloring or icons to draw the
> user's
> attention as a means of indicating that there may be a security
> risk
> with the presented content; or more obvious, the user agent may
> display
> an alert dialog describing the issue and requiring user
> confirmation
> before continuing (particularly in cases relating to IRIs); or even
> more
> stringent, a user agent may ignore the use the bidirectional
> overrides
> altogether. Implementers are encouraged to refer to [UTR36] for
> advice
> on dealing with the security risks associated with bi-directional
> text,
> IRIs, and Unicode in general."
> 
> Kind regards,
> Marcos
> 
> --
> Marcos Caceres
> Opera Software

Received on Monday, 29 March 2010 15:16:47 UTC