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: file://host/location URLs Date: Mon, 19 Nov 2012 12:54:00 +0900 Message-ID: <87haom6yef.fsf@uwakimon.sk.tsukuba.ac.jp> References: <50A57E1A.4040109@dancol.org> <50A6FDD7.4090304@dancol.org> <87a9ugljpg.fsf@Rainer.invalid> <50A8FF48.6090007@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1353297258 15148 80.91.229.3 (19 Nov 2012 03:54:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Nov 2012 03:54:18 +0000 (UTC) Cc: Achim Gratz , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 19 04:54:27 2012 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 1TaIRG-0002bs-P8 for ged-emacs-devel@m.gmane.org; Mon, 19 Nov 2012 04:54:26 +0100 Original-Received: from localhost ([::1]:51498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaIR6-0002qM-NH for ged-emacs-devel@m.gmane.org; Sun, 18 Nov 2012 22:54:16 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaIR2-0002pE-D6 for emacs-devel@gnu.org; Sun, 18 Nov 2012 22:54:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TaIQz-0003Z6-AX for emacs-devel@gnu.org; Sun, 18 Nov 2012 22:54:12 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:53947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaIQy-0003Rb-QP for emacs-devel@gnu.org; Sun, 18 Nov 2012 22:54:09 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id AD5E59708F7; Mon, 19 Nov 2012 12:54:00 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 706F61A2778; Mon, 19 Nov 2012 12:54:00 +0900 (JST) In-Reply-To: <50A8FF48.6090007@dancol.org> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:154947 Archived-At: Daniel Colascione writes: > Yes, my proposal violates the RFC. I maintain that nobody deliberately > constructs file URLs Shouldn't you put a period here? ;-) Seriously, I expect that people who deliberately write file URIs probably know what an RFC is, and may even have read the relevant ones. It's not like an http URI where any Facebook user has at least seen them. On the contrary, I had an experimental implementation of an URL handler that used TRAMP to deal with file URLs, and tested it with deliberately constructed file URLs. So "nobody" is wrong. I've seen such URLs in the wild, used properly though not in a programmatic context (in a trust group with access to several hosts, indicating use with SSH or scp, written on paper napkins and the like). > pointing to remote hosts, I disagree. To me, it's the obvious RFC-standardized way to write an ssh/scp/sftp URL[1] for fetching a file from a specific host, where the user of the URL is expected to be able to access the same file system on that host as the writer, but without constraining the user to a possibly inconvenient transport protocol. If you're saying that users sometimes write file://usr/bin/emacs when they mean either file:///usr/bin/emacs, file:/usr/bin/emacs, or maybe file:usr/bin/emacs, too bad for those users. Even on Windows, with a leading doubled slash the following element indicates the host providing a service (ie, a namespace authority in URI-speak). As for the bug in Emacs (and other programs), what else is new? Emacs is buggy. Fix the bug. > and that the behavior that best matches user intent is to always > interpret file URIs as local, RFC be damned. And what are you proposing? Should file://bogus/foo be interpreted as file:///bogus/foo or as file:bogus/foo? Or perhaps as file:///foo? If you want to know what users think, make file://bogus/foo... error at parse time if bogus doesn't resolve to the local host. They'll tell you. But it's a bad idea to guess, and a worse idea to take a precise syntax and make it fuzzy. Next users will request that such fuzziness should be allowed for http and other URLs. After all, it's obvious what they meant when they wrote http:/www.gnu.org/, right? By the way, none of the above means that you shouldn't write a defuzzer program to guess what possibly broken URIs were intended to be. Users who can't or won't learn how to write conforming URIs can install it themselves, and I see nothing wrong with that. But Emacs itself should follow the RFC here. The RFC is not broken. Footnotes: [1] Yes, I'm aware of the *long*-expired IETF draft, though not why it expired without being approved for RFC status. Possibly because of the overlap with the existing file URI?