[apps-discuss] draft-kerwin-file-scheme and hosts

Sam Ruby <rubys@intertwingly.net> Sat, 20 December 2014 00:45 UTC

Return-Path: <rubys@intertwingly.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548201A8032 for <apps-discuss@ietfa.amsl.com>; Fri, 19 Dec 2014 16:45:39 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 DqHHoXgOQPjD for <apps-discuss@ietfa.amsl.com>; Fri, 19 Dec 2014 16:45:37 -0800 (PST)
Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id B8B0E1A1B0D for <apps-discuss@ietf.org>; Fri, 19 Dec 2014 16:45:37 -0800 (PST)
Received: from [98.27.51.253] ([98.27.51.253:10091] helo=rubix) by cdptpa-oedge01 (envelope-from <rubys@intertwingly.net>) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 80/78-17706-0B6C4945; Sat, 20 Dec 2014 00:45:37 +0000
Received: from [192.168.1.102] (unknown [192.168.1.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: rubys) by rubix (Postfix) with ESMTPSA id BA61E140D25; Fri, 19 Dec 2014 19:45:35 -0500 (EST)
Message-ID: <5494C6AF.4070902@intertwingly.net>
Date: Fri, 19 Dec 2014 19:45:35 -0500
From: Sam Ruby <rubys@intertwingly.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Matthew Kerwin <matthew@kerwin.net.au>
References: <CAL0qLwYrAGk-gpfMKigy8C8CCzdA4NhQv60UdUmBtXdkQF10SA@mail.gmail.com> <54922C81.4030908@intertwingly.net> <CACweHNDT4iNmDyGkvDBa08apPcaQC7hoAQ2gFZxYE-8wFiDrvg@mail.gmail.com>
In-Reply-To: <CACweHNDT4iNmDyGkvDBa08apPcaQC7hoAQ2gFZxYE-8wFiDrvg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-RR-Connecting-IP: 107.14.168.118:25
X-Cloudmark-Score: 0
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/C3iiIZoXzX7hF65wRyrgt9R6vVQ
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] draft-kerwin-file-scheme and hosts
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sat, 20 Dec 2014 00:45:39 -0000

On 12/17/2014 09:01 PM, Matthew Kerwin wrote:
> On 18 December 2014 at 11:23, Sam Ruby <rubys@intertwingly.net
> <mailto:rubys@intertwingly.net>>wrote:
>
>     This is NOT an objection, but I will note that
>     draft-kerwin-file-scheme makes a reference to a document I co-edit:
>
>     https://tools.ietf.org/html/__draft-kerwin-file-scheme-13#__ref-WHATWG-URL
>     <https://tools.ietf.org/html/draft-kerwin-file-scheme-13#ref-WHATWG-URL>
>
>     I further would like APPSAWG to consider the following as input:
>
>     http://tools.ietf.org/html/__draft-ruby-url-problem-00
>     <http://tools.ietf.org/html/draft-ruby-url-problem-00>
>
> ​Yes, the more this can tie in with other efforts (notably​ in the W3C
> and WHATWG) the better. If draft-ruby-url-problem eventually ends up
> with a BCP we'll definitely do all we can to adhere to it, and even
> without, I think the principle is worthy and we'll strive anyway. If
> that involves a reference to a new informational RFC, all well and good.

Thanks!

I'm sure that we can learn much from each other, and the specs we 
produce will benefit as a result.

To start off, I'd like point out one area where there may be some 
technical issues that you might not be aware of -- and I encourage you 
to do the same with specs I am working on.

So as to not affect the call for adoption, I've changed the subject line.

The area I've chosen to focus on first is host names -- something that 
is particularly thorny.  The RFCs you reference don't quite capture all 
of the necessary behavior.  I encourage you to explore the following 
URIs.  In particular, I recommend exploring these with the Chrome browser:

file://2130706433/foo
file://[2001::1]/foo
file://0Xc0.0250.01/foo

Note that the last one is using Unicode wide characters.  An alternate 
representation would be as follows:

file://\uFF10\uFF38\uFF43\uFF10\uFF0E\uFF10\uFF12\uFF15\uFF10\uFF0E\uFF10\uFF11/foo

You may find the following online tool to be handy for exploring cases 
such as these:

https://url.spec.whatwg.org/reference-implementation/liveview.html

- Sam Ruby