Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme

t.petch <ietfc@btconnect.com> Wed, 13 April 2016 16:56 UTC

Return-Path: <ietfc@btconnect.com>
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 3528212DB7C; Wed, 13 Apr 2016 09:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 hgd1IPrwT8Gy; Wed, 13 Apr 2016 09:55:58 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0091.outbound.protection.outlook.com [104.47.0.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A1512DAF4; Wed, 13 Apr 2016 09:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J/V3nyRyA5mv5TgHQ7D3HZ1VRZla7u7gHmgdWRSDvTc=; b=URs5mmZQoYTM2HQIfaRQKGUKWUgln0osVoF/CgYE/joqgMblXGKERKLJsTPYro8VySwj4/3sltzKYC050u+MBdOY4ewu16uiMDn5oGfWiNuBNnjs7gZtvNBlDVZ4arYzkEIROnC96ZHfC+4hWhXD+GoXTEf/nvi47dmLcm182Vo=
Authentication-Results: ninebynine.org; dkim=none (message not signed) header.d=none;ninebynine.org; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (86.171.1.17) by AM4PR07MB1620.eurprd07.prod.outlook.com (10.166.132.150) with Microsoft SMTP Server (TLS) id 15.1.453.11; Wed, 13 Apr 2016 16:55:53 +0000
Message-ID: <01b901d195a4$e9e18060$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Graham Klyne <gk@ninebynine.org>, Matthew Kerwin <matthew@kerwin.net.au>, Dave Crocker <dcrocker@bbiw.net>
References: <570D4C99.1030405@dcrocker.net> <CACweHND-OX+5okkJ+oE=6UN84x+CFtPBpMnU8HqaPbgQgJ_oWA@mail.gmail.com> <570E1D3A.5050608@ninebynine.org>
Date: Wed, 13 Apr 2016 17:39:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.171.1.17]
X-ClientProxiedBy: DB3PR08CA0017.eurprd08.prod.outlook.com (10.161.51.155) To AM4PR07MB1620.eurprd07.prod.outlook.com (10.166.132.150)
X-MS-Office365-Filtering-Correlation-Id: e06cc3b6-1fce-462b-527d-08d363bc79f5
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 2:I33NlcQvbwe962KqmRHH4SZmRMx14Vfa6nsjWE9D8Ag8dOoFt2h17SO6E8nAjhJyERtBXYQ+1V/w9QdSh2nsQXKLcUMiH01OmGf7FGze1SGl/PABfobcZyHipIWV1RblNRoQzm61jvp1elegXGBm8OArxojy9tJFU/R7rcTfvnLzOeNo1ENkA/KH4JKOjAk7; 3:yJTK4Lwy4cKwDIeF7yV1OEPyv2ufMaUidXFPr7rSyn7jJdCpp4hXfjHc5Qk81q5TrKhNWEnbG1RR20Wo/Q6wKyzcU7BZkQ/oqTE4722AcQHBHee/sGclSOB0lpdycD6T
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1620;
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 25:WczgEymjCRmY/VaGkZOZr3g1B7Tzif9pXh44xK6NjV5mUX6sUE+WwYM0T/Q1XZOiX6GwA3Qn9eRforzA2uAbRA8k+Xg0hswdLRNWHHuUwgErdHAfUfFcSOkvAoehbBKIyTJ1msYTw9AApPmcuoziYOnB/BBo92TRbVhscub3jKwwr8+mOk6OSBwMGbZkiwyBWX7G8QMBkkIxsid5k4g2LhNCEQUWv1ctYrDLA8Ega//8Yld8xwbQFYGZPX1ZIg7OeRcRbDGmA5iBWP0nCjERRmaOM5qDAw+DSqVbMyxNFwcB30c8BYhNmLxhi9e5tCBMKniSr7bDeDycNjnV4b9zhBVqODFPuBvsTyzuUK1kG5nr7koU1DbOnDFqxG9mVQYmow2+Y0jilFKF+sfB68vnyZyLgGnSEZpMsbGli5DqsU35Cg1bWhl9AcBdgCAoA8ni0I3TwfPYPhO6sFKA8KwNpU4aZIdr050VEwtqjDwTah9ZcxlbG2k/PGwMy4J1m+e5Rs9775yYIrMcUDx9sqei7Yl4BYOBihDxyh3a5M7zj1Jimnps1bcA8z8MctNLThtPts0Wv/zBbDdHU3sNke+y+LawFfNigGcYGoggBZZyy+Q5q89yv2n5rExo89jnpafOcmJLiRMFA6gY4WulMZqgZw3PKrukWhf0xInuTKFjFIi0ltELVagqlgaQXqKIQODUh0y6gPyeZz3rLEAITvX4hG+NO+cnQi68D/m3opMmbYk=
X-Microsoft-Antispam-PRVS: <AM4PR07MB16200779C24ACE34BEE5D8CAA0960@AM4PR07MB1620.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM4PR07MB1620; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1620;
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 4:4mIg9L51gyQyjFqfCAHtzP8Ydg+vOTqU/2jLXjKbf5/21WC6RmpYq2wQVWyLY0UmpJgnEy+OeSrFGlcy92WHOMDC2U0LATGr8cglKhMGyyrK2dUD94nwGixEFHDqaPCmmgPDqSYL6PbCfNSTrSES2hoiaVe/5iJpva2GQdpxqzS1n61oQr/z2PNrQFWe7bI+h2nl0VePsPd89dQAw/2iOT21c81ay7u6p57B7I5sQQy+JfTLHmqj7BZ46t3AdmLswXKrAbP8QFA79PLLRw1Ozdvl10nRA3AxpqBIoOnjQgMUeXvG4khzpL38cerhFLC0ur7Rrfrs2Z6bh4X5OptzyKHq4a9WZNIqqjf7t9+u/mgIzcAgVKtE+bhnWog0R3fX
X-Forefront-PRVS: 0911D5CE78
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(24454002)(377454003)(51444003)(81166005)(5008740100001)(230700001)(586003)(4326007)(84392002)(1720100001)(15975445007)(42186005)(1456003)(77096005)(2906002)(9686002)(61296003)(1556002)(44716002)(62236002)(47776003)(15395725005)(230783001)(81816999)(50986999)(81686999)(76176999)(66066001)(86362001)(5001770100001)(5004730100002)(92566002)(3846002)(1096002)(6116002)(23756003)(19580405001)(19580395003)(189998001)(50226001)(19273905006)(50466002)(33646002)(74416001)(7726001)(4720700001)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1620; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM4PR07MB1620; 23:6vW0EjHtisX4VDX2C1pdctwYlx22fvlKH7c6KVU?= =?iso-8859-1?Q?+EIuiG7q1psdHVGgdsN5KDPp6oHH4ZScts7SqAV7AXPbMXVlmJJvlOHHYz?= =?iso-8859-1?Q?Y2UOcqimr/46nXVGZrBgfrDlovCBspKrWfh/PPEOZrkkYWVKFdq1kPHFw4?= =?iso-8859-1?Q?0J+tc5jyhTN2q2WUoFymibDP1wFrcm9qQ2ZdV9g4PP9lb/0eB+YA21Oo0/?= =?iso-8859-1?Q?nP+bqezsUEGMHERS0CJJLoFioSYFcgps1nM/h/ojMIrkEgPwy0/IFjPmMh?= =?iso-8859-1?Q?quOe26wCApLMOrJcEKVrJuv7Hje6j0iqCafeS3FGPqIiDudfCNoE5GQYdg?= =?iso-8859-1?Q?8f1T+2yKITqsTkt8UfEDiUONRHSu+4mV7omlI9UJ0UaswSC2J1a31HO7Li?= =?iso-8859-1?Q?nfawLg5uPbwHTBOqad0YRFx+jWgVJ9BCH56ZbzVbylHMZCZ10Wc9CXPfaG?= =?iso-8859-1?Q?Js9/yiArvc/0gaAYbzSjDR6o87FYhwC1inhltWanc0tqoa+dl+3F0c1uvf?= =?iso-8859-1?Q?aSI9P+hVbfS9EhPhyroCoxTnNegjfj/0zv3Rd4u1HGQRN55lR4K049QiMW?= =?iso-8859-1?Q?I63sxQNVQPDaytqXM43kJq1VU8JyyTBeo/yFV2dkwS6cvnHD6hEEFAqWWb?= =?iso-8859-1?Q?7474ENVrz8wOhQqOpLccFCrI1Fie33C76TP37ggjhciK+DMd6zH6cgfwLk?= =?iso-8859-1?Q?DIW3hjwEx004PeFk98dezj9JEGF0gfc4//Y0u7PMi3YAnv46p9YeRCDORe?= =?iso-8859-1?Q?5J/TfyoHjqitdpcLPXOJLQ32TCvEPxG2P5ZNJfMG+Wqf9nh4ObPXmjIq+C?= =?iso-8859-1?Q?4qMcaXJqhFAVW+1e1iNZteHGVVqvYwftYAgdbKP2OF7V1g4o7GsjG6VtyD?= =?iso-8859-1?Q?FSGfxo7XGofAB2L8PO7P799F08VPfrnMQYcY3kSgsVn4cDKFdDPgql+bLj?= =?iso-8859-1?Q?G5u/hiEaROztMfF7Bf9j/LhqEHNzhYEL63qENT3yyRnskN+uCrDk+5aG6T?= =?iso-8859-1?Q?dXbkaO5uIMaBwDgHPnCY6v4oBmKkzY2tKdXZtmneKFfwftlgDJmaYvRfSe?= =?iso-8859-1?Q?xy3sWFpg0CqsR8Rbk+Cm3qM6ZiZVPjoFa/abWbpKKMZdPp/E7jxl4I5Ru+?= =?iso-8859-1?Q?/aZKazySykcbfo2Ee7YP5lI/SHriH0/rAqFVMFqgM/y7RdNr2h4obu0uH2?= =?iso-8859-1?Q?6qykGXpX1PSA0S21zmKkABuFQAytg3PQxTt0SOKy0fJccXpekjBVk0OUgs?= =?iso-8859-1?Q?T5hFk/hnhpNQbWGJWBXvc7PEQ8HSg6yPjxL2nyu6nGlM+QTZD//KgURQPQ?= =?iso-8859-1?Q?zIzTTdcIK/GYKCRDJ8HMA2BvF8dToVhDatpePLSaATO8Q=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 5:k4xB5CokSyHC5gPUF0mEP2WZJwY4+tasLvGNNRibAtUhyPC4a7IAAFYq136WLhxW2OuoP4KOjEqxD5SfNy8w4B5B4d/A3zGV0SwnG/TA6d4r78kWw0e+/1Q0FCLadedlFHWil3FUDoo0feXqa/mNXw==; 24:vi0C+DskOv0lGe0GtHJUjzCCu9nImMmDVr4ajsxOW2HmVaCj6s+g1paEFCkyqBlM6eMZ0IWXXFyBwI4hQ6Viscy4nj7itdWmi9v8Uu5ZZNg=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 16:55:53.3306 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1620
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/syGWPcgw5AuZVuXCpSz6uxt8VGo>
Cc: Apps Discuss <apps-discuss@ietf.org>, draft-ietf-appsawg-file-scheme@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-file-scheme
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, 13 Apr 2016 16:56:01 -0000

