Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

Sean Leonard <> Sat, 03 January 2015 20:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 61EB21A0040 for <>; Sat, 3 Jan 2015 12:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dcg3IRSKTAs5 for <>; Sat, 3 Jan 2015 12:07:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6FD121A000F for <>; Sat, 3 Jan 2015 12:07:12 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5824922E25F for <>; Sat, 3 Jan 2015 15:07:11 -0500 (EST)
Message-ID: <>
Date: Sat, 03 Jan 2015 12:06:11 -0800
From: Sean Leonard <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jan 2015 20:07:16 -0000

Basically this entire reply is a big +1 in the hopes of converging on 
consensus and moving onwards.

On 1/3/2015 4:10 AM, Graham Klyne wrote:
> Sam,
> Rather than continue the blow-by-blow exchange of points, let me try 
> and respond in one place where I think we stand:
> 1. I agree that draft-kerwin-file-scheme *should* work for everyone.  
> And that probably means reducing the scope of anything there that may 
> be considered normative.
>    But I also believe it can be useful to document other behaviours 
> *informatively*.  I think this is discussed elsewhere and anticipate 
> evolution in this direction.  This could mean, to develop your 
> example, describing Microsoft Windows specific behaviours without any 
> expectation that such behaviours would be implemented by Apple.

As I have stated previously, I do not believe that a Standards-Track RFC 
on this topic should enumerate local forms (i.e., Windows vs. Mac OS X 
vs. VMS vs. whatever). But informative text does not seem harmful to me.

> 2. I think our disagreement may lie primarily in the area of what 
> should be the scope of RFC 3986 or its successor.  There is (I claim) 
> a substantial developer community who are familiar with RFC3986 as it 
> stands, and creating a new document to cover the same material with 
> enlarged scope is unnecessary and disruptive. The additional scope 
> coverage could be in a new document that builds upon what RFC3986 does 
> specify.
>    Part of this disagreement is that I don't think the URI core spec 
> needs to describe the operation of splitting a URI into its 
> components.  (I regard 
> as merely informative.)  The syntax specification is sufficient to 
> associate substrings of a well-formed URI with named syntax productions.
>    I also think the core URI spec should not be describing how to turn 
> non-URI strings (some of which may be system-dependent forms) into 
> valid URIs.  (Except URI-references, which are covered by the 
> resolution specification.)
> 3. Where there is divergence between implementations and RFC3986, 
> these indeed should be considered on a case-by-case basis, but with 
> (IMO) the presumption that RFC3986 is correct.  I.e. it is for those 
> who think there is a problem with RFC3986 to make the case.
>    You ask me to spend time with your data.  That's a big ask.  If 
> some implementers think there is a problem with RFC 3986 then I think 
> it is they who should be making the specific arguments about where 
> RFC3986 is problematic.  I accept that UTS-46 host names is such an 
> area, concerning which there should be a considered and focused debate 
> (and about which I have insufficient knowledge to make a meaningful 
> contribution).
+1. UTS-46 host names shouldn't affect the file: scheme any differently 
than anything else.

> 4. I agree with your point about qualifying my statement about 
> system-dependent forms conforming to core URI syntax.  While forms 
> such as "C:\Program Files (x86)" might be described as variations, I 
> don't think they should be considered to be valid URIs.
> I'm supportive of the strategy you outline (repeated here for ease of 
> reference), which I don't think is so different from what I've argued 
> for:
> [[
> A strategy that is more likely to be successful would be to identify 
> URIs as being completely system independent, and URLs as being mostly 
> system independent, and for there to be a well known and documented 
> mechanism for converting from URLs to URIs.  Even that is not likely 
> to be completely achieved -- the conversion may end up being (at least 
> partially) system dependent, but in such cases we should be able to 
> define the problematic set of the inputs as non-conforming.
> ]]
> -- 

> Where I may diverge is that I don't think the "well known and 
> documented mechanism for converting from URLs to URIs" should be part 
> of the URI specification (cf. my point 2 above).
+1 it's a local convention issue

> 5. The previous point also begs the question of what should be covered 
> by the file: scheme document.  I think it may be appropriate to 
> describe some commonly occurring system-dependent file: URL forms, but 
> I'm less convinced that this is the place to describe how to map them 
> to URIs.  Any normative specification of file: URI formats should be 
> restricted to forms that comply fully with RFC3986.

There could be some value in having a "normative" file: URI 
format...which if anything, probably means that it is:
file://{HOST}/{root stuff}/{directories...}/{filename}

In an abstract non-system-specific way, that fully complies with RFC 3986.

Individual systems (Windows, Mac OS) can have other forms (e.g., \ 
[which doesn't comply with 3986 and thus is not a URI] or : [which does 
comply and therefore is a URI, but isn't analyzable in the 3986 
p-component way]), and those other forms are acceptable for their use, 
but they aren't the "normative" form (whether or not they are "URIs") 
and that's okay.

The end.