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