----- Original Message -----
From: "Graham Klyne" <gk@ninebynine.org>
To: "Matthew Kerwin" <matthew@kerwin.net.au>au>; "Dave Crocker"
<dcrocker@bbiw.net>
Cc: <draft-ietf-appsawg-file-scheme@ietf.org>rg>; "Apps Discuss"
<apps-discuss@ietf.org>
Sent: Wednesday, April 13, 2016 11:19 AM

> Dave,
>
> (writing as a s/w dev who uses URIs a lot...)
>
> I think the role of file: URIs is slightly unusual as a protocol
element.  It
> appears in contexts where a network address may be used, but (in my
experience)
> is mainly used to trigger local access.  So in an application that
uses a URI
> like "http://example.org/somedata" to address some data on the web, it
can also
> be really useful to be able to use "file:///somelocaldata" to tell the
> application to read a local file.  What I never use is a file URI to
actually
> access data from another system (*).  So I don't think that interop of
> cross-system data access is the primary concern here.
>
> BUT, there is one case where common interpretation and interop is
really
> important, and that is relative URI reference resolution.  Something I
commonly
> do is use relative references (e.g. "someplace/somedata") in my data,
which may
> be hosted on a web server (e.g. "http://www.example.org/") or in a
local file
> system ("file:///home/user/exampledata/").  What is important to me is
that the
> relative reference resolves consistently in these situations.  E.g.,
for the
> examples given, to yield absolute addresses respectively of:
>
>    http://www.example.org/someplace/somedata
> and
>    file:///home/user/exampledata/someplace/somedata
>
> In the past, the problem has been that the local system quirks cause
deviant
> behaviour (e.g. what happens if the base URI used is based on a
Windows path,
> e.g. "C:/someuser/") - it is "edge cases" like this that have caused
me
> difficulties in the past running software on different systems.
>
> I believe that Matthew's draft, as currently structured, does usefully
navigate
> this space between desired and widely implemented core functionality
and
> likely-to-be-encountered quirks.  I would hope that by publishing this
as a
> standard document, we will see programming language URI-handling
library
> functions converge to provide the defined core behaviour.

