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

Matthew Kerwin <> Sun, 04 January 2015 13:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 693591A88BF for <>; Sun, 4 Jan 2015 05:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z8bT0D-4cNhR for <>; Sun, 4 Jan 2015 05:20:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DC6B1A88B4 for <>; Sun, 4 Jan 2015 05:20:44 -0800 (PST)
Received: by with SMTP id b13so15993927qcw.20 for <>; Sun, 04 Jan 2015 05:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k309RzrkthpGQ/c1LhDVSaa+ZDVyIbvK9p62ACQII6A=; b=mkCohFbUvkZ3vb+4cpLJMa4vF5W2L/NZ3KfzHuAXMBJa6M/Vn9N5lqkZUMZvd1QWQ5 73VyUKA5qmfzLymH+jgzo6ZAvd4xtjmOlD29Urd99Swg2u6fXSw2wLrmX/Fb2Dr4fgMs A4X9wJBunqSGKrKrJUXEUqB9O39xJ6LgaWiLel0tepv5KRzqdRGvECD3K6X50hzaIPUf v33xkH24RcPJHoaZsSKawiirQS04L5cLn9CbNLnc0dAp1So/X6nL9joSn/dojbVzEJKP YgMlg1f5186d6eBfM63sR1+X5KyAAMm7WgeLs+BJaMrb1dqwTwTZuUs27/IF9Jfy9FvL cCzw==
MIME-Version: 1.0
X-Received: by with SMTP id a1mr58005736qam.92.1420377643246; Sun, 04 Jan 2015 05:20:43 -0800 (PST)
Received: by with HTTP; Sun, 4 Jan 2015 05:20:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Sun, 04 Jan 2015 23:20:43 +1000
X-Google-Sender-Auth: 9xb8763MnQocdjMZlCLMt76WVGw
Message-ID: <>
From: Matthew Kerwin <>
To: Graham Klyne <>
Content-Type: multipart/alternative; boundary="001a11c2c31edf6a71050bd37054"
Cc: IETF Apps Discuss <>
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: Sun, 04 Jan 2015 13:20:46 -0000

On 3 January 2015 at 22:10, 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.
This is in the works. I've had a computer die, and been in full time
vacation mode for the past month, so I'm a bit behind schedule, but I'll
have something for folks to look at as soon as I can.

> 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.
> ]]
> --
> lNsLrE3xDYpo2GyvgHzGGZv-PLI
> 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).
Is there a reference somewhere that distinguishes URIs and URLs the way you
guys are here? I thought URL was still a subset of URI. Has that changed?

> 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.
Indeed. The normative core of the spec will be the pure RFC 3986-compatible
parts; the non-normative appendices will include bad things like pipe
characters and backslashes and such. I think it would be helpful to
*suggest* how to map those to valid URIs, at the very least so people can
update their old documents.

  Matthew Kerwin