Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-05.txt (relative URIs)
Stephan Bosch <stephan@rename-it.nl> Wed, 16 March 2016 14:24 UTC
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2C12D78A for <apps-discuss@ietfa.amsl.com>; Wed, 16 Mar 2016 07:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BoznrvD-ZEn for <apps-discuss@ietfa.amsl.com>; Wed, 16 Mar 2016 07:24:41 -0700 (PDT)
Received: from sogo.guto.nl (guto.nl [178.21.117.49]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F6912D722 for <apps-discuss@ietf.org>; Wed, 16 Mar 2016 07:24:29 -0700 (PDT)
Received: from wlan018160.mobiel.utwente.nl ([130.89.18.160]) by sogo.guto.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <stephan@rename-it.nl>) id 1agCN6-0000Ys-BC; Wed, 16 Mar 2016 15:24:25 +0100
To: Matthew Kerwin <matthew@kerwin.net.au>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <20151201004350.6084.94598.idtracker@ietfa.amsl.com> <CACweHNDzUSpZYgR6qabNCPrL_x4HNTAmP-aSTJK+2Jr4txNuVA@mail.gmail.com>
From: Stephan Bosch <stephan@rename-it.nl>
Message-ID: <56E96C95.1020106@rename-it.nl>
Date: Wed, 16 Mar 2016 15:24:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CACweHNDzUSpZYgR6qabNCPrL_x4HNTAmP-aSTJK+2Jr4txNuVA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090300000202030402070205"
X-SA-Exim-Connect-IP: 130.89.18.160
X-SA-Exim-Mail-From: stephan@rename-it.nl
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on sogo.guto.nl)
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/qVQp-OaK81mwkGKoRTdeTtsoYSg>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-05.txt (relative URIs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2016 14:24:50 -0000
Hi, I have a question about relative URI resolution with respect to the file URI. I know I am a bit late to the party, but this work hasn't caught my eye before; I only read this draft in a moment of boredom in my coffee break. I quickly skimmed the mailing list, but I haven't seen any recent discussions on this topic. There is only a very specific Windows case described in Appendix C of the draft. I am not an expert, but I find RFC 3986 Section 5 rather confusing. When is reference resolution applied? According to Section 5.2.2, absolute URIs can be subject to the resolution algorithm as well. The main effect of that is the application of the remove_dot_segments() algorithm, which removes all "../" and "./" instances from the path. So, is this always applied before a URI is interpreted? Does it apply to an absolute file URI? This leads to the following concrete questions: - Does the OS file system path extracted from an absolute file URI like "file:/frop/./friep/../frml" include the dot segments? Or is the remove_dot_segments() normalization always applied? So, is "/frop/frml" or "/frop/./friep/../frml" going to be passed to e.g. the open() system call on a POSIX system? Does that matter? It might: when the path contains symbolic links on a POSIX system, the use of ".." can cause semantic differences between the URI-based normalization and what POSIX systems do. Here's the GLibC implementation of the stdlib realpath() function that performs the POSIX equivalent of remove_dot_segments(): https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/canonicalize.c;h=58bb8de949bc8cc705de7c0840c859fed7b06c01;hb=HEAD#l43 - In that regard, how are relative URIs handled when the base is a file URI? In any case, I think these concerns need to be addressed explicitly in the document, so that the semantics are always as clear as possible. Regards, Stephan. Op 1-12-2015 om 1:56 schreef Matthew Kerwin: > Hi folks, > > I've pushed out a new version of the file URI draft which I believe > addresses most of the feedback received over the past couple of weeks. > Looking at the rfcdiff[1] the biggest changes were: being more clear > about how we're using/overriding components like "authority" from RFC > 3986, and rearranging the examples throughout the appendices to be > "description - example" (from "example - description".) > > I also misspelled "ooperation." :\ > > Cheers > > [1]: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05.txt > > > On 1 December 2015 at 10:43, <internet-drafts@ietf.org > <mailto:internet-drafts@ietf.org>> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ART Area General Applications > Working Group Working Group of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-05.txt > Pages : 20 > Date : 2015-11-30 > > Abstract: > This document specifies the "file" Uniform Resource Identifier > (URI) > scheme, obsoleting the definition in RFC 1738. > > It attempts to define a common core which is intended to > interoperate > across the broad spectrum of existing implementations, while at the > same time documenting other current practices. > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area > Working > Group discussion list <apps-discuss@ietf.org > <mailto:apps-discuss@ietf.org>>. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at > tools.ietf.org <http://tools.ietf.org>. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org <mailto:apps-discuss@ietf.org> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- > Matthew Kerwin > http://matthew.kerwin.net.au/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss
- [apps-discuss] I-D Action: draft-ietf-appsawg-fil… internet-drafts
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Matthew Kerwin
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… t.petch
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Stephan Bosch
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Matthew Kerwin