From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Bidirectional text and URLs Date: Tue, 02 Dec 2014 05:08:11 +0900 Message-ID: <87a937m8us.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87a93cngwv.fsf@uwakimon.sk.tsukuba.ac.jp> <837fyfml31.fsf@gnu.org> <874mtio7wh.fsf@uwakimon.sk.tsukuba.ac.jp> <83r3wml8kq.fsf@gnu.org> <87zjb8n6th.fsf@uwakimon.sk.tsukuba.ac.jp> <837fyb8htc.fsf@gnu.org> <87d283mdaw.fsf@uwakimon.sk.tsukuba.ac.jp> <83oarn6v7b.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1417464549 19743 80.91.229.3 (1 Dec 2014 20:09:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 20:09:09 +0000 (UTC) Cc: larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 21:09:02 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XvXHF-00054i-EC for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 21:08:57 +0100 Original-Received: from localhost ([::1]:33671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvXHE-0004eD-T1 for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 15:08:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvXGu-0004dz-4Q for emacs-devel@gnu.org; Mon, 01 Dec 2014 15:08:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvXGm-0002KX-L4 for emacs-devel@gnu.org; Mon, 01 Dec 2014 15:08:36 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:58407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvXGe-0002F7-Ik; Mon, 01 Dec 2014 15:08:20 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CA3261C39C0; Tue, 2 Dec 2014 05:08:11 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A82571A273D; Tue, 2 Dec 2014 05:08:11 +0900 (JST) In-Reply-To: <83oarn6v7b.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178645 Archived-At: Eli Zaretskii writes: > > Note that RFC 3987 specifies that bidirectional IRIs must *always* be > > displayed with the UBA, and as if in an LRE embedding. I'm not sure > > how you would enforce it, but I believe this would defang larsi's > > example (ie, at the start of the URI proper in logical order insert a > > LRE, and at the end a PDF -- any directional format characters between > > those points are nonconforming to RFC 3987, section 4.1, last > > paragraph). > > Using an LRE..PDF embedding is a possibility, but it can be defeated: > the UBA mandates that any embeddings above some predefined fixed depth > are to be ignored. So a malicious code could insert a large enough > number of RLOs such that any LRE would be ignored. Note that RFC 3987 is a MUST, and OTOH does not specify an implementation (probably precisely because of the nesting issue). > That's one of the reasons why I prefer not to poke the text with > additional directional controls. You don't need to poke them into the text. You just MUST display IRIs "as if" there were an effective embedding. I'm aware of the GNU mantra "standards are sometimes not a terrible idea -- but only sometimes". But in this case I think conformance is a very good idea. > > If they're inside the IRI, they're non-conforming and therefore bogus, > > and would be caught by the tooltip. > > Yes, but tooltips could be overlooked (or even disabled globally by > the user). I think for the cases we've identified so far (LTR-only text in a RTL context, RTL-only text in an LTR context, and directional controls embedded in an IRI) you probably want to require the user who clicks on them to confirm that they want to follow this misleading link, anyway.