So do I.

I note that RFC3986 starts by saying
"   This document specifies an Internet standards track protocol .."
which I think a load of rubbish.  It then goes on to say
" A Uniform Resource Identifier (URI) is a compact sequence of
   characters that identifies an abstract or physical resource.  "
which I find spot on.  But in the days of RFC3986, the 'rubbish' had to
appear first:-(

I think that the IETF is expert at specifying protocols and may struggle
to find the right language to specify entities that are not protocols,
as commonly understood, such as DDLs, identifiers, meta-syntactic
languages and so on.  By which I mean that I disagree with Dave's
comments on this I-D relating to protocols; were we specifying a
protocol sensu stricto, they would have merit - but we are not.

Tom Petch

> #g
> --
>
> (*) other than a mounted network file system.
>
>
>
> On 13/04/2016 09:28, Matthew Kerwin wrote:
> >> >
> >> >A file: construct should be of significant utility to the Internet
> >> >community.  So it warrants careful community review and extensive
> >> >indication of active support.  That is, there ought to be a basis
for
> >> >assessing the likelihood of implementation and use.  As of now,
this is not
> >> >possible.
> >> >
> >> >
> > Technically it's already implemented in a bunch of places, not
always
> > entirely interoperably. Most of the non-interoperable parts are in
the edge
> > cases, but the "common core" is pretty universal. Since there's no
> > (non-obsolete) spec that defines it, what I want to achieve with
this draft
> > -- if nothing else -- is to put that "common core" in a
(non-obsolete) spec.
> >
> > If that just meant de-obsoleting RFC 1738 that would almost be
enough
> > (although an update might be in order.) However the discussion that
started
> > with that question has lead us to where we are now, with this draft.
> >
> > For what it's worth, at least one potential implementation is
likely: the
> > Ruby standard library OpenURI module, which was the original reason
I
> > started pursuing this in the first place (
> > https://bugs.ruby-lang.org/issues/8544)
> >
> >
> >
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss