From nobody Mon Apr 4 03:06:24 2016 Return-Path: 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 10DD612D54F for ; Mon, 4 Apr 2016 03:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=dvJ1zyut; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=bsgh1npA 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 7spzWEYETJeW for ; Mon, 4 Apr 2016 03:06:19 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4559912D565 for ; Mon, 4 Apr 2016 03:06:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 95E3B20977 for ; Mon, 4 Apr 2016 06:06:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 04 Apr 2016 06:06:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=mPzRHHzOt8mx7L1Z iEgiqbnWZzg=; b=dvJ1zyutUUn65RMzHhi7wuMtcdiWNlT1TRszrnx0nWUjyzWz I65rQIWS6Jm2G9IQLE4CeOBTvpgL5oAYCDqsp0QBj3fJ+IzcKkW70mSwCbilk9zF W9QR/70pGkVYU8F4ZtDPWpka+3beF10IioseJbLWd0wDzklabn+MccCVgH8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=mPzRHHzOt8mx7L1ZiEgiqbnWZzg=; b=bsgh1npAjnwbKQXiP1Vw AfyjTPN/xjAXa4jQqDALzkhjtbnxiRcz4YPgkOUxvMilHsZ/Du5PcrI1dOvs1vKG pnkDIWFDTR0VO/edyjP1THQw8weCb32Zm6NYsBgkwIxmCqBRN+oavSVfKKLNZaGt I52D91uvSZZcrzIU40J/ssw= X-Sasl-enc: enMa/H36oDQyGZq3SC/H1P1lCJ/EWKzg6NCikM1tkU7q 1459764377 Received: from dhcp-8c14.meeting.ietf.org (dhcp-8c14.meeting.ietf.org [31.133.140.20]) by mail.messagingengine.com (Postfix) with ESMTPA id AD0B3C00022; Mon, 4 Apr 2016 06:06:16 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0" Date: Mon, 4 Apr 2016 07:06:15 -0300 References: <492694C0-1033-41FB-A06B-63648F143E7E@netapp.com> To: dispatch@ietf.org, apps-discuss@ietf.org Message-Id: <200C687E-B73D-4950-B188-956137247119@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [apps-discuss] Fwd: ANRP presentations at IETF-95 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 10:06:22 -0000 --Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Forwarding since folks might want to check out these talks in the = IRTFOPEN session, Tuesday at 10:00am in Pacifico A. > Begin forwarded message: >=20 > From: "Eggert, Lars" > Subject: ANRP presentations at IETF-95 > Date: March 10, 2016 at 1:34:47 PM GMT-3 > To: "irtf-announce@irtf.org" , "ietf@ietf.org" = , "95attendees@ietf.org" <95attendees@ietf.org> > Reply-To: "anrp@irtf.org" >=20 > Hi, >=20 > we are extremely pleased to report that for the 2016 award period of > the Applied Networking Research Prize (ANRP), 53 eligible nominations > were received. Each submission was reviewed by several members of the > selection committee selection committee according to a diverse set of > criteria, including scientific excellence and substance, timeliness, > relevance, and potential impact on the Internet. >=20 > Based on this review, six submissions are awarded an Applied > Networking Research Prize in 2016. Two prize winners will present > their work at the IRTF Open Meeting during IETF-95 in Buenos Aires, > Argentina. The ANRPs for IETF-95 go to: >=20 > *** Roya Ensafi *** for examining how the Chinese "great firewall" > discovers hidden circumvention servers: >=20 > Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, > Nicholas Weaver, and Vern Paxson. Examining How the Great Firewall > Discovers Hidden Circumvention Servers. Proc. ACM Internet > Measurement Conference (IMC), Tokyo, Japan, October 28-30, 2015. >=20 > *** Zakir Durumeric *** for an empirical analysis of email delivery > security: >=20 > Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Elie > Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, Michael > Bailey, and J. Alex Halderman. Neither Snow Nor Rain Nor MITM=E2=80=A6= An > Empirical Analysis of Email Delivery Security. Proc. ACM Internet > Measurement Conference (IMC), Tokyo, Japan, October 28-30, 2015. >=20 > Please subscribe to the IRTF-Announce mailing list in order to receive > future calls for ANRP nominations and join ISOC to stay informed of > other networking research initiatives: >=20 > https://irtf.org/mailman/listinfo/irtf-announce > https://isoc.org/join >=20 > Regards, >=20 > Lars Eggert, IRTF Chair https://irtf.org/anrp > Mat Ford, Internet Society https://isoc.org/research/ >=20 >=20 > 2016 ANRP Selection Committee >=20 > Mark Allman, ICIR > Marcelo Bagnulo, UC3M > Lou Berger, LabN > KC Claffy, CAIDA > Mark Crovella, Boston University > Lars Eggert, NetApp > Stephen Farrell, Trinity College Dublin > Nick Feamster, Princeton > Mat Ford, ISOC > Lisandro Granville, UFRGS > Volker Hilt, Bell Labs > Suresh Krishnan, Ericsson > Al Morton, AT&T Laboratories > J=C3=B6rg Ott, Aalto University > Colin Perkins, University of Glasgow > Aiko Pras, University of Twente > J=C3=BCrgen Sch=C3=B6nw=C3=A4lder, Jacobs University Bremen > Joe Touch, USC/ISI > Rolf Winter, Hochschule Augsburg > Lixia Zhang, UCLA >=20 --Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Forwarding since folks might want to check out these talks in = the IRTFOPEN session, Tuesday at 10:00am in Pacifico A.

Begin forwarded message:

From: = "Eggert, Lars" <lars@netapp.com>
Subject: = ANRP = presentations at IETF-95
Date: = March 10, 2016 at 1:34:47 PM = GMT-3

Hi,

we are extremely pleased to report that for the 2016 award = period of
the Applied Networking Research Prize (ANRP), 53 = eligible nominations
were received. Each submission was = reviewed by several members of the
selection committee = selection committee according to a diverse set of
criteria, = including scientific excellence and substance, timeliness,
relevance, and potential impact on the Internet.

Based on this review, six submissions are = awarded an Applied
Networking Research Prize in 2016. Two = prize winners will present
their work at the IRTF Open = Meeting during IETF-95 in Buenos Aires,
Argentina. The = ANRPs for IETF-95 go to:

*** Roya Ensafi = *** for examining how the Chinese "great firewall"
discovers= hidden circumvention servers:

=    Roya Ensafi, David Fifield, Philipp Winter, Nick = Feamster,
   Nicholas Weaver, and Vern = Paxson. Examining How the Great Firewall
=    Discovers Hidden Circumvention Servers. Proc. ACM = Internet
   Measurement Conference (IMC), = Tokyo, Japan, October 28-30, 2015.

*** = Zakir Durumeric *** for an empirical analysis of email delivery
security:

=    Zakir Durumeric, David Adrian, Ariana Mirian, James = Kasten, Elie
   Bursztein, Nicolas = Lidzborski, Kurt Thomas, Vijay Eranti, Michael
=    Bailey, and J. Alex Halderman. Neither Snow Nor Rain = Nor MITM=E2=80=A6 An
   Empirical Analysis = of Email Delivery Security. Proc. ACM Internet
=    Measurement Conference (IMC), Tokyo, Japan, October = 28-30, 2015.

Please subscribe to the = IRTF-Announce mailing list in order to receive
future = calls for ANRP nominations and join ISOC to stay informed of
other networking research initiatives:

   https://irtf.org/mailman/listinfo/irtf-announce
   https://isoc.org/join

Regards,

Lars Eggert, IRTF Chair =            https://irtf.org/anrp
Mat Ford, Internet Society =         https://isoc.org/research/

2016 ANRP Selection Committee

Mark Allman, ICIR
Marcelo Bagnulo, UC3M
Lou Berger, LabN
KC Claffy, CAIDA
Mark Crovella, Boston University
Lars Eggert, = NetApp
Stephen Farrell, Trinity College Dublin
Nick Feamster, Princeton
Mat Ford, ISOC
Lisandro Granville, UFRGS
Volker Hilt, Bell = Labs
Suresh Krishnan, Ericsson
Al Morton, = AT&T Laboratories
J=C3=B6rg Ott, Aalto University
Colin Perkins, University of Glasgow
Aiko Pras, = University of Twente
J=C3=BCrgen Sch=C3=B6nw=C3=A4lder, = Jacobs University Bremen
Joe Touch, USC/ISI
Rolf Winter, Hochschule Augsburg
Lixia Zhang, = UCLA


= --Apple-Mail=_F2FC46AB-EAAE-4E7F-B319-6380C95A36F0-- From stephan.bosch@dovecot.fi Mon Apr 4 13:23:09 2016 Return-Path: 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 0FA0012D111 for ; Mon, 4 Apr 2016 13:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Xm1uoGk_wTDl for ; Mon, 4 Apr 2016 13:23:06 -0700 (PDT) Received: from wursti.dovecot.fi (wursti.dovecot.fi [87.106.245.223]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7F12D0EE for ; Mon, 4 Apr 2016 13:23:06 -0700 (PDT) Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by wursti.dovecot.fi (Postfix) with ESMTPSA id DB7C5201EA for ; Mon, 4 Apr 2016 22:23:04 +0200 (CEST) From: Stephan Bosch To: IETF Apps Discuss References: <20160404194931.15658.52837.idtracker@ietfa.amsl.com> Message-ID: <5702CD0C.9010204@dovecot.fi> Date: Mon, 4 Apr 2016 22:22:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160404194931.15658.52837.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------020400010400050301090406" Archived-At: Subject: [apps-discuss] SPECIAL-USE (RFC 6154) in Sieve (RFC 5228): draft-bosch-sieve-special-use-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:30:12 -0000 This is a multi-part message in MIME format. --------------020400010400050301090406 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Currently, the Sieve language (RFC 5228) lacks the means of freely accessing the IMAP special-use mailbox attributes (RFC 6154). For example, it would be nice to be able to determine what the Junk mailbox is during Sieve processing at delivery, based on which mailbox has the "\Junk" special-use attribute assigned. I created a draft specification that adds this functionality. I posted this before on the IETF Sieve mailing list (affiliation updated). A few people expressed their interest there already. I was told that the apps-discuss mailing list is still the best venue for putting this document forward. Now that the draft submission is reopened, I have submitted it. The announcement of the submission is attached. Please tell me what you think. Regards, Stephan. --------------020400010400050301090406 Content-Type: message/rfc822; name="New Version Notification for draft-bosch-sieve-special-use-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-bosch-sieve-special-use-0"; filename*1="0_txt.eml" Return-Path: Delivered-To: stephan@dovecot.fi Received: from wursti.dovecot.fi by wursti.dovecot.fi (Dovecot) with LMTP id lJQzOE/FAldtIgAAvAUe3g for ; Mon, 04 Apr 2016 21:49:35 +0200 Received: from wursti.dovecot.fi (localhost.localdomain [127.0.0.1]) by wursti.dovecot.fi (Postfix) with ESMTP id 9A0AB20258 for ; Mon, 4 Apr 2016 21:49:33 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on wursti.dovecot.fi X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by wursti.dovecot.fi (Postfix) with ESMTPS for ; Mon, 4 Apr 2016 21:49:33 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5AF12D84F for ; Mon, 4 Apr 2016 12:49:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Stephan Bosch" Subject: New Version Notification for draft-bosch-sieve-special-use-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404194931.15658.52837.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 12:49:31 -0700 A new version of I-D, draft-bosch-sieve-special-use-00.txt has been successfully submitted by Stephan Bosch and posted to the IETF repository. Name: draft-bosch-sieve-special-use Revision: 00 Title: Sieve Email Filtering: Delivering to Special-Use Mailboxes Document date: 2016-04-04 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-bosch-sieve-special-use-00.txt Status: https://datatracker.ietf.org/doc/draft-bosch-sieve-special-use/ Htmlized: https://tools.ietf.org/html/draft-bosch-sieve-special-use-00 Abstract: The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned. 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. The IETF Secretariat --------------020400010400050301090406-- From nobody Mon Apr 11 20:32:37 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3CC12E027; Mon, 11 Apr 2016 20:32:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412033235.13019.93101.idtracker@ietfa.amsl.com> Date: Mon, 11 Apr 2016 20:32:35 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 03:32:35 -0000 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 of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-06.txt Pages : 20 Date : 2016-04-11 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 . 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 12 12:30:08 2016 Return-Path: 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 5F27512D09E; Tue, 12 Apr 2016 12:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 C2yAA4N2bto0; Tue, 12 Apr 2016 12:30:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E592A12DDB8; Tue, 12 Apr 2016 12:29:40 -0700 (PDT) Received: from [192.168.11.172] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3CJTbC2007207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 Apr 2016 12:29:38 -0700 From: Dave Crocker X-Priority: 2 (High) To: draft-ietf-appsawg-file-scheme@ietf.org Organization: Brandenburg InternetWorking Message-ID: <570D4C99.1030405@dcrocker.net> Date: Tue, 12 Apr 2016 12:29:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 12 Apr 2016 12:29:40 -0700 (PDT) Archived-At: Cc: art-ads@ietf.org, Apps Discuss Subject: [apps-discuss] Review of draft-ietf-appsawg-file-scheme X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 19:30:07 -0000 Review of: The file URI Scheme I-D: draft-ietf-appsawg-file-scheme-05 (I see that a -06 version was released today. Based on a quick scan of differences from the -05 version, I do not see their affecting the review.) Reviewer: D. Crocker Date: 12 April 2016 This review was performed in my role as document shepherd. The review was originally written last November but unfortunately I lost track of it and apologize for the delay. I should also comment that I've just consulted a number of others who have been involved in discussions about the draft and hope that they will response to this review, on the mailing list. Summary: The specification seeks to detail the file: URI scheme, which "identifies a file on a particular file system", and replaces RFC 1738. The document has been housed within the Apps Area WG, but has received little substantive comment -- somewhere in the range of 5-8 people, with small bursts of activity. Although at least some have tended to be supportive, there have been notable exceptions. Worse, significant issues that were raised were not obviously resolved on the list. (I looked at postings by others, immediately after the author's postings, to see whether there were statements of agreement that an issue had been resolved, and did not generally see them, concerning those substantive issues.) The draft began as an individual effort, in June 2013, went through many revisions, and was adopted by AppsAWG in January 2015, and has had a number of revisions. I note a 9/26/2014 (pre-AppsAWG) comment from Daniel Stenberg: "I would rather have a new spec straighten up and tighten the language somewhat so that we can get a stricter interpretation of how a file:// is supposed to work." which, in spite of the many document revisions, unfortunately matches my own assessment of the current draft. I also note a 9/15/2015 (post-AppsAWG adoption) comment from Mark Nottingham, on behalf of the W3C TAG: Regarding the use of `file://` URIs on the web, there are a few issues that need to be resolved for interoperability: 1. How does `file://` fit into the web's origin model? 2. How does retrieval of `file://` URIs fit into [Fetch](https://fetch.spec.whatwg.org/) and/or the [URL standard](https://url.spec.whatwg.org)? This document does not address any of these issues, so we encourage the APPSAWG to consider addressing these. One point of process discussion about the draft was to distinguish between documenting current practice, versus specifying enhancements. Another was to distinguish between use of the construct locally (within a user's own system) versus globally, across the public Web. Again, neither matter appears to be resolved clearly within the draft, and I can't tell tell clearly which goals the draft targets, even with the Abstract text: "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." These two goals entail a classic choice in development of a specification that deals with existing practice. Clarity between the two goals and careful precision about which is being served, is essential. 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. In technical terms, document seems to suffer some confusion about its role as a format specification, versus as a protocol specification. I believe this issue is basic and important. It needs to be resolved. For a specification involving such a potentially and presumably important capability, I think significant community support should be required... unless the spec is to be offered as Experimental, which is the most I'm inclined to recommend at this point... Details: > Applications Area Working Group M. Kerwin > Internet-Draft QUT > Obsoletes: 1738 (if approved) December 1, 2015 I believe it merely updates it. It essentially replaces only Section 3.10 of that RFC. > Intended status: Standards Track > Expires: June 3, 2016 > > > The file URI Scheme > draft-ietf-appsawg-file-scheme-05 > > 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 attempts to define -> defines also: common core of what? I think the answer is a common core of object storage naming convention, but whatever is correct, it should be made explicit here. > across the broad spectrum of existing implementations, while at the > same time documenting other current practices. implementations of ... URI-based file system accessing mechanisms? > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area Working > Group discussion list . > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on June 3, 2016. > > Copyright Notice > > Copyright (c) 2015 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > > > > Kerwin Expires June 3, 2016 [Page 1] > > Internet-Draft file-scheme December 2015 > > > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.2. Similar Technologies . . . . . . . . . . . . . . . . . . 3 > 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 4 > 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Operations on file URIs . . . . . . . . . . . . . . . . . . . 5 > 3.1. Translating Local File Path to file URI . . . . . . . . . 5 > 3.2. Translating Non-local File Path to file URI . . . . . . . 6 > 3.3. Incompatible File Paths . . . . . . . . . . . . . . . . . 7 > 3.3.1. Win32 Namespaces . . . . . . . . . . . . . . . . . . 7 > 4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Origins . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 > 9.2. Informative References . . . . . . . . . . . . . . . . . 10 > Appendix A. Example URIs . . . . . . . . . . . . . . . . . . . . 12 > Appendix B. System-specific Operations . . . . . . . . . . . . . 12 > B.1. POSIX Systems . . . . . . . . . . . . . . . . . . . . . . 12 > B.2. DOS- and Windows-Like Systems . . . . . . . . . . . . . . 12 > B.3. Mac OS X Systems . . . . . . . . . . . . . . . . . . . . 13 > B.4. OpenVMS Files-11 Systems . . . . . . . . . . . . . . . . 13 > Appendix C. Nonstandard Syntax Variations . . . . . . . . . . . 13 > C.1. DOS and Windows Drive Letters . . . . . . . . . . . . . . 13 > C.1.1. Relative Paths . . . . . . . . . . . . . . . . . . . 14 > C.1.2. Vertical Bar Character . . . . . . . . . . . . . . . 14 > C.2. UNC Strings . . . . . . . . . . . . . . . . . . . . . . . 15 > C.3. UNC Paths . . . . . . . . . . . . . . . . . . . . . . . . 15 > C.4. Backslash as Separator . . . . . . . . . . . . . . . . . 16 > Appendix D. Example of IRI vs Percent-Encoded URI . . . . . . . 17 > Appendix E. UNC Syntax . . . . . . . . . . . . . . . . . . . . . 18 > Appendix F. Collected Rules . . . . . . . . . . . . . . . . . . 19 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 > > > > > > > Kerwin Expires June 3, 2016 [Page 2] > > Internet-Draft file-scheme December 2015 > > > 1. Introduction > > A file URI identifies a file on a particular file system. It can be > used in discussions about the file, and if other conditions are met > it can be dereferenced to directly access the file. Since this is a specification, and it has intended for wide use, there should be some sort of basic definition of what a file system is. Nothing fancy. And by way of priming the pump: ...on a particular file system, which is an object stored in a structured naming-and-accessing environment on a host. The URI can be used... > > The file URI scheme is not coupled with a specific protocol, nor with > a specific media type. See Section 3 for a discussion of operations > that can be performed on a file URI. I think these defined operations are not really performed 'on' the file URI, but rather are used to create or apply the URI. Also: media type. -> media type [rfc6838]. > This document defines a syntax that is compatible with most extant > implementations, while attempting to push towards a stricter subset > of "ideal" constructs. In many cases it simultaneously acknowledges > and deprecates some less common or outdated constructs. *** ideal? How does it 'acknowledge' such constructs? > > 1.1. History > > The file URI scheme was first defined in [RFC1630], which, being an > informational RFC, does not specify an Internet standard. The My personal preference is for documents to refrain from referring to their standards status or the status of other documents. "Status" is an ephemeral attribute that should be external to the details of a specification, IMO. That is, make the discussion be in terms of the technical and operational issues, not the standards status. > definition was standardised in [RFC1738], and the scheme was > registered with the Internet Assigned Numbers Authority (IANA); IANA registration is a side-effect of the specs and typically isn't called out this way, I believe. > however that definition omitted certain language included by the > former that clarified aspects such as: ... by former that... missing word? > > o the use of slashes to denote boundaries between directory levels > of a hierarchical file system; and > > o the requirement that client software convert the file URI into a > file name in the local file name conventions. *** Hmmm. A requirement like that moves this from being a URI specification to being a file protocol specification... > > The Internet draft [I-D.hoffman-file-uri] was written in an effort to > keep the file URI scheme on standards track when [RFC1738] was made > obsolete, but that draft expired in 2005. It enumerated concerns > arising from the various, often conflicting implementations of the > scheme. It serves as the spiritual predecessor of this document. > > Additionally the WHATWG defines a living URL standard [WHATWG-URL], > which includes algorithms for interpreting file URIs (as URLs). How does it relate to the current draft? At the least, doesn't it instead belong in the next 'Similar Technologies' section? > > 1.2. Similar Technologies > > The Universal Naming Convention (UNC) [MS-DTYP] defines a string > format that can perform a similar role to the file URI scheme in > describing the location of files. A UNC filespace selector string > has three parts: host, share, and path; see Appendix E. This > document describes but does not specify a means of translating > between UNC filespace selector strings and file URIs in Appendix C.2. "describes but does not specify" seems an odd distinction. Not exactly sure what it means. > > > > Kerwin Expires June 3, 2016 [Page 3] > > Internet-Draft file-scheme December 2015 > > > 1.3. Notational Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > Throughout this document the term "local" is used to describe files > that can be accessed directly through the local file system. It is > important to note that a local file may not be physically located on > the local machine, for example if a networked file system is > transparently mounted into the local file system. I'm not exactly sure what 'accessed directly' means, in the modern world of file systems. Unfortunately, this is cast as a major point of concern in the document. How is 'directly' different from 'no authority value is specified'? > 2. Syntax > > The file URI syntax is defined here in Augmented Backus-Naur Form > (ABNF) [RFC5234], including the core ABNF syntax rule "ALPHA" defined > by that specification, and importing the "userinfo", "host" and > "path-absolute" rules from [RFC3986] (as updated by [RFC6874].) Possibly cleaner: [RFC5234]. Imported rules: From [RFC5234]: ALPHA From [RFC3986], [RFC6874]: userinfo, host, authority, path-absolute > The core syntax in [RFC3986] includes "path" and "authority" > components, for each of which only a subset is used in the definition > of the file URI scheme. The relevant subset of "path" is "path- > absolute", and the subset of "authority" is "file-auth", given below. > > Please note Appendix C that lists some other commonly seen but > nonstandard variations. > > file-URI = file-scheme ":" file-hier-part > > file-scheme = "file" > > file-hier-part = "//" auth-path > / local-path > > auth-path = [ file-auth ] path-absolute > > local-path = path-absolute > > file-auth = [ userinfo "@" ] host Syntax problem: If auth-path has no file-auth, since it's optional, then both the auth-path and local-path of file-hier-part reduce to path-absolute. Methinks that's creates a parsing ambiguity? Hmmm. I'm also not sure whether stylistic nuance and exact compatibility with the meta-specification documents this is based on are worth worrying about, but... I believe this could derive more smoothly from section 3 of RFC3986, with something like: URI = scheme ":" hier-part ; from RFC 3986 scheme = "file" hier-part = "//" ( authority / local-path ) (The parens are to make the binding of the alternatives visually unambiguous. Relying on formal, implicit binding rules can create tricky usability errors. The hier-part rule in RFC 3986 might be an example: Concatenation is has tighter binding than alternatives, in ABNF, but the labeling in RFC3986 could imply a different parsing. Presumably the authors of RFC 3986 got the BNF correct, but I'm guessing a random reader could easily get it wrong... ) > The syntax definition above is different from those given in > [RFC1630] and [RFC1738] as it is derived from the generic syntax of > [RFC3986], which post-dates all previous specifications. all previous -> the previous file URI > As a special case, the "file-auth" rule can match the string > "localhost" or the empty string; either value is interpreted as "the > machine from which the URI is being interpreted," exactly as if no > authority was present. To maximise compatibility with previous 'as if no authority" was present.' Probably should be 'were' present, but more significantly 'authority' is not defined. This is a reason to re-use the ABNF rulenames from RFC 3986, when you are importing them, but modify the portion to suit the file scheme. (Note that Ned Freed offers extended discussion about this, including going down a different line of resolution on this issue, in his 2 November 1:42pm posting. However the issue here is resolved, the main point is that the text needs to be consistent and clear in its language. It seems that the current text does not fully resolve the points he raised.) Since file-auth is shown as optional, that handles the empty string already and doesn't need a comment. Offhand, I wonder whether the details of the "As special case" paragraph can (and should) instead be reflected directly in the ABNF? > Kerwin Expires June 3, 2016 [Page 4] > > Internet-Draft file-scheme December 2015 > > > specifications, implementations MAY choose to include an empty "file- > auth". > > Systems exhibit different levels of case-sensitivity. Unless the > file system is known to be case-insensitive, implementations MUST > maintain the case of file and directory names when translating file > URIs to and from the local system's representation of file paths, and > any systems or devices that transport file URIs MUST NOT alter the > case of file URIs they transport. This is protocol language, not URI format/semantics language. I believe that the needs of this spec are served by something along the lines of: Some systems have case-sensitive file naming and some do not. Hence the file scheme supports case sensitivity, in order to retain the case as given. Any transport-related handling of the file URI scheme MUST retain the case as given. Any mapping to or from a case-insensitive form is soley the responsibility of the implementation processing the file URI on behalf of the referenced file system. > > 3. Operations on file URIs Use of normative language in this section is inappropriate. It does not provide protocol details and provides essentially no semantics. > Implementations that provide dereferencing ooperations on file URIs ooperations -> operations > SHOULD, at a minimum, provide a read-like operation to return the > contents of a file located by a file URI. Additional operations MAY > be provided, such as writing to, creating, and deleting files. See > the POSIX file and directory operations [POSIX] for examples of > standardized operations that can be performed on files. What is the practical benefit of giving the reader superficial tutorial information about file system operations? > File URIs can also be translated to and from other, similar > constructs, such as local file paths or UNC strings. I don't know what this means. And how is this sentence useful? > A file URI can be dependably dereferenced or translated to a local > file path only if it is local. A file URI is considered "local" if > it has a blank or no authority, or the authority is the special > string "localhost". > > This specification neither defines nor forbids a mechanism for > accessing non-local files. See SMB [MS-SMB], NFS [RFC7530], NCP > [NOVELL] for examples of protocols that can be used to access files > over a network. Also see Appendix C.2 for a discussion on > translating non-local file URIs to and from UNC stings. > > 3.1. Translating Local File Path to file URI > > Below is an algorithmic description of the process used to convert a > file path to a URI; see Section 4. > > 1. Resolve the file path to its fully qualified absolute form. What does this mean? Where is it defined? > > 2. Initialise the URI with the "file:" scheme identifier. > > 3. If including an empty authority field, append the "//" sigil to > the URI. sigil ??? pretty stylized vocabulary... What about the alternative of including a /non-empty/ authority field? > 4. Append a slash character "/" to the URI, to signify the path > root.> > 5. For each directory in the path after the root: > > 1. Transform the directory name to a path segment ([RFC3986], > Section 3.3) as per Section 2 of [RFC3986]. I think that Section 2 does not specify how to do a transform, although yes, it does make reference to doing one. Rather, it specifies encoding rules. The details of how to do a transform are left to the implementer. Hence I believe the above should be something like: 1. Transform the directory name to a path segment (RFC3986], Section 3.3]) to conform to the encoding rules of Section 2 of [RFC3986]. The specific rules for mapping between a file system name and a file scheme URI are outside the scope of this specification. > 2. Append the transformed segment and a delimiting slash > character "/" to the URI. > > 6. If the path includes a file name: > > 1. Transform the file name to a path segment as above. > > 2. Append the transformed segment to the URI. A slash is required at the end of a directory, even if there is no file name? > Differences from RFC 1738 Seems like this belongs elsewhere in the document, like maybe an appendix. It is irrelevant except as an historical note. > In [RFC1738] a file URL always started with the token "file://", > followed by an (optionally blank) authority and a "/". That "/" was > not considered part of the path. This implies that the correct > encoding for a file path in a UNIX-like environment would have been: > > token + authority + slash + path > = "file://" + "" + "/" + "/path/to/file.txt" > = "file:////path/to/file.txt" > > However that construct was never observed in practice, and in fact > would have collided with the eventual encoding of UNC strings in URIs > described in Appendix C.3. > > 3.2. Translating Non-local File Path to file URI > > Translating a non-local file path, including a UNC string, to a file > URI follows the same basic algorithm as for local files, above, > except that the authority MUST refer to the network-accesible node > that hosts the file. accesible -> accessible > For example, in a clustered OpenVMS Files-11 system the authority > would contain the node name. Where the original node reference > includes a username and password in an access control string, they > MAY be transcribed into the userinfo field of the authority > ([RFC3986], Section 3.2.1), security considerations (Section 6) > notwithstanding. > > See Appendix C.2 for an explicit handling of UNC strings. > > > > > > > > Kerwin Expires June 3, 2016 [Page 6] > > Internet-Draft file-scheme December 2015 > > > 3.3. Incompatible File Paths > > Some conventional file path formats are known to be incompatible with > the file URI scheme. > > 3.3.1. Win32 Namespaces > > The Microsoft Windows API defines Win32 Namespaces [Win32-Namespaces] > for interacting with files and devices using Windows API functions. > These namespaced paths are prefixed by "\\?\" for Win32 File > Namespaces and "\\.\" for Win32 Device Namespaces. There is also a > special case for UNC file paths in Win32 File Namespaces, referred to > as "Long UNC", using the prefix "\\?\UNC\". > > This specification does not define a mechanism for translating > namespaced paths to or from file URIs. No it doesn't, although it contains some language that almost seems to. The language needs to be removed, in favor of the above simple sentence. Further, language about 'incompatibility' is a commentary that belongs in the Introduction or some other place outside the main spec. It's an important discussion point, but it's not part of the spec. > > 4. Encoding > > To avoid ambiguity, a file URI SHOULD be transported as an > Internationalized Resource Identifier (IRI) [RFC3987], or as a URI > with non-ASCII characters encoded according to the UTF-8 character > encoding [STD63] and percent-encoded as needed ([RFC3986], > Section 2.5). > > The encoding of a file URI depends on the file system that stores the I'm not sure this sentence is correct. It's a natural assumption but arguably one can lay any encoding convention on top of any data store. > identified file. If the file system uses a known non-Unicode > character encoding, the path SHOULD be converted to a sequence of > characters from the Universal Character Set [ISO10646] normalized > according to Normalization Form C (NFC) [UTR15], before being > translated to a file URI, and conversely a file URI SHOULD be > converted back to the file system's native encoding when > dereferencing or translating to a file path. > > Note that many modern file systems encode directory and file names > as arbitrary sequences of octets. In those cases, the > representation as an encoded string often depends on the user's > localization settings, or defaults to UTF-8 [STD63]. > > When the file system's encoding is not known the file URI SHOULD be > transported as an Internationalized Resource Identifier (IRI) > [RFC3987] to avoid ambiguity. See Appendix D for examples. I'm inclined to think that this section either needs to be far more complete -- and I'm not recommending it do that -- or it merely needs to caution implementers to make sure that file scheme URI storage needs to be idempotent with the original, interoperable form. > > 5. Origins > > As per [RFC6454], Section 4, when determining the origin of a file > URI implementations MAY return an implementation-defined value. Now we are back to protocol, rather than basic representation. But it seems minimal in detail and utility. > > > > Kerwin Expires June 3, 2016 [Page 7] > > Internet-Draft file-scheme December 2015 > > > Historically, user agents have granted content from the file URI > scheme a tremendous amount of privilege. However, granting all local > files such wide privileges can lead to privilege escalation attacks. > Some user agents have had success granting local files directory- > based privileges, but this approach has not been widely adopted. > Other user agents use globally unique identifiers for each file URI, > which is the most secure option. This paragraph belongs in the next, Security Considerations section. Without the protocol-ish paragraph before it. > > 6. Security Considerations > > There are many security considerations for URI schemes discussed in > [RFC3986]. > > File access and the granting of privileges for specific operations > are complex topics, and the use of file URIs can complicate the > security model in effect for file privileges. Software using file > URIs MUST NOT grant greater access than would be available for other > file access methods. This sort of normative statement has no real meaning, and certainly none without explanation. At base, the reader cannot tell was satisfies the normative statement and what does not. > File systems typically assign an operational meaning to special > characters, such as the "/", "\", ":", "[", and "]" characters, and > to special device names like ".", "..", "...", "aux", "lpt", etc. In > some cases, merely testing for the existence of such a name will > cause the operating system to pause or invoke unrelated system calls, > leading to significant security concerns regarding denial of service > and unintended data transfer. It would be impossible for this > specification to list all such significant characters and device > names. Implementers MUST research the reserved names and characters > for the types of storage device that may be attached to their > application and restrict the use of data obtained from URI components > accordingly. > > Additionally, as discussed in the HP OpenVMS Systems Documentation > > "access control strings include sufficient information to allow > someone to break in to the remote account, [therefore] they create > serious security exposure." In a similar vein, the presence of a > password in a "user:password" userinfo field is deprecated by > [RFC3986]. As such, the userinfo field of a file URI, if present, > MUST NOT contain a password. Is there really no stable, published document that says something similar? > 7. IANA Considerations > > This document defines the following URI scheme, so the "Permanent URI > Schemes" registry has been updated accordingly. This registration > complies with [BCP35]. > > Scheme name: > > > > Kerwin Expires June 3, 2016 [Page 8] > > Internet-Draft file-scheme December 2015 > > > file > > Status: > permanent > > Applications/protocols that use this scheme name: > Commonly used in hypertext documents to refer to files without > depending on network access. Supported by major browsers. > > Windows API (PathCreateFromUrl, UrlCreateFromPath). > > Perl LWP. > > Contact: > Matthew Kerwin > > Change Controller: > This scheme is registered under the IETF tree. As such, the IETF > maintains change control. > > 8. Acknowledgements > > This specification is derived from [RFC1738], [RFC3986], and > [I-D.hoffman-file-uri] (expired); the acknowledgements in those > documents still apply. > > Additional thanks to Dave Risney, author of the informative IE Blog > article windows.aspx>, and Dave Thaler for their comments and suggestions. > > 9. References > > 9.1. Normative References > > [BCP35] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines > and Registration Procedures for URI Schemes", BCP 35, > RFC 7595, DOI 10.17487/RFC7595, June 2015, > . > > [ISO10646] > International Organization for Standardization, > "Information Technology - Universal Multiple-Octet Coded > Character Set (UCS)", ISO/IEC 10646:2003, December 2003. > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, > November 1987, . > > > > > Kerwin Expires June 3, 2016 [Page 9] > > Internet-Draft file-scheme December 2015 > > > [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - > Application and Support", STD 3, RFC 1123, > DOI 10.17487/RFC1123, October 1989, > . > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . > > [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifier (URI): Generic Syntax", STD 66, > RFC 3986, DOI 10.17487/RFC3986, January 2005, > . > > [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource > Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, > January 2005, . > > [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 4291, DOI 10.17487/RFC4291, February > 2006, . > > [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", STD 68, RFC 5234, > DOI 10.17487/RFC5234, January 2008, > . > > [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing > IPv6 Zone Identifiers in Address Literals and Uniform > Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, > February 2013, . > > [UTR15] Davis, M. and K. Whistler, "Unicode Normalization Forms", > August 2012, > . > > 9.2. Informative References > > [Bug107540] > Bugzilla@Mozilla, "Bug 107540", October 2007, > . > > [I-D.hoffman-file-uri] > Hoffman, P., "The file URI Scheme", draft-hoffman-file- > uri-03 (work in progress), January 2005. > > > > > > Kerwin Expires June 3, 2016 [Page 10] > > Internet-Draft file-scheme December 2015 > > > [MS-DTYP] Microsoft Open Specifications, "Windows Data Types, 2.2.56 > UNC", January 2013, > . > > [MS-NBTE] Microsoft Open Specifications, "NetBIOS over TCP (NBT) > Extensions", May 2014, > . > > [MS-SMB] Microsoft Open Specifications, "Server Message Block (SMB) > Protocol", January 2013, > . > > [NOVELL] Novell, "NetWare Core Protocols", 2013, > netware_core_protocols.html>. > > [POSIX] IEEE, "IEEE Std 1003.1, 2013 Edition", 2013. > > [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A > Unifying Syntax for the Expression of Names and Addresses > of Objects on the Network as used in the World-Wide Web", > RFC 1630, DOI 10.17487/RFC1630, June 1994, > . > > [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform > Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, > December 1994, . > > [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, > DOI 10.17487/RFC6454, December 2011, > . > > [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System > (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, > March 2015, . > > [STD63] Yergeau, F., "UTF-8, a transformation format of ISO > 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November > 2003, . > > [WHATWG-URL] > WHATWG, "URL Living Standard", May 2013, > . > > [Win32-Namespaces] > Microsoft Developer Network, "Naming Files, Paths, and > Namespaces", June 2013, au/library/windows/desktop/aa365247(v=vs.85).aspx>. > > > > Kerwin Expires June 3, 2016 [Page 11] > > Internet-Draft file-scheme December 2015 > > > Appendix A. Example URIs > > The syntax in Section 2 is intended to support file URIs that take > the following forms: > > Local files: > > o A traditional file URI for a local file, with an empty authority. > This is the most common format in use today. E.g.: > > * "file:///path/to/file" > > o The minimal representation of a local file, with no authority > field and an absolute path that begins with a slash "/". E.g.: > > * "file:/path/to/file" > > Non-local files: > > o A non-local file, with an explicit authority. E.g.: > > * "file://host.example.com/path/to/file" > > Appendix B. System-specific Operations > > This appendix is not normative; it highlights some observed > behaviours and provides system-specific guidance for interacting with > file URIs and paths. > > B.1. POSIX Systems > > There is little to say about POSIX file systems; the file URI > structure already closely resembles POSIX file paths. > > B.2. DOS- and Windows-Like Systems > > When mapping a DOS- or Windows-like file path to a file URI, > implementations typically map the drive letter (e.g. "c:") into the > first path segment. > > See Appendix C.1 for explicit (but non-normative and strictly > optional) rules for interacting with DOS- or Windows-like file paths > and URIs. > > > > > > > > > Kerwin Expires June 3, 2016 [Page 12] > > Internet-Draft file-scheme December 2015 > > > B.3. Mac OS X Systems > > The HFS+ file system uses a non-standard normalization form, similar > to Normalization Form D. Take care when transforming HFS+ file paths > to and from URIs using Normalization Form C Section 4. > > B.4. OpenVMS Files-11 Systems > > When mapping a VMS file path to a file URI, map the device name into > the first path segment. Note that the dollars sign "$" is a reserved > character per the definition in [RFC3986], Section 2.2, so should be > percent-encoded if present in the device name. > > If the VMS file path includes a node reference, use that as the > authority. Where the original node reference includes a username and > password in an access control string, they can be transcribed into > the userinfo field of the authority ([RFC3986], Section 3.2.1), > security considerations (Section 6) notwithstanding. > > Appendix C. Nonstandard Syntax Variations > > These variations may be encountered for historical reasons, but are > not supported by the normative syntax of Section 2. > > This appendix is not normative. > > C.1. DOS and Windows Drive Letters > > On Windows- or DOS-based file systems a absolute file path can begin > with a drive letter. To facilitate this, the "local-path" rule in > Section 2 can be replaced with the following: > > local-path = [ drive-letter ] path-absolute > > drive-letter = ALPHA ":" > > This is intended to support the minimal representation of a local > file in a DOS- or Windows-based environment, with no authority field > and an absolute path that begins with a drive letter. E.g.: > > o "file:c:/path/to/file" > > URIs of the form "file:///c:/path/to/file" are already supported by > the "path-absolute" rule. > > Note that comparison of drive letters in DOS or Windows file paths is > case-insensitive. Some implementations therefore canonicalize drive > letters in file URIs by converting them to uppercase. > > > > Kerwin Expires June 3, 2016 [Page 13] > > Internet-Draft file-scheme December 2015 > > > C.1.1. Relative Paths > > In DOS- or Windows-based file systems, relative paths beginning with > a slash "/" should be resolved relative to the drive letter, and > resolution of ".." dot segments (per Section 5.2.4 of [RFC3986]) > should not ever overwrite the drive letter. > > e.g.: > > base: file:///c:/path/to/file.txt > rel. URI: /some/other/thing.bmp > resolved: file:///c:/some/other/thing.bmp > > base: file:///c:/foo.txt > rel. URI: ../../bar.txt > resolved: file:///c:/bar.txt > > Relative paths with a drive letter followed by a character other than > a slash (e.g. "c:bar/baz.txt" or "c:../foo.txt") should not be > accepted as dereferenceable URIs in DOS or Windows systems. > > C.1.2. Vertical Bar Character > > Historically some implementations have used a vertical line character > "|" instead of a colon ":" in the drive letter construct. [RFC3986] > forbids the use of the vertical line, however it may be necessary to > interpret or update old URIs. > > For interpreting such URIs, the "auth-path" and "local-path" rules in > Section 2 and the "drive-letter" rule above are replaced with the > following: > > auth-path = [ file-auth ] path-absolute > / [ file-auth ] file-absolute > > local-path = [ drive-letter ] path-absolute > / file-absolute > > file-absolute = "/" drive-letter path-absolute > > drive-letter = ALPHA ":" > / ALPHA "|" > > This is intended to support regular DOS or Windows file URIs with > vertical line characters in the drive letter construct. E.g.: > > o "file:///c|/path/to/file" > > > > > Kerwin Expires June 3, 2016 [Page 14] > > Internet-Draft file-scheme December 2015 > > > o "file:/c|/path/to/file" > > o "file:c|/path/to/file" > > To update such an old URI, replace the vertical line "|" with a colon > ":". > > C.2. UNC Strings > > A UNC filespace selector string can be directly translated to a URI; > see Section 4. The following is an algorithmic description of the > process of translating a UNC string to a file URI: > > 1. Initialise the URI with the "file:" scheme identifier. > > 2. Append the authority: > > 1. Append the "//" authority sigil to the URI. > > 2. Append the hostname field of the UNC string to the URI. > > 3. Append the sharename: > > 1. Transform the sharename to a path segment ([RFC3986], > Section 3.3) as per Section 2 of [RFC3986]. > > 2. Append a delimiting slash character "/" and the transformed > segment to the URI. > > 4. For each objectname: > > 1. Transform the objectname to a path segment ([RFC3986], > Section 3.3) as per Section 2 of [RFC3986]. > > 2. Append a delimiting slash character "/" and the transformed > segment to the URI. > > Example: > > UNC String: \\host.example.com\Share\path\to\file.txt > URI: file://host.example.com/Share/path/to/file.txt > > C.3. UNC Paths > > It is common to encounter file URIs that encode entire UNC strings in > the path, usually with all backslash "\" characters replaced with > slashes "/". > > > > > Kerwin Expires June 3, 2016 [Page 15] > > Internet-Draft file-scheme December 2015 > > > To interpret such URIs, the "auth-path" rule in Section 2 is replaced > with the following: > > auth-path = [ file-auth ] path-absolute > / unc-authority path-absolute > > unc-authority = 2*3"/" [ userinfo "@" ] file-host > > file-host = inline-IP / IPv4address / reg-name > > inline-IP = "%5B" ( IPv6address / IPvFuture ) "%5D" > > This syntax uses the "userinfo", "IPv4address, "IPv6address", > "IPvFuture", and "reg-name` rules from [RFC3986]. > > Note that the "file-host" rule is the same as "host" but with > percent-encoding applied to "[" and "]" characters. > > This extended syntax is intended to support URIs that take the > following forms, in addition to those in Appendix A: > > Non-local files: > > o The "traditional" representation of a non-local file, with an > empty authority and a complete (transformed) UNC string in the > path. E.g.: > > * "file:////host.example.com/path/to/file" > > o As above, with an extra slash between the empty authority and the > transformed UNC string, conformant with the definition from > [RFC1738]. E.g.: > > * "file://///host.example.com/path/to/file" > > This representation is notably used by the Firefox web browser. > See Bugzilla#107540 [Bug107540]. > > It also further limits the set of file URIs that can be translated to > a local file path to those with a path that does not encode a UNC > string. > > C.4. Backslash as Separator > > Historically some implementations have copied entire file paths into > the path components of file URIs. Where DOS or Windows file paths > were copied thus, resulting URI strings contained unencoded backslash > "\" characters, which are forbidden by both [RFC1738] and [RFC3986]. > > > > Kerwin Expires June 3, 2016 [Page 16] > > Internet-Draft file-scheme December 2015 > > > It may be possible to translate or update such an invalid file URI by > replacing all backslashes "\" with slashes "/", if it can be > determined with reasonable certainty that the backslashes are > intended as path separators. > > Appendix D. Example of IRI vs Percent-Encoded URI > > The following examples demonstrate the advantage of encoding file > URIs as IRIs to avoid ambiguity (see Section 4). > > Example: file IRI: > > | Bytes of file IRI in a UTF-8 document: > | 66 69 6c 65 3a 43 3a 2f 72 65 c3 a7 75 2e 74 78 74 > | f i l e : c : / r e ( c ) u . t x t > | > | Interpretation: > | A file named "recu.txt" with a cedilla on the "c", in the > | directory "C:\" of a DOS or Windows file system. > | > | Character value sequences of file paths, for various file system > | encodings: > | > | o UTF-16 (e.g. NTFS): > | 0043 003a 005c 0072 0065 00e7 0075 002e 0074 0078 0074 > | > | o Codepage 437 (e.g. MS-DOS): > | 43 3a 5c 72 65 87 75 2e 74 78 74 > > Counter-example: ambiguous file URI: > > > > > > > > > > > > > > > > > > > > > > Kerwin Expires June 3, 2016 [Page 17] > > Internet-Draft file-scheme December 2015 > > > | Percent-encoded file URI, in any ASCII-compatible document: > | "file:///%E3%81%A1" > | > | Possible interpretations of the file name, depending on the > | encoding of the file system: > | > | o UTF-8: > | > | > | o Codepage 437: > | + > | + > | > | > | o EBCDIC: > | "Ta~" > | > | etc. > > Appendix E. UNC Syntax > > The UNC filespace selector string is a null-terminated sequence of > characters from the Universal Character Set [ISO10646]. > > The syntax of a UNC filespace selector string, as defined by > [MS-DTYP], is given here in Augmented Backus-Naur Form (ABNF) > [RFC5234] for convenience. Note that this definition is informative > only; the normative description is in [MS-DTYP]. > > UNC = "\\" hostname "\" sharename *( "\" objectname ) > hostname = netbios-name / fqdn / ip-address > sharename = > objectname = > > o "netbios-name" from [MS-NBTE], Section 2.2.1. > > o "fqdn" from [RFC1035] or [RFC1123] > > o "ip-address" from Section 2.1 of [RFC1123], or Section 2.2 of > [RFC4291]. > > The precise format of "sharename" depends on the protocol; see: SMB > [MS-SMB], NFS [RFC7530], NCP [NOVELL]. > > > > > > > > > Kerwin Expires June 3, 2016 [Page 18] > > Internet-Draft file-scheme December 2015 > > > Appendix F. Collected Rules > > Here are the collected syntax rules for all optional appendices, > presented for convenience. This collected syntax is not normative. > > file-URI = file-scheme ":" file-hier-part > > file-scheme = "file" > > file-hier-part = "//" auth-path > / local-path > > auth-path = [ file-auth ] path-absolute > / [ file-auth ] file-absolute > / unc-authority path-absolute > > local-path = [ drive-letter ] path-absolute > / file-absolute > > file-auth = [ userinfo "@" ] host > > unc-authority = 2*3"/" [ userinfo "@" ] file-host > > file-host = inline-IP / IPv4address / reg-name > > inline-IP = "%5B" ( IPv6address / IPvFuture ) "%5D" > > file-absolute = "/" drive-letter path-absolute > > drive-letter = ALPHA ":" > / ALPHA "|" > > This collected syntax is intended to support file URIs that take the > following forms: > > Local files: > > o A traditional file URI for a local file, with an empty authority. > E.g.: > > * "file:///path/to/file" > > o The minimal representation of a local file, with no authority > field and an absolute path that begins with a slash "/". E.g.: > > * "file:/path/to/file" > > > > > > Kerwin Expires June 3, 2016 [Page 19] > > Internet-Draft file-scheme December 2015 > > > o The minimal representation of a local file in a DOS- or Windows- > based environment, with no authority field and an absolute path > that begins with a drive letter. E.g.: > > * "file:c:/path/to/file" > > o Regular DOS or Windows file URIs, with vertical line characters in > the drive letter construct. E.g.: > > * "file:///c|/path/to/file" > > * "file:/c|/path/to/file" > > * "file:c|/path/to/file" > > Non-local files: > > o The representation of a non-local file, with an explicit > authority. E.g.: > > * "file://host.example.com/path/to/file" > > o The "traditional" representation of a non-local file, with an > empty authority and a complete (transformed) UNC string in the > path. E.g.: > > * "file:////host.example.com/path/to/file" > > o As above, with an extra slash between the empty authority and the > transformed UNC string. E.g.: > > * "file://///host.example.com/path/to/file" > > Author's Address > > Matthew Kerwin > Queensland University of Technology > Victoria Park Road > Kelvin Grove, QLD 4059 > Australia > > Email: matthew.kerwin@qut.edu.au > > > > > > > > > > Kerwin Expires June 3, 2016 [Page 20] -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Apr 12 16:09:09 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D134712E94F for ; Tue, 12 Apr 2016 16:09:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412230907.32202.15899.idtracker@ietfa.amsl.com> Date: Tue, 12 Apr 2016 16:09:07 -0700 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 23:09:08 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-http-problem", resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-file-scheme", set due date to May 2016 from December 2015. Changed milestone "Publication requested for draft-ietf-appsawg-mdn-3798bis", set due date to May 2016 from December 2015. URL: https://datatracker.ietf.org/wg/appsawg/charter/ From nobody Tue Apr 12 16:21:36 2016 Return-Path: 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 645B212E38E; Tue, 12 Apr 2016 16:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dhFKWisDfAoO; Tue, 12 Apr 2016 16:21:34 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F082C12E070; Tue, 12 Apr 2016 16:21:33 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id c4so46566948vkb.3; Tue, 12 Apr 2016 16:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1qx3tUB1joFSrc3LqldySyr+5YqKAHBOOpGhgfvybao=; b=uMroRhYIU8A0T+OoIGRfO/lbZFgfzdGOlH5lrd4FW9FPw7k/kfZ2a/xCBW4lz06EBS h01NkISQdEfRLBJuqAVtE/8yvlXR5r4nfrSU7vISOYW6clym4uZnpY+Ml0tFYKdcOHtD qEbXqBXHMvWF82NPDwZiiySz1RR854Lw7Y3JfTYMEZwk3uHtgXP1oeJZQ/nGK+2P5K+5 dvO8t1WFe6tgmc8s7fpjg76VzS/dCqTQh+XdxphgZNistSMJswLHdc7C4BjOXanT1IDj AbQKBUjySCY6F6FMF1kKWC8rbnsWCGWZ5p7s9teu7I5aNTDILrmVLYuGL11zIpTcSdh/ 1QfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1qx3tUB1joFSrc3LqldySyr+5YqKAHBOOpGhgfvybao=; b=e3FtIxWwZGs/joOGL2FfCh79dF7w1k+vnY5fMBXDT92lVQTrB51w+b13nzmI63uipL 17fupEs4wvUAviHGdkIZufKjxijIGFnEYLwFRTvYrNtDI3c6u1To9ikxGF6wWIC2DmSl enQD0wgomIMPF/bD1Vg5Ruc25HnyJTSkzHnTsQwZU3bLCnTLKTGxE8dZ3ag+kFLrMX+F d5Im2FHfOFp0eXINPn+HUccM9orIcm1urOQe/2hJ6MhXZDs8MceXUSM2F1J/dliKjmcm nTL1gMVOr209S9/9trLsisdLQQYqUB+rGqHXcfx5mSWAvu1bEq7hrMOOSrHkK5zbwCmb nNjg== X-Gm-Message-State: AOPr4FUXFWA1TvHdJUIFQ52hJBE7nBoRtStoCdjcIEjwyWLLwAvDba0MZQr3xxRoTCw9Kr6U75MsnMdRA+TbSA== MIME-Version: 1.0 X-Received: by 10.31.52.147 with SMTP id b141mr3085494vka.82.1460503293013; Tue, 12 Apr 2016 16:21:33 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Tue, 12 Apr 2016 16:21:32 -0700 (PDT) In-Reply-To: <570D4C99.1030405@dcrocker.net> References: <570D4C99.1030405@dcrocker.net> Date: Tue, 12 Apr 2016 20:21:32 -0300 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1143f846f93674053051eb94 Archived-At: Cc: art-ads@ietf.org, Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 23:21:35 -0000 --001a1143f846f93674053051eb94 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 12, 2016 at 4:29 PM, Dave Crocker wrote: > [...] > In technical terms, document seems to suffer some confusion about its role > as a format specification, versus as a protocol specification. I believe > this issue is basic and important. It needs to be resolved. > > For a specification involving such a potentially and presumably important > capability, I think significant community support should be required... > unless the spec is to be offered as Experimental, which is the most I'm > inclined to recommend at this point... > Thanks, Dave. I've consulted with our ADs and they're fine with keeping APPSAWG open to process this document so long as we see continued work on its development. If it goes stale again for too long, we'll likely shut down without completing this final milestone and pass the document over to DISPATCH for disposition under their handling model. If we're sure we want Standards Track, that will mean sponsorship by an AD, or a (likely small/short) working group to finish it off. Matthew, do you have the time to put into closing this out? -MSK --001a1143f846f93674053051eb94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 12, 2016 at 4:29 PM, Dave Crocker <dhc2@dcroc= ker.net> wrote:
[...]
In technical terms, document seems to suffer some confusion about its role = as a format specification, versus as a protocol specification.=C2=A0 I beli= eve this issue is basic and important.=C2=A0 It needs to be resolved.

For a specification involving such a potentially and presumably important c= apability, I think significant community support should be required... unle= ss the spec is to be offered as Experimental, which is the most I'm inc= lined to recommend at this point...

Tha= nks, Dave.=C2=A0 I've consulted with our ADs and they're fine with = keeping APPSAWG open to process this document so long as we see continued w= ork on its development.=C2=A0 If it goes stale again for too long, we'l= l likely shut down without completing this final milestone and pass the doc= ument over to DISPATCH for disposition under their handling model.=C2=A0 If= we're sure we want Standards Track, that will mean sponsorship by an A= D, or a (likely small/short) working group to finish it off.

<= div>Matthew, do you have the time to put into closing this out?

-MSK
--001a1143f846f93674053051eb94-- From nobody Tue Apr 12 16:32:44 2016 Return-Path: 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 A2FBA12DD79; Tue, 12 Apr 2016 16:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uYM56jmpmLB3; Tue, 12 Apr 2016 16:32:40 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1E112DD5B; Tue, 12 Apr 2016 16:32:39 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id g8so37227683igr.0; Tue, 12 Apr 2016 16:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=mPXzMhVk4N2VQXHHCAN+gTc+LWwYxHzM7zsmFHjKtWM=; b=XO6U0Zh3dYogG/qek0BH73yLSPbu6Wr9bPoE8Yp7JgWXMtTLK9IO8ayol2kyljlfxg SwJVUydCEADf5TsN+daK/BjRwKLtCXTR8iYtvt68Pf6YFqIKSkMPC4bsLyOOEDTU6EOF 8mAtVk/HJFOeVTVIOSododtsXpHvcp+GRPIVppHK5Ofbbu+mvDDc/082sdOiWzl39Uwr 4r3Djq3/lKP0zOTXAzKgyvKaNbZ1eHBWwl4erPde8anP18QZx+Nd9xrDb1Y46Lf3fVC4 7tlcHbHBjqpJ2UBDtfsRolip0FJ2UIiDkEAPYpOCh+0MgHJouB893PGLD5PdYFwhgPRc xZQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=mPXzMhVk4N2VQXHHCAN+gTc+LWwYxHzM7zsmFHjKtWM=; b=ki9a+mwDnp3GpSDMocmJwRc58UdL7LlR6zlEERBrBG/0YRTvTcd+sMw14ZPAxnlhEi JSG2fNQeqih6UmCdNmNYhk+HKscxzglutO+0wkQv84w7ANhWLvouktjOZqc4VNuLConn tz31UxDdHQ8xW4SNTjGThykgijp+UC2eVNMPs7iXZojjbmKTIB2nQHDClSqSRlIO6x9U TGpJXejt18PoBVy3JfRR7K3XaR01KowuWSNd/aV4GQbZVs9GmCc+JbTIjdShJVde33xR xfEbapCIqdCcIKjMN2H1ypgevpnwCkh9/9nJkPp8bKsJL4KJCGE6B4aujE7pxyDtTs+U K2Dg== X-Gm-Message-State: AD7BkJIIh+Jks6AgBzqfJtvxpsJTs6ZukpuW9L6LYmN4Ybn02bDV0XUypzlQ08binLqjD2zm5W+lEkwCo7Rb1w== MIME-Version: 1.0 X-Received: by 10.50.41.35 with SMTP id c3mr26588698igl.50.1460503959111; Tue, 12 Apr 2016 16:32:39 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Tue, 12 Apr 2016 16:32:39 -0700 (PDT) In-Reply-To: References: <570D4C99.1030405@dcrocker.net> Date: Wed, 13 Apr 2016 09:32:39 +1000 X-Google-Sender-Auth: orHdnLuaDrb56oRszCu0bE4sSEY Message-ID: From: Matthew Kerwin To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e011842e4ad11f6053052130d Archived-At: Cc: art-ads@ietf.org, draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker , Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 23:32:41 -0000 --089e011842e4ad11f6053052130d Content-Type: text/plain; charset=UTF-8 On 13 April 2016 at 09:21, Murray S. Kucherawy wrote: > On Tue, Apr 12, 2016 at 4:29 PM, Dave Crocker wrote: > >> [...] >> In technical terms, document seems to suffer some confusion about its >> role as a format specification, versus as a protocol specification. I >> believe this issue is basic and important. It needs to be resolved. >> >> For a specification involving such a potentially and presumably important >> capability, I think significant community support should be required... >> unless the spec is to be offered as Experimental, which is the most I'm >> inclined to recommend at this point... >> > > Thanks, Dave. I've consulted with our ADs and they're fine with keeping > APPSAWG open to process this document so long as we see continued work on > its development. If it goes stale again for too long, we'll likely shut > down without completing this final milestone and pass the document over to > DISPATCH for disposition under their handling model. If we're sure we want > Standards Track, that will mean sponsorship by an AD, or a (likely > small/short) working group to finish it off. > > Matthew, do you have the time to put into closing this out? > > -MSK > Yes, I don't foresee any big obstacles in the coming weeks/month. I'm working my way through Dave's feedback right now, in fact. Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ --089e011842e4ad11f6053052130d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 13 April 2016 at 09:21, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Apr 12, 2016 = at 4:29 PM, Dave Crocker <dhc2@dcrocker.net> wrote:
[...]
In technical terms, document seems to suffer some confusion about its role = as a format specification, versus as a protocol specification.=C2=A0 I beli= eve this issue is basic and important.=C2=A0 It needs to be resolved.

For a specification involving such a potentially and presumably important c= apability, I think significant community support should be required... unle= ss the spec is to be offered as Experimental, which is the most I'm inc= lined to recommend at this point...

<= div>Thanks, Dave.=C2=A0 I've consulted with our ADs and they're fin= e with keeping APPSAWG open to process this document so long as we see cont= inued work on its development.=C2=A0 If it goes stale again for too long, w= e'll likely shut down without completing this final milestone and pass = the document over to DISPATCH for disposition under their handling model.= =C2=A0 If we're sure we want Standards Track, that will mean sponsorshi= p by an AD, or a (likely small/short) working group to finish it off.
Matthew, do you have the time to put into closing this out?

-MSK

Yes, I don= 't foresee any big obstacles in the coming weeks/month. I'm working= my way through Dave's feedback right now, in fact.

<= /div>
Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--089e011842e4ad11f6053052130d-- From nobody Wed Apr 13 01:28:35 2016 Return-Path: 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 CEBEF12DDFA; Wed, 13 Apr 2016 01:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 w7mn84GJ8i1z; Wed, 13 Apr 2016 01:28:27 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECDB12E1C7; Wed, 13 Apr 2016 01:28:27 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id f1so111597182igr.1; Wed, 13 Apr 2016 01:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=niwKphEKUJWMiFKd/3Zx4MtEMuOlG0u0v67LpFAhAN4=; b=aNMOlFzzVsoD1rtk3/OzP6yU5X763acBkRggZMnYNSFelF/g9hTSLBkjDf/BZxY3Fb 5Fl+RraWETyLj7SclBl6uQiBGJcC9hV5RAvWRzwa/keNW9LzDTa36VJYV0dUhUAmhR8O nhEo6j+Z+H8YlYVvlBZIGd/9jUSls7aln+wGJkwdcdz89on4XaFFdm+j448vRT1M1kwh tuy76Fzfi/ARE/1pUqPNC9aKlXBTMVOZsMbtgdat6+H6gOF59Ryu+HEmgLjNZFQXWJtr v7SjtrJNCKWNTVIZ34Q5t3UNTnJGMeRTMCKzFD6Cc2XKpyy7zUqJnKFlAUUE+/TJ9wri AKTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=niwKphEKUJWMiFKd/3Zx4MtEMuOlG0u0v67LpFAhAN4=; b=X+zHjzIZL2Cah4VGUp1vpd6whtMdkvs/Ie6foQiez9EUXBvgUiaSW3qG5rqwdHvvLD /Snt1xJMIG4ukt0dvd6GfcEybLhRiSB/Xm5k7dN4RE2Ii3zdaSDd8rE0wBhPW5c1ar5/ tfAx7T+dHNjsN+42LIUL/mwezwKiGq9EACE26/kmk21kJ5FxKAXivoko7Sh4cfpeEq8b Wu4VDETRMiiDX8Wr+IramaNZNgHyp7wFxn/J3vfwNQ/UtRImEKFkSuN23SmLwyDwJVWf XUbm0Yvys+ycswWITx69oyqniuZiNpBSRAQKdq+TUgQImJGn+dQ1zeJV9yKQUeF9Z4eV uiRg== X-Gm-Message-State: AOPr4FWqN/itN5xQ3HSgvdpTAhceqBhKxdo6Z5y++NQUJA817fyGctLGM65UmD1kU9jwg0FLKq3KTjlPc56XQw== MIME-Version: 1.0 X-Received: by 10.50.62.113 with SMTP id x17mr9164870igr.34.1460536106445; Wed, 13 Apr 2016 01:28:26 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Wed, 13 Apr 2016 01:28:26 -0700 (PDT) In-Reply-To: <570D4C99.1030405@dcrocker.net> References: <570D4C99.1030405@dcrocker.net> Date: Wed, 13 Apr 2016 18:28:26 +1000 X-Google-Sender-Auth: jDGuJd9rIPqeA7BHSy6PvTNaScc Message-ID: From: Matthew Kerwin To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7bb0414ece75430530598f28 Archived-At: Cc: Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 08:28:34 -0000 --047d7bb0414ece75430530598f28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for this review; it's nice and hefty. I'll work my way through it, commenting inline where relevant, and will endeavour to incorporate your suggestions into my working copy. On 13 April 2016 at 05:29, Dave Crocker wrote: > > > Review of: The file URI Scheme > I-D: draft-ietf-appsawg-file-scheme-05 > > (I see that a -06 version was released today. Based on a quick > scan of differences from the -05 version, I do not see their > affecting the review.) > > > Reviewer: D. Crocker > Date: 12 April 2016 > > This review was performed in my role as document shepherd. > > The review was originally written last November but unfortunately I lost > track of it and apologize for the delay. > > I should also comment that I've just consulted a number of others who hav= e > been involved in discussions about the draft and hope that they will > response to this review, on the mailing list. > > > > Summary: > > The specification seeks to detail the file: URI scheme, which "identifies > a file on a particular file system", and replaces RFC 1738. > > The document has been housed within the Apps Area WG, but has received > little substantive comment -- somewhere in the range of 5-8 people, with > small bursts of activity. Although at least some have tended to be > supportive, there have been notable exceptions. Worse, significant issues > that were raised were not obviously resolved on the list. (I looked at > postings by others, immediately after the author's postings, to see wheth= er > there were statements of agreement that an issue had been resolved, and d= id > not generally see them, concerning those substantive issues.) > > > The draft began as an individual effort, in June 2013, went through many > revisions, and was adopted by AppsAWG in January 2015, and has had a numb= er > of revisions. I note a 9/26/2014 (pre-AppsAWG) comment from Daniel > Stenberg: > > "I would rather have a new spec straighten up and tighten the > language somewhat so that we can get a stricter interpretation of > how a file:// is supposed to work." > > which, in spite of the many document revisions, unfortunately matches my > own assessment of the current draft. > > This is a surprise, since this comment from Daniel was what triggered the complete restructure of the draft into its current form (with a relatively short normative body, and a bunch of informational stuff in appendices.) > I also note a 9/15/2015 (post-AppsAWG adoption) comment from Mark > Nottingham, on behalf of the W3C TAG: > > Regarding the use of `file://` URIs on the web, there are a few > issues that need to be resolved for interoperability: > > 1. How does `file://` fit into the web's origin model? > > 2. How does retrieval of `file://` URIs fit into > [Fetch](https://fetch.spec.whatwg.org/) and/or the [URL > standard](https://url.spec.whatwg.org)? > > This document does not address any of these issues, so we > encourage the APPSAWG to consider addressing these. > > After some discussions with W3 and WHAT folk, I did include mention of 'origin' in the draft. When I received the comments, fetch was very protocol-oriented, and 'file:' doesn't belong to any particular protocol, so there was no obvious fit there; and the draft as it was designed was a close match for the WHAT URL standard as it was at the time (and from what I can see, still is now) so I don't know what more need be said. If someone could tell me what sort of thing they think I should be saying, then I could probably say it. > > One point of process discussion about the draft was to distinguish betwee= n > documenting current practice, versus specifying enhancements. Another was > to distinguish between use of the construct locally (within a user's own > system) versus globally, across the public Web. Again, neither matter > appears to be resolved clearly within the draft, and I can't tell tell > clearly which goals the draft targets, even with the Abstract text: > > "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." > > These two goals entail a classic choice in development of a specification > that deals with existing practice. Clarity between the two goals and > careful precision about which is being served, is essential. > > Yes, this could really do with rewriting and clarification. More on this below, in your inline breakdown. > > 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 n= ot > 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) > > In technical terms, document seems to suffer some confusion about its rol= e > as a format specification, versus as a protocol specification. I believe > this issue is basic and important. It needs to be resolved. > > I don't disagree. Guidance on how to clarify this would be appreciated. How many URI specs don't also define a protocol? If this is the only one, then I probably don't know how to set the precedent. (Some of this is sorted below, with your suggestions.) For a specification involving such a potentially and presumably important > capability, I think significant community support should be required... > unless the spec is to be offered as Experimental, which is the most I'm > inclined to recommend at this point... > > To be honest, if that's what you think is most suitable and if we can't improve it, I don't have a problem with Experimental. We're fighting against decades of stagnation and ennui; if an Experimental spec can kick some life into it and stir up the muck that's a good start. If something resolves out of it, then there's nothing wrong with redoing it "properly" in future, with more engagement and recent experience to call on. But to reiterate, it's already implemented pretty widely so I don't think it can count as an "experimental scheme" -- rather, this would be an experiment in restandardising a diverged and stagnant scheme. > > > Details: > > > Applications Area Working Group M. Kerwin >> Internet-Draft QUT >> Obsoletes: 1738 (if approved) December 1, 2015 >> > > I believe it merely updates it. It essentially replaces only Section > 3.10 of that RFC. > > Yeah, just like 4248 and 4266 did. I'll follow your guidance here. (If I update an obsolete spec, do I inherit that obsoletion?) > Intended status: Standards Track >> Expires: June 3, 2016 >> >> >> The file URI Scheme >> draft-ietf-appsawg-file-scheme-05 >> >> 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 >> > > attempts to define -> defines > > ACK also: common core of what? I think the answer is a common core of object > storage naming convention, but whatever is correct, it should be made > explicit here. > > A common core of what current file URI implementations support and do. At the very least, a common core of syntax. > > > across the broad spectrum of existing implementations, while at the >> same time documenting other current practices. >> > > implementations of ... URI-based file system accessing mechanisms? > > Um, yes, I guess that's a way of putting it. Implementations of things that use file URIs. Should I not write that is "implementations of this scheme" or just "implementations"? > >> =E2=80=8B >> >> >> >> 1. Introduction >> >> A file URI identifies a file on a particular file system. It can be >> used in discussions about the file, and if other conditions are met >> it can be dereferenced to directly access the file. >> > > Since this is a specification, and it has intended for wide use, there > should be some sort of basic definition of what a file system is. > Nothing fancy. And by way of priming the pump: > > ...on a particular file system, which is an object stored in a > structured naming-and-accessing environment on a host. The URI can be > used... > > Hmm, ok. Are parenthetical definitions like this alright? > A file URI identified an object (a "file") stored in a structured > object naming and accessing environment on a host (a "file system.") > The URI can be used ... > > >> The file URI scheme is not coupled with a specific protocol, nor with >> a specific media type. See Section 3 for a discussion of operations >> that can be performed on a file URI. >> > > I think these defined operations are not really performed 'on' the > file URI, but rather are used to create or apply the URI. > > Translating to a local file path is one you perform on the URI itself. How about "...operations that can be performed on a file URI or the object it identifies"? Or just "...on the object identified by a file URI" if you don't like the transformation. > Also: > > media type. -> media type [rfc6838]. > > Sure. Is that an informative reference, or normative? We're mentioning it as something that doesn't apply here, so I'm not sure. > > This document defines a syntax that is compatible with most extant >> implementations, while attempting to push towards a stricter subset >> of "ideal" constructs. In many cases it simultaneously acknowledges >> and deprecates some less common or outdated constructs. >> > > *** ideal? > > How does it 'acknowledge' such constructs? > > I will replace this whole paragraph, it's no longer correct. How about: > This document specifies a syntax that is compatible with most extant > implementations. It also documents other less common or outdated > constructs. > > >> 1.1. History >> >> The file URI scheme was first defined in [RFC1630], which, being an >> informational RFC, does not specify an Internet standard. The >> > > My personal preference is for documents to refrain from referring to > their standards status or the status of other documents. "Status" is an > ephemeral attribute that should be external to the details of a > specification, IMO. > > That is, make the discussion be in terms of the technical and > operational issues, not the standards status. > > Ok. How about I just remove "History" altogether? It doesn't add anything technical or operational. > > definition was standardised in [RFC1738], and the scheme was >> registered with the Internet Assigned Numbers Authority (IANA); >> > > IANA registration is a side-effect of the specs and typically isn't > called out this way, I believe. > > > however that definition omitted certain language included by the >> former that clarified aspects such as: >> > > ... by former that... missing word? > > It says "...by the former that..." > >> o the use of slashes to denote boundaries between directory levels >> of a hierarchical file system; and >> >> o the requirement that client software convert the file URI into a >> file name in the local file name conventions. >> > > *** Hmmm. A requirement like that moves this from being a URI > specification to being a file protocol specification... > > Thank you for saying that, you've triggered a bit of a light-bulb moment for me about why I've had so much trouble getting this draft straight in my head -- maybe it is actually a protocol spec. That said, I'd rather cut it back to be a URI scheme spec. If we need to define the protocol in future, then that's a future issue. > >> The Internet draft [I-D.hoffman-file-uri] was written in an effort to >> keep the file URI scheme on standards track when [RFC1738] was made >> obsolete, but that draft expired in 2005. It enumerated concerns >> arising from the various, often conflicting implementations of the >> scheme. It serves as the spiritual predecessor of this document. >> >> Additionally the WHATWG defines a living URL standard [WHATWG-URL], >> which includes algorithms for interpreting file URIs (as URLs). >> > > How does it relate to the current draft? At the least, doesn't it > instead belong in the next 'Similar Technologies' section? > > I was just listing other specs that roughly do what this one does. UNC isn't the same as file:, but file: URLs are the same as file: URIs. That said I could just wipe out the whole History section, then I'd probably move the WHATWG reference to Similar Technologies. > >> 1.2. Similar Technologies >> >> The Universal Naming Convention (UNC) [MS-DTYP] defines a string >> format that can perform a similar role to the file URI scheme in >> describing the location of files. A UNC filespace selector string >> has three parts: host, share, and path; see Appendix E. This >> document describes but does not specify a means of translating >> between UNC filespace selector strings and file URIs in Appendix C.2. >> > > "describes but does not specify" seems an odd distinction. Not exactly > sure what it means. > > Normative vs informative; the appendices are non-normative descriptions of things that are currently done, or that could be done -- but not things that MUST be done (this comes back to Daniel's comment from 2014.) I will work on the language, and work on clarifying the document structure, since I don't want this confusion to be an issue. > >> >> >> Kerwin Expires June 3, 2016 [Page 3] >> >> Internet-Draft file-scheme December 2015 >> >> >> 1.3. Notational Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> Throughout this document the term "local" is used to describe files >> that can be accessed directly through the local file system. It is >> important to note that a local file may not be physically located on >> the local machine, for example if a networked file system is >> transparently mounted into the local file system. >> > > I'm not exactly sure what 'accessed directly' means, in the modern world > of file systems. Unfortunately, this is cast as a major point of > concern in the document. How is 'directly' different from 'no authority > value is specified'? > > Um, I mean something like "...can be access through the local file system API without explicitly establishing network connections or engaging network protocols." I don't know if that's any better. I should also clarify that I'm talking about local files, not local URIs -- although they're equivalent. The definition of a local file URI is given in section 3. I'll try to rework it. > > 2. Syntax >> >> The file URI syntax is defined here in Augmented Backus-Naur Form >> (ABNF) [RFC5234], including the core ABNF syntax rule "ALPHA" defined >> by that specification, and importing the "userinfo", "host" and >> "path-absolute" rules from [RFC3986] (as updated by [RFC6874].) >> > > Possibly cleaner: > > [RFC5234]. Imported rules: > > From [RFC5234]: ALPHA > > From [RFC3986], [RFC6874]: userinfo, host, authority, > path-absolute > > > The core syntax in [RFC3986] includes "path" and "authority" >> components, for each of which only a subset is used in the definition >> of the file URI scheme. The relevant subset of "path" is "path- >> absolute", and the subset of "authority" is "file-auth", given below. >> >> Please note Appendix C that lists some other commonly seen but >> nonstandard variations. >> >> file-URI =3D file-scheme ":" file-hier-part >> >> file-scheme =3D "file" >> >> file-hier-part =3D "//" auth-path >> / local-path >> >> auth-path =3D [ file-auth ] path-absolute >> >> local-path =3D path-absolute >> >> file-auth =3D [ userinfo "@" ] host >> > > Syntax problem: > > If auth-path has no file-auth, since it's optional, then both the > auth-path and local-path of file-hier-part reduce to path-absolute. > Methinks that's creates a parsing ambiguity? > > =E2=80=8BI think we might have an operator precedence issue; I mean: > file-hier-part =3D ( "//" auth-path ) / local-path=E2=80=8B =E2=80=8Bnot: > file-hier-part =3D "//" ( auth-path / local-path ) So auth-path and local-path can look the same, but are clearly distinguished by the preceding double-slashes. I'll add parens to clarify this (per guidance in https://tools.ietf.org/html/rfc2234#section-3.5 ) > > Hmmm. I'm also not sure whether stylistic nuance and exact compatibility > with the meta-specification documents this is based on are worth > worrying about, but... > > I believe this could derive more smoothly from section 3 of RFC3986, > with something like: > > URI =3D scheme ":" hier-part ; from RFC 3986 > > scheme =3D "file" > > hier-part =3D "//" > ( authority > / local-path ) > > (The parens are to make the binding of the alternatives visually > unambiguous. Relying on formal, implicit binding rules can create tricky > usability errors. The hier-part rule in RFC 3986 might be an example: > Concatenation is has tighter binding than alternatives, in ABNF, but the > labeling in RFC3986 could imply a different parsing. Presumably the > authors of RFC 3986 got the BNF correct, but I'm guessing a random > reader could easily get it wrong... ) > > =E2=80=8B See above. > The syntax definition above is different from those given in >> [RFC1630] and [RFC1738] as it is derived from the generic syntax of >> [RFC3986], which post-dates all previous specifications. >> > > all previous -> the previous file URI > > ACK > > As a special case, the "file-auth" rule can match the string >> "localhost" or the empty string; either value is interpreted as "the >> machine from which the URI is being interpreted," exactly as if no >> authority was present. To maximise compatibility with previous >> > > 'as if no authority" was present.' Probably should be 'were' present, > but more significantly 'authority' is not defined. > > This is a reason to re-use the ABNF rulenames from RFC 3986, when you > are importing them, but modify the portion to suit the file > scheme. (Note that Ned Freed offers extended discussion about this, > including going down a different line of resolution on this issue, in > his 2 November 1:42pm posting. However the issue here is resolved, the > main point is that the text needs to be consistent and clear in its > language. It seems that the current text does not fully resolve the > points he raised.) > > I defined the authority using a reference to RFC3986, and then said that the relevant syntactic subset is given as 'file-auth'. Is that not enough? Also, "authority" is a word in its own right, not just a syntactic element from RFC 3986. I use the word "path" throughout the text without defining it, but nobody complains that there's no `path` in my ABNF. > Since file-auth is shown as optional, that handles the empty string > already and doesn't need a comment. > > Hmm, yes, I suppose so. I was thinking that an element of the ABNF not matched because it is [optional] is distinct from one not matched because it's in an ( unused / alternative ) branch. I can fix it up easily enough, I think, just by deleting a phrase. > > Offhand, I wonder whether the details of the "As special case" paragraph > can (and should) instead be reflected directly in the ABNF? > > I could change file-auth thus: > file-auth =3D "localhost" >=E2=80=8B / [ userinfo "@" ] host (do I need parens again?) Then the "special case" paragraph would just be a bit of text explaining why "localhost" is its own special token. That said, I'm pretty sure I already had that written at some point, and somebody complained that "localhost" was redundant because it was already syntactically covered by 'host'. Should the ABNF lean towards a pure syntactic parser, or include semantic chunks as well? (Asking for AD guidance here.) > > > Kerwin Expires June 3, 2016 [Page 4] >> >> Internet-Draft file-scheme December 2015 >> >> >> specifications, implementations MAY choose to include an empty "file- >> auth". >> >> Systems exhibit different levels of case-sensitivity. Unless the >> file system is known to be case-insensitive, implementations MUST >> maintain the case of file and directory names when translating file >> URIs to and from the local system's representation of file paths, and >> any systems or devices that transport file URIs MUST NOT alter the >> case of file URIs they transport. >> > > This is protocol language, not URI format/semantics language. > > I believe that the needs of this spec are served by something along the > lines of: > > =E2=80=8B=E2=80=8B > Some systems have case-sensitive file naming and some do not. Hence > the file scheme supports case sensitivity, in order to retain the case > as given. Any transport-related handling of the file URI scheme MUST > retain the case as given. Any mapping to or from a case-insensitive form > is soley the responsibility of the implementation processing the file > URI on behalf of the referenced file system. > > Sure thing, I'll work with that suggestion. > > > >> 3. Operations on file URIs >> > > Use of normative language in this section is inappropriate. It does not > provide protocol details and provides essentially no semantics. > > =E2=80=8BSo, should the section even exist? Or should it just say: we're ju= st defining a scheme here, operations are protocol business. BCP35 (http://tools.ietf.org/html/rfc7595#section-3.4) says that the scheme definitions should define a default dereference operation. It doesn't seem to account for schemes that aren't protocol-bound, though. > Implementations that provide dereferencing ooperations on file URIs >> > > ooperations -> operations > > Yep, already noted and fixed. > SHOULD, at a minimum, provide a read-like operation to return the >> contents of a file located by a file URI. Additional operations MAY >> be provided, such as writing to, creating, and deleting files. See >> the POSIX file and directory operations [POSIX] for examples of >> standardized operations that can be performed on files. >> > > What is the practical benefit of giving the reader superficial tutorial > information about file system operations? > > Well, I had to define what a file is earlier. Does it not follow from the previous two sentences? I can remove it if it's too bad, and point out the analogy between file operations and file URI operations. > > File URIs can also be translated to and from other, similar >> constructs, such as local file paths or UNC strings. >> > > I don't know what this means. And how is this sentence useful? > > A file URI is a structured string, a file path is a structured string, and a UNC string is a structured string. You can translate the former to and from (one of) the latter. In early version of the draft this translation was the only operation that could be "performed on a file URI". We can remove it, but then should we keep 3.1? > > A file URI can be dependably dereferenced or translated to a local >> file path only if it is local. A file URI is considered "local" if >> it has a blank or no authority, or the authority is the special >> string "localhost". >> >> This specification neither defines nor forbids a mechanism for >> accessing non-local files. See SMB [MS-SMB], NFS [RFC7530], NCP >> [NOVELL] for examples of protocols that can be used to access files >> over a network. Also see Appendix C.2 for a discussion on >> translating non-local file URIs to and from UNC stings. >> >> 3.1. Translating Local File Path to file URI >> >> Below is an algorithmic description of the process used to convert a >> file path to a URI; see Section 4. >> >> 1. Resolve the file path to its fully qualified absolute form. >> > > What does this mean? Where is it defined? > > I guess it's short-hand for much more text about how some file systems have concepts of relative vs. absolute paths and we have to use the absolute one when such a thing exists. I'll think more about this one. >> 2. Initialise the URI with the "file:" scheme identifier. >> >> 3. If including an empty authority field, append the "//" sigil to >> the URI. >> > > sigil ??? pretty stylized vocabulary... > > Well, it's a magical rune that doesn't mean anything outside of this context. I've spent too much time in D&D (or possibly perl), sorry. Is "token" better? > What about the alternative of including a /non-empty/ authority field? > > Hmm, yes, that's a point. If we want to keep this section, I should add "localhost". > 4. Append a slash character "/" to the URI, to signify the path >> root.> >> > > 5. For each directory in the path after the root: >> >> 1. Transform the directory name to a path segment ([RFC3986], >> Section 3.3) as per Section 2 of [RFC3986]. >> > > I think that Section 2 does not specify how to do a transform, although > yes, it does make reference to doing one. Rather, it specifies encoding > rules. The details of how to do a transform are left to the implementer. > > Hence I believe the above should be something like: > > 1. Transform the directory name to a path segment (RFC3986], > Section 3.3]) to conform to the encoding rules of Section 2 of > [RFC3986]. The specific rules for mapping between a file system name > and a file scheme URI are outside the scope of this specification. > > That works for me. > 2. Append the transformed segment and a delimiting slash >> character "/" to the URI. >> >> 6. If the path includes a file name: >> >> 1. Transform the file name to a path segment as above. >> >> 2. Append the transformed segment to the URI. >> > > A slash is required at the end of a directory, even if there is no file > name? > > If you're using it as a directory then yes. If you're using it as the ultimate object (the "file") then no. We defined "file" as an "object" in the file system earlier, which (going with the UNIX interpretation that everything is a file) can include directories. As far as I know most non-UNIXy systems around today can deal with this interpretation too. Should I spell it out, or leave it up to interpretation? > > Differences from RFC 1738 >> > > Seems like this belongs elsewhere in the document, like maybe an > appendix. It is irrelevant except as an historical note. > > I agree. I will look at moving it to an appendix. > In [RFC1738] a file URL always started with the token "file://", >> followed by an (optionally blank) authority and a "/". That "/" was >> not considered part of the path. This implies that the correct >> encoding for a file path in a UNIX-like environment would have been: >> >> token + authority + slash + path >> =3D "file://" + "" + "/" + "/path/to/file.txt" >> =3D "file:////path/to/file.txt" >> >> However that construct was never observed in practice, and in fact >> would have collided with the eventual encoding of UNC strings in URIs >> described in Appendix C.3. >> >> 3.2. Translating Non-local File Path to file URI >> >> Translating a non-local file path, including a UNC string, to a file >> URI follows the same basic algorithm as for local files, above, >> except that the authority MUST refer to the network-accesible node >> that hosts the file. >> > > accesible -> accessible > > ACK > For example, in a clustered OpenVMS Files-11 system the authority >> would contain the node name. Where the original node reference >> includes a username and password in an access control string, they >> MAY be transcribed into the userinfo field of the authority >> ([RFC3986], Section 3.2.1), security considerations (Section 6) >> notwithstanding. >> >> See Appendix C.2 for an explicit handling of UNC strings. >> >> >> >> >> >> >> >> Kerwin Expires June 3, 2016 [Page 6] >> >> Internet-Draft file-scheme December 2015 >> >> >> 3.3. Incompatible File Paths >> >> Some conventional file path formats are known to be incompatible with >> the file URI scheme. >> >> 3.3.1. Win32 Namespaces >> >> The Microsoft Windows API defines Win32 Namespaces [Win32-Namespaces] >> for interacting with files and devices using Windows API functions. >> These namespaced paths are prefixed by "\\?\" for Win32 File >> Namespaces and "\\.\" for Win32 Device Namespaces. There is also a >> special case for UNC file paths in Win32 File Namespaces, referred to >> as "Long UNC", using the prefix "\\?\UNC\". >> >> This specification does not define a mechanism for translating >> namespaced paths to or from file URIs. >> > > No it doesn't, although it contains some language that almost seems to. > The language needs to be removed, in favor of the above simple sentence. > > Further, language about 'incompatibility' is a commentary that belongs > in the Introduction or some other place outside the main spec. It's an > important discussion point, but it's not part of the spec. > > Intro, or yet another appendix? I don't mind either way, it depends what you think is best. > >> 4. Encoding >> >> To avoid ambiguity, a file URI SHOULD be transported as an >> Internationalized Resource Identifier (IRI) [RFC3987], or as a URI >> with non-ASCII characters encoded according to the UTF-8 character >> encoding [STD63] and percent-encoded as needed ([RFC3986], >> Section 2.5). >> >> The encoding of a file URI depends on the file system that stores the >> > > I'm not sure this sentence is correct. It's a natural assumption but > arguably one can lay any encoding convention on top of any data store. > > I think this sentence came out of a discussion with Dave Thaler, although I can't recall for sure (it appeared some time around September 2014.) What you say is true, but it's only useful if that encoding is compatible with (or can be translated to another encoding that is compatible with) the file system's, so there's still a dependence. I mean, the whole point of this paragraph is to say that you ought to encode it in UCS(+UTF8), even if the file system doesn't use that. Do you have a suggestion for something better to write, that isn't flirting with untruth? > identified file. If the file system uses a known non-Unicode >> character encoding, the path SHOULD be converted to a sequence of >> characters from the Universal Character Set [ISO10646] normalized >> according to Normalization Form C (NFC) [UTR15], before being >> translated to a file URI, and conversely a file URI SHOULD be >> converted back to the file system's native encoding when >> dereferencing or translating to a file path. >> >> Note that many modern file systems encode directory and file names >> as arbitrary sequences of octets. In those cases, the >> representation as an encoded string often depends on the user's >> localization settings, or defaults to UTF-8 [STD63]. >> >> When the file system's encoding is not known the file URI SHOULD be >> transported as an Internationalized Resource Identifier (IRI) >> [RFC3987] to avoid ambiguity. See Appendix D for examples. >> > > =E2=80=8B=E2=80=8B > I'm inclined to think that this section either needs to be far more > complete -- and I'm not recommending it do that -- or it merely needs to > caution implementers to make sure that file scheme URI storage needs to > be idempotent with the original, interoperable form. > > A lot of this is just quoting or paraphrasing RFC 3986. I could probably replace=E2=80=8B a bunch of it with a reference, but that would take some e= ditorial effort on my part, so I won't attempt it immediately. This goes back to Dave Thaler's comments about encoding file URIs and how he wants them to go away completely because of it. (The IRI bit definitely comes from him, filtered through my interpretation.) > > >> 5. Origins >> >> As per [RFC6454], Section 4, when determining the origin of a file >> URI implementations MAY return an implementation-defined value. >> > > Now we are back to protocol, rather than basic representation. But it > seems minimal in detail and utility. > mnot asked how 'file:' fits into the web's origin model; this sentence is pretty much the answer. If it doesn't belong here, then I'm not sure how to answer the question. > >> >> >> Kerwin Expires June 3, 2016 [Page 7] >> >> Internet-Draft file-scheme December 2015 >> >> >> Historically, user agents have granted content from the file URI >> scheme a tremendous amount of privilege. However, granting all local >> files such wide privileges can lead to privilege escalation attacks. >> Some user agents have had success granting local files directory- >> based privileges, but this approach has not been widely adopted. >> Other user agents use globally unique identifiers for each file URI, >> which is the most secure option. >> > > This paragraph belongs in the next, Security Considerations section. > Without the protocol-ish paragraph before it. > This same thought occurred to me yesterday. I'll move it. It means the final sentence need to be fixed, though, since that's talking about "origin" identifiers. > > >> 6. Security Considerations >> >> There are many security considerations for URI schemes discussed in >> [RFC3986]. >> >> File access and the granting of privileges for specific operations >> are complex topics, and the use of file URIs can complicate the >> security model in effect for file privileges. Software using file >> URIs MUST NOT grant greater access than would be available for other >> file access methods. >> > > This sort of normative statement has no real meaning, and certainly none > without explanation. At base, the reader cannot tell was satisfies the > normative statement and what does not. > > Yes, I agree. This is really old language (possibly predating my draft, or maybe suggested to me early on, I can't quite remember). Is it good enough to get rid of this sentence, and move the paragraph from above to here (since they address the same thing, modulo the term "user agents")? > > File systems typically assign an operational meaning to special >> characters, such as the "/", "\", ":", "[", and "]" characters, and >> to special device names like ".", "..", "...", "aux", "lpt", etc. In >> some cases, merely testing for the existence of such a name will >> cause the operating system to pause or invoke unrelated system calls, >> leading to significant security concerns regarding denial of service >> and unintended data transfer. It would be impossible for this >> specification to list all such significant characters and device >> names. Implementers MUST research the reserved names and characters >> for the types of storage device that may be attached to their >> application and restrict the use of data obtained from URI components >> accordingly. >> >> Additionally, as discussed in the HP OpenVMS Systems Documentation >> >> "access control strings include sufficient information to allow >> someone to break in to the remote account, [therefore] they create >> serious security exposure." In a similar vein, the presence of a >> password in a "user:password" userinfo field is deprecated by >> [RFC3986]. As such, the userinfo field of a file URI, if present, >> MUST NOT contain a password. >> > > Is there really no stable, published document that says something similar= ? > > =E2=80=8BNot that I could discover.=E2=80=8B > =E2=80=8B >> > I've just spent most of a day not working on my day job and my family is wondering where I am, so I'll leave the comments at that for now. Some of the incorporated/draft changes to my working copy are online now: http://phluid61.github.io/internet-drafts/file-scheme/ Cheers, and thanks again. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bb0414ece75430530598f28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks= for this review; it's nice and hefty. I'll work my way through it,= commenting inline where relevant, and will endeavour to incorporate your s= uggestions into my working copy.


On 13 April 2016 at 05:29, Dave Cro= cker <dhc2@dcrocker.net> wrote:


Review of: The file URI Scheme
I-D: draft-ietf-appsawg-file-scheme-05

=C2=A0 =C2=A0 =C2=A0(I see that a -06 version was released today.=C2=A0 Bas= ed on a quick
=C2=A0 =C2=A0 =C2=A0scan of differences from the -05 version, I do not see = their
=C2=A0 =C2=A0 =C2=A0affecting the review.)


Reviewer:=C2=A0 D. Crocker
Date:=C2=A0 =C2=A0 =C2=A0 12 April 2016

This review was performed in my role as document shepherd.

The review was originally written last November but unfortunately I lost tr= ack of it and apologize for the delay.

I should also comment that I've just consulted a number of others who h= ave been involved in discussions about the draft and hope that they will re= sponse to this review, on the mailing list.



Summary:

The specification seeks to detail the file: URI scheme, which "identif= ies a file on a particular file system", and replaces RFC 1738.

The document has been housed within the Apps Area WG, but has received litt= le substantive comment -- somewhere in the range of 5-8 people, with small = bursts of activity. Although at least some have tended to be supportive, th= ere have been notable exceptions. Worse, significant issues that were raise= d were not obviously resolved on the list.=C2=A0 (I looked at postings by o= thers, immediately after the author's postings, to see whether there we= re statements of agreement that an issue had been resolved, and did not gen= erally see them, concerning those substantive issues.)


The draft began as an individual effort, in June 2013, went through many re= visions, and was adopted by AppsAWG in January 2015, and has had a number o= f revisions.=C2=A0 I note a 9/26/2014 (pre-AppsAWG) comment from Daniel Ste= nberg:

=C2=A0 =C2=A0 =C2=A0"I would rather have a new spec straighten up and = tighten the
=C2=A0 =C2=A0 =C2=A0language somewhat so that we can get a stricter interpr= etation of
=C2=A0 =C2=A0 =C2=A0how a file:// is supposed to work."

which, in spite of the many document revisions, unfortunately matches my ow= n assessment of the current draft.


This is a surprise, since thi= s comment from Daniel was what triggered the complete restructure of the dr= aft into its current form (with a relatively short normative body, and a bu= nch of informational stuff in appendices.)

=C2=A0
=
I also note a 9/15/2015 (post-AppsAWG adoption) comment from Mark Nottingha= m, on behalf of the W3C TAG:

=C2=A0 =C2=A0 =C2=A0Regarding the use of `file://` URIs on the web, there a= re a few
=C2=A0 =C2=A0 =C2=A0issues that need to be resolved for interoperability:
=C2=A0 =C2=A0 =C2=A01. How does `file://` fit into the web's origin mod= el?

=C2=A0 =C2=A0 =C2=A02. How does retrieval of `file://` URIs fit into
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [Fetch](https://fetch.spec.whatwg.org/= ) and/or the [URL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standard](https://url.spec.whatwg.org)?
=C2=A0 =C2=A0 =C2=A0This document does not address any of these issues, so = we
=C2=A0 =C2=A0 =C2=A0encourage the APPSAWG to consider addressing these.


After some discussions with W= 3 and WHAT folk, I did include mention of 'origin' in the draft.

When I received the comments, fetch was very= protocol-oriented, and 'file:' doesn't belong to any particula= r protocol, so there was no obvious fit there; and the draft as it was desi= gned was a close match for the WHAT URL standard as it was at the time (and= from what I can see, still is now) so I don't know what more need be s= aid. If someone could tell me what sort of thing they think I should be say= ing, then I could probably say it.

=C2=A0

One point of process discussion about the draft was to distinguish between = documenting current practice, versus specifying enhancements. Another was t= o distinguish between use of the construct locally (within a user's own= system) versus globally, across the public Web.=C2=A0 Again, neither matte= r appears to be resolved clearly within the draft, and I can't tell tel= l clearly which goals the draft targets, even with the Abstract text:

=C2=A0 =C2=A0 =C2=A0"It attempts to define a common core which is inte= nded to
=C2=A0 =C2=A0 =C2=A0interoperate across the broad spectrum of existing
=C2=A0 =C2=A0 =C2=A0implementations, while at the same time documenting oth= er current
=C2=A0 =C2=A0 =C2=A0practices."

These two goals entail a classic choice in development of a specification t= hat deals with existing practice.=C2=A0 Clarity between the two goals and c= areful precision about which is being served, is essential.


Yes, this could really do wit= h rewriting and clarification. More on this below, in your inline breakdown= .

=C2=A0

A file: construct should be of significant utility to the Internet communit= y.=C2=A0 So it warrants careful community review and extensive indication o= f active support.=C2=A0 That is, there ought to be a basis for assessing th= e likelihood of implementation and use.=C2=A0 As of now, this is not possib= le.


Technically it's already = implemented in a bunch of places, not always entirely interoperably. Most o= f the non-interoperable parts are in the edge cases, but the "common c= ore" is pretty universal. Since there's no (non-obsolete) spec tha= t 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 discu= ssion that started with that question has lead us to where we are now, with= this draft.

For what it's worth, at l= east one potential implementation is likely: the Ruby standard library Open= URI module, which was the original reason I started pursuing this in the fi= rst place (https://bugs.= ruby-lang.org/issues/8544)

=C2=A0

In technical terms, document seems to suffer some confusion about its role = as a format specification, versus as a protocol specification.=C2=A0 I beli= eve this issue is basic and important.=C2=A0 It needs to be resolved.


I don't disagree. Guidanc= e on how to clarify this would be appreciated. How many URI specs don't= also define a protocol? If this is the only one, then I probably don't= know how to set the precedent. (Some of this is sorted below, with your su= ggestions.)


For a specification involving such a potentially and presumably important c= apability, I think significant community support should be required... unle= ss the spec is to be offered as Experimental, which is the most I'm inc= lined to recommend at this point...


To be honest, if that's w= hat you think is most suitable and if we can't improve it, I don't = have a problem with Experimental. We're fighting against decades of sta= gnation and ennui; if an Experimental spec can kick some life into it and s= tir up the muck that's a good start. If something resolves out of it, t= hen there's nothing wrong with redoing it "properly" in futur= e, with more engagement and recent experience to call on.
<= br>
But to reiterate, it's already implemented pretty wid= ely so I don't think it can count as an "experimental scheme"= -- rather, this would be an experiment in restandardising a diverged and s= tagnant scheme.





Details:


Applications Area Working Group=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M. Ke= rwin
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0QUT
Obsoletes: 1738 (if approved)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0December 1, 2015

I believe it merely updates it.=C2=A0 It essentially replaces only Section<= br> 3.10 of that RFC.


Yeah, just like 4248 and 4266= did. I'll follow your guidance here. (If I update an obsolete spec, do= I inherit that obsoletion?)



Intended status: Standards Track
Expires: June 3, 2016


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-= ietf-appsawg-file-scheme-05

Abstract

=C2=A0 =C2=A0This document specifies the "file" Uniform Resource = Identifier (URI)
=C2=A0 =C2=A0scheme, obsoleting the definition in RFC 1738.

=C2=A0 =C2=A0It attempts to define a common core which is intended to inter= operate

attempts to define -> defines


ACK

<= /div>

also: common core of what? I think the answer is a common core of object storage naming convention, but whatever is correct, it should be made
explicit here.


A common core of what current= file URI implementations support and do. At the very least, a common core = of syntax.

=C2=A0


=C2=A0 =C2=A0across the broad spectrum of existing implementations, while a= t the
=C2=A0 =C2=A0same time documenting other current practices.

implementations of ... URI-based file system accessing mechanisms?


Um, yes, I guess that's a= way of putting it. Implementations of things that use file URIs. Should I = not write that is "implementations of this scheme" or just "= implementations"?




=E2=80=8B<snip>



1.=C2=A0 Introduction

=C2=A0 =C2=A0A file URI identifies a file on a particular file system.=C2= =A0 It can be
=C2=A0 =C2=A0used in discussions about the file, and if other conditions ar= e met
=C2=A0 =C2=A0it can be dereferenced to directly access the file.

Since this is a specification, and it has intended for wide use, there
should be some sort of basic definition of what a file system is.
Nothing fancy. And by way of priming the pump:

=C2=A0 =C2=A0 =C2=A0...on a particular file system, which is an object stor= ed in a
structured naming-and-accessing environment on a host. The URI can be
used...


Hmm, ok. Are parenthetical de= finitions like this alright?

> A file URI identified an object (a "file") s= tored in a structured
> object naming = and accessing environment on a host (a "file system.")
> The URI can be used ...

<= div>=C2=A0


=C2=A0 =C2=A0The file URI scheme is not coupled with a specific protocol, n= or with
=C2=A0 =C2=A0a specific media type.=C2=A0 See Section 3 for a discussion of= operations
=C2=A0 =C2=A0that can be performed on a file URI.

I think these defined operations are not really performed 'on' the<= br> file URI, but rather are used to create or apply the URI.


Translating to a local file p= ath is one you perform on the URI itself. How about "...operations tha= t can be performed on a file URI or the object it identifies"? Or just= "...on the object identified by a file URI" if you don't lik= e the transformation.

=C2=A0
Also:

=C2=A0 =C2=A0media type. -> media type [rfc6838].


Sure. Is that an informative = reference, or normative? We're mentioning it as something that doesn= 9;t apply here, so I'm not sure.

=C2=A0

=C2=A0 =C2=A0This document defines a syntax that is compatible with most ex= tant
=C2=A0 =C2=A0implementations, while attempting to push towards a stricter s= ubset
=C2=A0 =C2=A0of "ideal" constructs.=C2=A0 In many cases it simult= aneously acknowledges
=C2=A0 =C2=A0and deprecates some less common or outdated constructs.

*** ideal?

How does it 'acknowledge' such constructs?


I will replace this whole par= agraph, it's no longer correct. How about:

> This document specifies a syntax that is compatible with most ext= ant
> implementations.=C2=A0 It also documents other less = common or outdated
> constructs.

=C2=A0


1.1.=C2=A0 History

=C2=A0 =C2=A0The file URI scheme was first defined in [RFC1630], which, bei= ng an
=C2=A0 =C2=A0informational RFC, does not specify an Internet standard.=C2= =A0 The

My personal preference is for documents to refrain from referring to
their standards status or the status of other documents. "Status"= is an
ephemeral attribute that should be external to the details of a
specification, IMO.

That is, make the discussion be in terms of the technical and
operational issues, not the standards status.


Ok. How about I just remove &= quot;History" altogether? It doesn't add anything technical or ope= rational.

=C2=A0

=C2=A0 =C2=A0definition was standardised in [RFC1738], and the scheme was =C2=A0 =C2=A0registered with the Internet Assigned Numbers Authority (IANA)= ;

IANA registration is a side-effect of the specs and typically isn't
called out this way, I believe.


=C2=A0 =C2=A0however that definition omitted certain language included by t= he
=C2=A0 =C2=A0former that clarified aspects such as:

=C2=A0 =C2=A0... by former that...=C2=A0 =C2=A0missing word?


It says "...by the former that..."




=C2=A0 =C2=A0o=C2=A0 the use of slashes to denote boundaries between direct= ory levels
=C2=A0 =C2=A0 =C2=A0 of a hierarchical file system; and

=C2=A0 =C2=A0o=C2=A0 the requirement that client software convert the file = URI into a
=C2=A0 =C2=A0 =C2=A0 file name in the local file name conventions.

*** Hmmm. A requirement like that moves this from being a URI
specification to being a file protocol specification...


Thank you for saying that, yo= u've triggered a bit of a light-bulb moment for me about why I've h= ad so much trouble getting this draft straight in my head -- maybe it is ac= tually a protocol spec. That said, I'd rather cut it back to be a URI s= cheme spec. If we need to define the protocol in future, then that's a = future issue.




=C2=A0 =C2=A0The Internet draft [I-D.hoffman-file-uri] was written in an ef= fort to
=C2=A0 =C2=A0keep the file URI scheme on standards track when [RFC1738] was= made
=C2=A0 =C2=A0obsolete, but that draft expired in 2005.=C2=A0 It enumerated = concerns
=C2=A0 =C2=A0arising from the various, often conflicting implementations of= the
=C2=A0 =C2=A0scheme.=C2=A0 It serves as the spiritual predecessor of this d= ocument.

=C2=A0 =C2=A0Additionally the WHATWG defines a living URL standard [WHATWG-= URL],
=C2=A0 =C2=A0which includes algorithms for interpreting file URIs (as URLs)= .

How does it relate to the current draft?=C2=A0 At the least, doesn't it=
instead belong in the next 'Similar Technologies' section?


I was just listing other spec= s that roughly do what this one does. UNC isn't the same as file:, but = file: URLs are the same as file: URIs. That said I could just wipe out the = whole History section, then I'd probably move the WHATWG reference to S= imilar Technologies.




1.2.=C2=A0 Similar Technologies

=C2=A0 =C2=A0The Universal Naming Convention (UNC) [MS-DTYP] defines a stri= ng
=C2=A0 =C2=A0format that can perform a similar role to the file URI scheme = in
=C2=A0 =C2=A0describing the location of files.=C2=A0 A UNC filespace select= or string
=C2=A0 =C2=A0has three parts: host, share, and path; see Appendix E.=C2=A0 = This
=C2=A0 =C2=A0document describes but does not specify a means of translating=
=C2=A0 =C2=A0between UNC filespace selector strings and file URIs in Append= ix C.2.

"describes but does not specify" seems an odd distinction.=C2=A0 = Not exactly
sure what it means.


Normative vs informative; the= appendices are non-normative descriptions of things that are currently don= e, or that could be done -- but not things that MUST be done (this comes ba= ck to Daniel's comment from 2014.)

I= will work on the language, and work on clarifying the document structure, = since I don't want this confusion to be an issue.

<= br>




Kerwin=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires June 3, 2016=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 3]
=0C
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0file-scheme=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0December 2015


1.3.=C2=A0 Notational Conventions

=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMENDED&= quot;, "MAY", and "OPTIONAL" in this
=C2=A0 =C2=A0document are to be interpreted as described in [RFC2119].

=C2=A0 =C2=A0Throughout this document the term "local" is used to= describe files
=C2=A0 =C2=A0that can be accessed directly through the local file system.= =C2=A0 It is
=C2=A0 =C2=A0important to note that a local file may not be physically loca= ted on
=C2=A0 =C2=A0the local machine, for example if a networked file system is =C2=A0 =C2=A0transparently mounted into the local file system.

I'm not exactly sure what 'accessed directly' means, in the mod= ern world
of file systems.=C2=A0 Unfortunately, this is cast as a major point of
concern in the document.=C2=A0 How is 'directly' different from = 9;no authority
value is specified'?


Um, I mean something like &qu= ot;...can be access through the local file system API without explicitly es= tablishing network connections or engaging network protocols." I don&#= 39;t know if that's any better.

I shou= ld also clarify that I'm talking about local files, not local URIs -- a= lthough they're equivalent. The definition of a local file URI is given= in section 3.

I'll try to rework it= .

=C2=A0

2.=C2=A0 Syntax

=C2=A0 =C2=A0The file URI syntax is defined here in Augmented Backus-Naur F= orm
=C2=A0 =C2=A0(ABNF) [RFC5234], including the core ABNF syntax rule "AL= PHA" defined
=C2=A0 =C2=A0by that specification, and importing the "userinfo",= "host" and
=C2=A0 =C2=A0"path-absolute" rules from [RFC3986] (as updated by = [RFC6874].)

Possibly cleaner:

=C2=A0 =C2=A0 =C2=A0[RFC5234]. Imported rules:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 From [RFC5234]: ALPHA

=C2=A0 =C2=A0 =C2=A0 =C2=A0 From [RFC3986], [RFC6874]: userinfo, host, auth= ority,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path-absolute


=C2=A0 =C2=A0The core syntax in [RFC3986] includes "path" and &qu= ot;authority"
=C2=A0 =C2=A0components, for each of which only a subset is used in the def= inition
=C2=A0 =C2=A0of the file URI scheme.=C2=A0 The relevant subset of "pat= h" is "path-
=C2=A0 =C2=A0absolute", and the subset of "authority" is &qu= ot;file-auth", given below.

=C2=A0 =C2=A0Please note Appendix C that lists some other commonly seen but=
=C2=A0 =C2=A0nonstandard variations.

=C2=A0 =C2=A0 =C2=A0 file-URI=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D file-scheme &qu= ot;:" file-hier-part

=C2=A0 =C2=A0 =C2=A0 file-scheme=C2=A0 =C2=A0 =3D "file"

=C2=A0 =C2=A0 =C2=A0 file-hier-part =3D "//" auth-path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/ local-path

=C2=A0 =C2=A0 =C2=A0 auth-path=C2=A0 =C2=A0 =C2=A0 =3D [ file-auth ] path-a= bsolute

=C2=A0 =C2=A0 =C2=A0 local-path=C2=A0 =C2=A0 =C2=A0=3D path-absolute

=C2=A0 =C2=A0 =C2=A0 file-auth=C2=A0 =C2=A0 =C2=A0 =3D [ userinfo "@&q= uot; ] host

Syntax problem:

=C2=A0 =C2=A0If auth-path has no file-auth, since it's optional, then b= oth the
auth-path and local-path of file-hier-part reduce to path-absolute.
Methinks that's creates a parsing ambiguity?


=E2=80=8BI think we might hav= e an operator precedence issue; I mean:

&= gt; file-hier-part =3D ( "//" auth-path ) / local-path=E2=80=8B
=E2=80=8Bnot:

= > file-hier-part =3D "//" ( auth-path / local-path )

=
So auth-path and local-path can look the same, but are = clearly distinguished by the preceding double-slashes. I'll add parens = to clarify this (per guidance in https://tools.ietf.org/html/rfc2234#section-3.5 )

=C2=A0

Hmmm. I'm also not sure whether stylistic nuance and exact compatibilit= y
with the meta-specification documents this is based on are worth
worrying about, but...

I believe this could derive more smoothly from section 3 of RFC3986,
with something like:

=C2=A0 =C2=A0URI=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D scheme ":" hier-p= art=C2=A0 =C2=A0 ; from RFC 3986

=C2=A0 =C2=A0scheme=C2=A0 =C2=A0 =C2=A0=3D "file"

=C2=A0 =C2=A0hier-part=C2=A0 =3D "//"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( authority
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / local-path )

(The parens are to make the binding of the alternatives visually
unambiguous. Relying on formal, implicit binding rules can create tricky usability errors. The hier-part rule in RFC 3986 might be an example:
Concatenation is has tighter binding than alternatives, in ABNF, but the labeling in RFC3986 could imply a different parsing. Presumably the
authors of RFC 3986 got the BNF correct, but I'm guessing a random
reader could easily get it wrong... )

=E2=80=8B
See above.
=



=C2=A0 =C2=A0The syntax definition above is different from those given in =C2=A0 =C2=A0[RFC1630] and [RFC1738] as it is derived from the generic synt= ax of
=C2=A0 =C2=A0[RFC3986], which post-dates all previous specifications.

=C2=A0all previous -> the previous file URI


ACK

=C2= =A0

=C2=A0 =C2=A0As a special case, the "file-auth" rule can match th= e string
=C2=A0 =C2=A0"localhost" or the empty string; either value is int= erpreted as "the
=C2=A0 =C2=A0machine from which the URI is being interpreted," exactly= as if no
=C2=A0 =C2=A0authority was present.=C2=A0 To maximise compatibility with pr= evious

'as if no authority" was present.'=C2=A0 Probably should be &#= 39;were' present,
but more significantly 'authority' is not defined.

This is a reason to re-use the ABNF rulen= ames from RFC 3986, when you
are importing them, but modify the <element> portion to suit the file=
scheme.=C2=A0 (Note that Ned Freed offers extended discussion about this, including going down a different line of resolution on this issue, in
his 2 November 1:42pm posting. However the issue here is resolved, the
main point is that the text needs to be consistent and clear in its
language. It seems that the current text does not fully resolve the
points he raised.)


I defined the authority using= a reference to RFC3986, and then said that the relevant syntactic subset i= s given as 'file-auth'. Is that not enough? Also, "authority&q= uot; is a word in its own right, not just a syntactic element from RFC 3986= . I use the word "path" throughout the text without defining it, = but nobody complains that there's no `path` in my ABNF.

=
=C2=A0
Since file-auth is shown as optional, that handles the empty string
already and doesn't need a comment.


Hmm, yes, I suppose so. I was= thinking that an element of the ABNF not matched because it is [optional] = is distinct from one not matched because it's in an ( unused / alternat= ive ) branch. I can fix it up easily enough, I think, just by deleting a ph= rase.

=C2=A0

Offhand, I wonder whether the details of the "As special case" pa= ragraph
can (and should) instead be reflected directly in the ABNF?


I could change file-auth thus= :

> file-auth =3D "localhost"=
>=E2=80=8B =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 / [ userinf= o "@" ] host

(do I need parens a= gain?)

Then the "special case" p= aragraph would just be a bit of text explaining why "localhost" i= s its own special token. That said, I'm pretty sure I already had that = written at some point, and somebody complained that "localhost" w= as redundant because it was already syntactically covered by 'host'= . Should the ABNF lean towards a pure syntactic parser, or include semantic= chunks as well? (Asking for AD guidance here.)

<= div>=C2=A0


Kerwin=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires June 3, 2016=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 4]
=0C
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0file-scheme=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0December 2015


=C2=A0 =C2=A0specifications, implementations MAY choose to include an empty= "file-
=C2=A0 =C2=A0auth".

=C2=A0 =C2=A0Systems exhibit different levels of case-sensitivity.=C2=A0 Un= less the
=C2=A0 =C2=A0file system is known to be case-insensitive, implementations M= UST
=C2=A0 =C2=A0maintain the case of file and directory names when translating= file
=C2=A0 =C2=A0URIs to and from the local system's representation of file= paths, and
=C2=A0 =C2=A0any systems or devices that transport file URIs MUST NOT alter= the
=C2=A0 =C2=A0case of file URIs they transport.

This is protocol language, not URI format/semantics language.

I believe that the needs of this spec are served by something along the
lines of:

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 Some systems = have case-sensitive file naming and some do not.=C2=A0 Hence
the=C2=A0 file scheme supports case sensitivity, in order to retain the cas= e
as given. Any transport-related handling of the file URI scheme MUST
retain the case as given. Any mapping to or from a case-insensitive form is soley the responsibility of the implementation processing the file
URI on behalf of the referenced file system.


Sure thing, I'll work wit= h that suggestion.

=C2=A0



3.=C2=A0 Operations on file URIs

Use of normative language in this section is inappropriate.=C2=A0 It does n= ot
provide protocol details and provides essentially no semantics.


=E2=80=8BSo, should the secti= on even exist? Or should it just say: we're just defining a scheme here= , operations are protocol business.

BCP35 = (http://tools.ie= tf.org/html/rfc7595#section-3.4) says that the scheme definitions shoul= d define a default dereference operation. It doesn't seem to account fo= r schemes that aren't protocol-bound, though.

=C2= =A0
=C2=A0 =C2=A0Implementations that provide dereferencing ooperations on file= URIs

=C2=A0 =C2=A0ooperations -> operations


Yep, already noted and fixed.=

=C2=A0
=C2=A0 =C2=A0SHOULD, at a minimum, provide a read-like operation to return = the
=C2=A0 =C2=A0contents of a file located by a file URI.=C2=A0 Additional ope= rations MAY
=C2=A0 =C2=A0be provided, such as writing to, creating, and deleting files.= =C2=A0 See
=C2=A0 =C2=A0the POSIX file and directory operations [POSIX] for examples o= f
=C2=A0 =C2=A0standardized operations that can be performed on files.

What is the practical benefit of giving the reader superficial tutorial
information about file system operations?


Well, I had to define what a = file is earlier.

Does it not follow from t= he previous two sentences? I can remove it if it's too bad, and point o= ut the analogy between file operations and file URI operations.

=C2=A0

=C2=A0 =C2=A0File URIs can also be translated to and from other, similar =C2=A0 =C2=A0constructs, such as local file paths or UNC strings.

I don't know what this means.=C2=A0 And how is this sentence useful?

A file URI is a structured st= ring, a file path is a=C2=A0structured=C2=A0string, and a UNC string is a s= tructured string. You can translate the former to and from (one of) the lat= ter.

In early version of the draft this tr= anslation was the only operation that could be "performed on a file UR= I". We can remove it, but then should we keep 3.1?

=C2=A0

=C2=A0 =C2=A0A file URI can be dependably dereferenced or translated to a l= ocal
=C2=A0 =C2=A0file path only if it is local.=C2=A0 A file URI is considered = "local" if
=C2=A0 =C2=A0it has a blank or no authority, or the authority is the specia= l
=C2=A0 =C2=A0string "localhost".

=C2=A0 =C2=A0This specification neither defines nor forbids a mechanism for=
=C2=A0 =C2=A0accessing non-local files.=C2=A0 See SMB [MS-SMB], NFS [RFC753= 0], NCP
=C2=A0 =C2=A0[NOVELL] for examples of protocols that can be used to access = files
=C2=A0 =C2=A0over a network.=C2=A0 Also see Appendix C.2 for a discussion o= n
=C2=A0 =C2=A0translating non-local file URIs to and from UNC stings.

3.1.=C2=A0 Translating Local File Path to file URI

=C2=A0 =C2=A0Below is an algorithmic description of the process used to con= vert a
=C2=A0 =C2=A0file path to a URI; see Section 4.

=C2=A0 =C2=A01.=C2=A0 Resolve the file path to its fully qualified absolute= form.

What does this mean?=C2=A0 Where is it defined?


I guess it's short-hand f= or much more text about how some file systems have concepts of relative vs.= absolute paths and we have to use the absolute one when such a thing exist= s. I'll think more about this one.



=C2=A0 =C2=A02.=C2=A0 Initialise the URI with the "file:" scheme = identifier.

=C2=A0 =C2=A03.=C2=A0 If including an empty authority field, append the &qu= ot;//" sigil to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the URI.

sigil ???=C2=A0 pretty stylized vocabulary...


Well, it's a magical rune= that doesn't mean anything outside of this context. I've spent too= much time in D&D (or possibly perl), sorry. Is "token" bette= r?

=C2=A0
What about the alternative of including a /non-empty/ authority field?


Hmm, yes, that's a point.= If we want to keep this section, I should add "localhost".
=


=C2=A0 =C2=A04.=C2=A0 Append a slash character "/" to the URI, to= signify the path
=C2=A0 =C2=A0 =C2=A0 =C2=A0root.>

=C2=A0 =C2=A05.=C2=A0 For each directory in the path after the root:

=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 Transform the directory name to a path = segment ([RFC3986],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.3) as per Section 2 of [= RFC3986].

I think that Section 2 does not specify how to do a transform, although
yes, it does make reference to doing one.=C2=A0 Rather, it specifies encodi= ng
rules.=C2=A0 The details of how to do a transform are left to the implement= er.

Hence I believe the above should be something like:

=C2=A0 =C2=A0 =C2=A01. Transform the directory name to a path segment (RFC3= 986],
Section 3.3]) to conform to the encoding rules of Section 2 of
[RFC3986].=C2=A0 The specific rules for mapping between a file system name<= br> and a file scheme URI are outside the scope of this specification.


That works for me.

<= /div>


=C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 Append the transformed segment and a de= limiting slash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0character "/" to the URI= .

=C2=A0 =C2=A06.=C2=A0 If the path includes a file name:

=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 Transform the file name to a path segme= nt as above.

=C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 Append the transformed segment to the U= RI.

A slash is required at the end of a directory, even if there is no file
name?


If you're using it as a d= irectory then yes. If you're using it as the ultimate object (the "= ;file") then no. We defined "file" as an "object" = in the file system earlier, which (going with the UNIX interpretation that = everything is a file) can include directories. As far as I know most non-UN= IXy systems around today can deal with this interpretation too. Should I sp= ell it out, or leave it up to interpretation?

=C2=A0

Differences from RFC 1738

Seems like this belongs elsewhere in the document, like maybe an
appendix.=C2=A0 It is irrelevant except as an historical note.


I agree. I will look at movin= g it to an appendix.



=C2=A0 =C2=A0In [RFC1738] a file URL always started with the token "fi= le://",
=C2=A0 =C2=A0followed by an (optionally blank) authority and a "/"= ;.=C2=A0 That "/" was
=C2=A0 =C2=A0not considered part of the path.=C2=A0 This implies that the c= orrect
=C2=A0 =C2=A0encoding for a file path in a UNIX-like environment would have= been:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 token=C2=A0 =C2=A0 =C2=A0+ authority + slash + = path
=C2=A0 =C2=A0 =C2=A0 =3D "file://" + ""=C2=A0 =C2=A0 = =C2=A0 =C2=A0 + "/"=C2=A0 =C2=A0+ "/path/to/file.txt" =C2=A0 =C2=A0 =C2=A0 =3D "file:////path/to/file.txt"

=C2=A0 =C2=A0However that construct was never observed in practice, and in = fact
=C2=A0 =C2=A0would have collided with the eventual encoding of UNC strings = in URIs
=C2=A0 =C2=A0described in Appendix C.3.

3.2.=C2=A0 Translating Non-local File Path to file URI

=C2=A0 =C2=A0Translating a non-local file path, including a UNC string, to = a file
=C2=A0 =C2=A0URI follows the same basic algorithm as for local files, above= ,
=C2=A0 =C2=A0except that the authority MUST refer to the network-accesible = node
=C2=A0 =C2=A0that hosts the file.

=C2=A0 =C2=A0accesible=C2=A0 -> accessible


ACK



=C2=A0 =C2=A0For example, in a clustered OpenVMS Files-11 system the author= ity
=C2=A0 =C2=A0would contain the node name.=C2=A0 Where the original node ref= erence
=C2=A0 =C2=A0includes a username and password in an access control string, = they
=C2=A0 =C2=A0MAY be transcribed into the userinfo field of the authority =C2=A0 =C2=A0([RFC3986], Section 3.2.1), security considerations (Section 6= )
=C2=A0 =C2=A0notwithstanding.

=C2=A0 =C2=A0See Appendix C.2 for an explicit handling of UNC strings.







Kerwin=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires June 3, 2016=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 6]
=0C
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0file-scheme=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0December 2015


3.3.=C2=A0 Incompatible File Paths

=C2=A0 =C2=A0Some conventional file path formats are known to be incompatib= le with
=C2=A0 =C2=A0the file URI scheme.

3.3.1.=C2=A0 Win32 Namespaces

=C2=A0 =C2=A0The Microsoft Windows API defines Win32 Namespaces [Win32-Name= spaces]
=C2=A0 =C2=A0for interacting with files and devices using Windows API funct= ions.
=C2=A0 =C2=A0These namespaced paths are prefixed by "\\?\" for Wi= n32 File
=C2=A0 =C2=A0Namespaces and "\\.\" for Win32 Device Namespaces.= =C2=A0 There is also a
=C2=A0 =C2=A0special case for UNC file paths in Win32 File Namespaces, refe= rred to
=C2=A0 =C2=A0as "Long UNC", using the prefix "\\?\UNC\"= .

=C2=A0 =C2=A0This specification does not define a mechanism for translating=
=C2=A0 =C2=A0namespaced paths to or from file URIs.

No it doesn't, although it contains some language that almost seems to.=
=C2=A0The language needs to be removed, in favor of the above simple senten= ce.

Further, language about 'incompatibility' is a commentary that belo= ngs
in the Introduction or some other place outside the main spec.=C2=A0 It'= ;s an
important discussion point, but it's not part of the spec.


Intro, or yet another appendi= x? I don't mind either way, it depends what you think is best.
=C2=A0

4.=C2=A0 Encoding

=C2=A0 =C2=A0To avoid ambiguity, a file URI SHOULD be transported as an
=C2=A0 =C2=A0Internationalized Resource Identifier (IRI) [RFC3987], or as a= URI
=C2=A0 =C2=A0with non-ASCII characters encoded according to the UTF-8 chara= cter
=C2=A0 =C2=A0encoding [STD63] and percent-encoded as needed ([RFC3986],
=C2=A0 =C2=A0Section 2.5).

=C2=A0 =C2=A0The encoding of a file URI depends on the file system that sto= res the

I'm not sure this sentence is correct.=C2=A0 It's a natural assumpt= ion but
arguably one can lay any encoding convention on top of any data store.


I think this sentence came ou= t of a discussion with Dave Thaler, although I can't recall for sure (i= t appeared some time around September 2014.) What you say is true, but it&#= 39;s only useful if that encoding is compatible with (or can be translated = to another encoding that is compatible with) the file system's, so ther= e's still a dependence. I mean, the whole point of this paragraph is to= say that you ought to encode it in UCS(+UTF8), even if the file system doe= sn't use that.

Do you have a suggestio= n for something better to write, that isn't flirting with untruth?


=C2=A0 =C2=A0identified file.=C2=A0 If the file system uses a known non-Uni= code
=C2=A0 =C2=A0character encoding, the path SHOULD be converted to a sequence= of
=C2=A0 =C2=A0characters from the Universal Character Set [ISO10646] normali= zed
=C2=A0 =C2=A0according to Normalization Form C (NFC) [UTR15], before being<= br> =C2=A0 =C2=A0translated to a file URI, and conversely a file URI SHOULD be<= br> =C2=A0 =C2=A0converted back to the file system's native encoding when =C2=A0 =C2=A0dereferencing or translating to a file path.

=C2=A0 =C2=A0 =C2=A0 Note that many modern file systems encode directory an= d file names
=C2=A0 =C2=A0 =C2=A0 as arbitrary sequences of octets.=C2=A0 In those cases= , the
=C2=A0 =C2=A0 =C2=A0 representation as an encoded string often depends on t= he user's
=C2=A0 =C2=A0 =C2=A0 localization settings, or defaults to UTF-8 [STD63].
=C2=A0 =C2=A0When the file system's encoding is not known the file URI = SHOULD be
=C2=A0 =C2=A0transported as an Internationalized Resource Identifier (IRI)<= br> =C2=A0 =C2=A0[RFC3987] to avoid ambiguity.=C2=A0 See Appendix D for example= s.

=E2=80=8B=E2=80=8B
I'm inclined to think t= hat this section either needs to be far more
complete -- and I'm not recommending it do that -- or it merely needs t= o
caution implementers to make sure that file scheme URI storage needs to
be idempotent with the original, interoperable form.


A lot of this is just quoting= or paraphrasing RFC 3986. I could probably replace=E2=80=8B a bunch of it = with a reference, but that would take some editorial effort on my part, so = I won't attempt it immediately. This goes back to Dave Thaler's com= ments about encoding file URIs and how he wants them to go away completely = because of it. (The IRI bit definitely comes from him, filtered through my = interpretation.)

=C2=A0


5.=C2=A0 Origins

=C2=A0 =C2=A0As per [RFC6454], Section 4, when determining the origin of a = file
=C2=A0 =C2=A0URI implementations MAY return an implementation-defined value= .

Now we are back to protocol, rather than basic representation. But it
seems minimal in detail and utility.

mnot asked how 'file:' fits into the web's origin model;= this sentence is pretty much the answer. If it doesn't belong here, th= en I'm not sure how to answer the question.

=C2=A0<= /div>



Kerwin=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Expires June 3, 2016=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 7]
=0C
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0file-scheme=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0December 2015


=C2=A0 =C2=A0Historically, user agents have granted content from the file U= RI
=C2=A0 =C2=A0scheme a tremendous amount of privilege.=C2=A0 However, granti= ng all local
=C2=A0 =C2=A0files such wide privileges can lead to privilege escalation at= tacks.
=C2=A0 =C2=A0Some user agents have had success granting local files directo= ry-
=C2=A0 =C2=A0based privileges, but this approach has not been widely adopte= d.
=C2=A0 =C2=A0Other user agents use globally unique identifiers for each fil= e URI,
=C2=A0 =C2=A0which is the most secure option.

This paragraph belongs in the next, Security Considerations section.
Without the protocol-ish paragraph before it.

This same thought occurred to me yesterday. I'll move i= t. It means the final sentence need to be fixed, though, since that's t= alking about "origin" identifiers.

=C2=A0


6.=C2=A0 Security Considerations

=C2=A0 =C2=A0There are many security considerations for URI schemes discuss= ed in
=C2=A0 =C2=A0[RFC3986].

=C2=A0 =C2=A0File access and the granting of privileges for specific operat= ions
=C2=A0 =C2=A0are complex topics, and the use of file URIs can complicate th= e
=C2=A0 =C2=A0security model in effect for file privileges.=C2=A0 Software u= sing file
=C2=A0 =C2=A0URIs MUST NOT grant greater access than would be available for= other
=C2=A0 =C2=A0file access methods.

This sort of normative statement has no real meaning, and certainly none without explanation.=C2=A0 At base, the reader cannot tell was satisfies th= e
normative statement and what does not.


Yes, I agree. This is really = old language (possibly predating my draft, or maybe suggested to me early o= n, I can't quite remember). Is it good enough to get rid of this senten= ce, and move the paragraph from above to here (since they address the same = thing, modulo the term "user agents")?

=C2=A0=

=C2=A0 =C2=A0File systems typically assign an operational meaning to specia= l
=C2=A0 =C2=A0characters, such as the "/", "\", ":&= quot;, "[", and "]" characters, and
=C2=A0 =C2=A0to special device names like ".", "..", &q= uot;...", "aux", "lpt", etc.=C2=A0 In
=C2=A0 =C2=A0some cases, merely testing for the existence of such a name wi= ll
=C2=A0 =C2=A0cause the operating system to pause or invoke unrelated system= calls,
=C2=A0 =C2=A0leading to significant security concerns regarding denial of s= ervice
=C2=A0 =C2=A0and unintended data transfer.=C2=A0 It would be impossible for= this
=C2=A0 =C2=A0specification to list all such significant characters and devi= ce
=C2=A0 =C2=A0names.=C2=A0 Implementers MUST research the reserved names and= characters
=C2=A0 =C2=A0for the types of storage device that may be attached to their<= br> =C2=A0 =C2=A0application and restrict the use of data obtained from URI com= ponents
=C2=A0 =C2=A0accordingly.

=C2=A0 =C2=A0Additionally, as discussed in the HP OpenVMS Systems Documenta= tion
=C2=A0 =C2=A0<http://h71000.www7.hp= .com/doc/84final/ba554_90015/ch03s09.html>
=C2=A0 =C2=A0"access control strings include sufficient information to= allow
=C2=A0 =C2=A0someone to break in to the remote account, [therefore] they cr= eate
=C2=A0 =C2=A0serious security exposure."=C2=A0 In a similar vein, the = presence of a
=C2=A0 =C2=A0password in a "user:password" userinfo field is depr= ecated by
=C2=A0 =C2=A0[RFC3986].=C2=A0 As such, the userinfo field of a file URI, if= present,
=C2=A0 =C2=A0MUST NOT contain a password.

Is there really no stable, published document that says something similar?<= br>

=E2=80=8BNot that I could dis= cover.=E2=80=8B



=E2=80=8B<snip>

I've just spent most of a day not working on my da= y job and my family is wondering where I am, so I'll leave the comments= at that for now. Some of the incorporated/draft changes to my working copy= are online now:=C2=A0http://phluid61.github.io/internet-drafts/file-scheme/

Cheers, and thanks again.
--
=C2=A0 Matthew Kerwin
=C2=A0 <= a href=3D"http://matthew.kerwin.net.au/" target=3D"_blank">http://matthew.k= erwin.net.au/
--047d7bb0414ece75430530598f28-- From nobody Wed Apr 13 02:55:04 2016 Return-Path: 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 C006D12D825; Wed, 13 Apr 2016 02:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 faDu4dVy5KL3; Wed, 13 Apr 2016 02:55:01 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F55C12D806; Wed, 13 Apr 2016 02:55:01 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqHVf-0006ud-aT; Wed, 13 Apr 2016 10:54:55 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqHVf-0003na-Jq; Wed, 13 Apr 2016 10:54:55 +0100 Message-ID: <570E176B.1030608@ninebynine.org> Date: Wed, 13 Apr 2016 10:54:51 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 09:55:03 -0000 Hi Dave, Matthew, On 13/04/2016 09:28, Matthew Kerwin wrote: >> The draft began as an individual effort, in June 2013, went through many >> >revisions, and was adopted by AppsAWG in January 2015, and has had a number >> >of revisions. I note a 9/26/2014 (pre-AppsAWG) comment from Daniel >> >Stenberg: >> > >> > "I would rather have a new spec straighten up and tighten the >> > language somewhat so that we can get a stricter interpretation of >> > how afile:// is supposed to work." >> > >> >which, in spite of the many document revisions, unfortunately matches my >> >own assessment of the current draft. >> > >> > > This is a surprise, since this comment from Daniel was what triggered the > complete restructure of the draft into its current form (with a relatively > short normative body, and a bunch of informational stuff in appendices.) This is my perception too. My take is that the main body of the document does now cover core material that can be followed quite strictly. But because of file:'s long history and accretions, it seemed helpful to have *informative* material describing variations that might be in the wild - I think moving these to the appendixes and clearly marking these as informative keeps them clearly separated from the core material about how it should be used. #g -- From nobody Wed Apr 13 03:19:49 2016 Return-Path: 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 D0E5A12D5C8; Wed, 13 Apr 2016 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 u9nbh9yAIiDo; Wed, 13 Apr 2016 03:19:45 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4885612D7A7; Wed, 13 Apr 2016 03:19:45 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqHtc-0004x9-iB; Wed, 13 Apr 2016 11:19:40 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqHtc-0002h8-EV; Wed, 13 Apr 2016 11:19:40 +0100 Message-ID: <570E1D3A.5050608@ninebynine.org> Date: Wed, 13 Apr 2016 11:19:38 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:19:48 -0000 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. #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) > > > From nobody Wed Apr 13 03:35:16 2016 Return-Path: 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 3069212E4B4; Wed, 13 Apr 2016 03:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 bgvo9kaQ2GhC; Wed, 13 Apr 2016 03:35:05 -0700 (PDT) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A4D12E4B0; Wed, 13 Apr 2016 03:35:05 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqI8T-0000pq-oG; Wed, 13 Apr 2016 11:35:01 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqI8T-0004Kt-E6; Wed, 13 Apr 2016 11:35:01 +0100 Message-ID: <570E20D3.5000002@ninebynine.org> Date: Wed, 13 Apr 2016 11:34:59 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:35:14 -0000 On 13/04/2016 09:28, Matthew Kerwin wrote: > >> > >> >In technical terms, document seems to suffer some confusion about its role >> >as a format specification, versus as a protocol specification. I believe >> >this issue is basic and important. It needs to be resolved. >> > >> > > I don't disagree. Guidance on how to clarify this would be appreciated. How > many URI specs don't also define a protocol? If this is the only one, then > I probably don't know how to set the precedent. (Some of this is sorted > below, with your suggestions.) > A URI is a structured data element used in protocols (e.g. HTTP) and in data formats (e.g. HTML). As such, I don't think it makes sense to call it a "protocol". The expected interpretation of some URI schemes will depend on a protocol specification (e.g. HTTP), and its definition may appear in the protocol spec. E.g. https://tools.ietf.org/html/rfc7230#section-2.7.1, but the URI itself is a string that conforms to indicated syntax that can be used predictably with common URI handling operations such as resolution (https://tools.ietf.org/html/rfc3986#section-5). As for other URI specs that don't define a protocol... urn: acct: about: cid: mid: ni: (etc) (That's from a very brief look at http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) #g -- From nobody Wed Apr 13 03:41:36 2016 Return-Path: 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 2FE0312E4CC; Wed, 13 Apr 2016 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 yzdxVChmcu-I; Wed, 13 Apr 2016 03:41:35 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA30212E4C6; Wed, 13 Apr 2016 03:41:34 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqIEm-0007hH-cd; Wed, 13 Apr 2016 11:41:33 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqIEm-00050z-FJ; Wed, 13 Apr 2016 11:41:32 +0100 Message-ID: <570E225B.4090504@ninebynine.org> Date: Wed, 13 Apr 2016 11:41:31 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:41:36 -0000 On 13/04/2016 09:28, Matthew Kerwin wrote: > For a specification involving such a potentially and presumably important >> >capability, I think significant community support should be required... >> >unless the spec is to be offered as Experimental, which is the most I'm >> >inclined to recommend at this point... >> > >> > > To be honest, if that's what you think is most suitable and if we can't > improve it, I don't have a problem with Experimental. We're fighting > against decades of stagnation and ennui; if an Experimental spec can kick > some life into it and stir up the muck that's a good start. If something > resolves out of it, then there's nothing wrong with redoing it "properly" > in future, with more engagement and recent experience to call on. > > But to reiterate, it's already implemented pretty widely so I don't think > it can count as an "experimental scheme" -- rather, this would be an > experiment in restandardising a diverged and stagnant scheme. +1 file:// URIs are *very* widely used - I don't think it makes sense to call them "experimental". I think it should be standards-track, but if the community can't agree then I'd suggest "informational" with permanent registration. (I don't anticipate any spec needing to normatively reference file: URI specifically, as opposed to URIs generically, so I don't see "informational" causing any problems.) #g -- From nobody Wed Apr 13 03:46:18 2016 Return-Path: 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 39C5412D6CE; Wed, 13 Apr 2016 03:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 xjZ2x_7xDkkJ; Wed, 13 Apr 2016 03:46:16 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D309D12D1CB; Wed, 13 Apr 2016 03:46:15 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqIJJ-0002rj-eZ; Wed, 13 Apr 2016 11:46:13 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqIJJ-0005Tj-E0; Wed, 13 Apr 2016 11:46:13 +0100 Message-ID: <570E2373.20209@ninebynine.org> Date: Wed, 13 Apr 2016 11:46:11 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:46:17 -0000 On 13/04/2016 09:28, Matthew Kerwin wrote: >> > >>> >> o the use of slashes to denote boundaries between directory levels >>> >> of a hierarchical file system; and >>> >> >>> >> o the requirement that client software convert the file URI into a >>> >> file name in the local file name conventions. >>> >> >> > >> >*** Hmmm. A requirement like that moves this from being a URI >> >specification to being a file protocol specification... >> > >> > > Thank you for saying that, you've triggered a bit of a light-bulb moment > for me about why I've had so much trouble getting this draft straight in my > head -- maybe it is actually a protocol spec. That said, I'd rather cut it > back to be a URI scheme spec. If we need to define the protocol in future, > then that's a future issue. > Yes, I think staying clear of "protocol" is probably best. #g -- From nobody Wed Apr 13 03:53:12 2016 Return-Path: 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 E877112DCAB; Wed, 13 Apr 2016 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 IfQXkD57jIuQ; Wed, 13 Apr 2016 03:53:09 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7802812DB56; Wed, 13 Apr 2016 03:53:09 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqIPy-0006aT-ro; Wed, 13 Apr 2016 11:53:06 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqIPy-0006Ca-EQ; Wed, 13 Apr 2016 11:53:06 +0100 Message-ID: <570E2510.4040408@ninebynine.org> Date: Wed, 13 Apr 2016 11:53:04 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:53:11 -0000 On 13/04/2016 09:28, Matthew Kerwin wrote: >>> Systems exhibit different levels of case-sensitivity. Unless the >>> >> file system is known to be case-insensitive, implementations MUST >>> >> maintain the case of file and directory names when translating file >>> >> URIs to and from the local system's representation of file paths, and >>> >> any systems or devices that transport file URIs MUST NOT alter the >>> >> case of file URIs they transport. >>> >> >> > >> >This is protocol language, not URI format/semantics language. >> > >> >I believe that the needs of this spec are served by something along the >> >lines of: >> > >> >​​ >> > Some systems have case-sensitive file naming and some do not. Hence >> >the file scheme supports case sensitivity, in order to retain the case >> >as given. Any transport-related handling of the file URI scheme MUST >> >retain the case as given. Any mapping to or from a case-insensitive form >> >is soley the responsibility of the implementation processing the file >> >URI on behalf of the referenced file system. >> > >> > > Sure thing, I'll work with that suggestion. I think this is pretty much redundant. URIs are case sensitive per RFC3986. (Local interpretation may not be, but I'd suggest that's a local implementation issue. At most, make a note as a local handling issue in the appendices? Hmmm... are there any security considerations here that should be flagged - relating to possible unexpected aliasing from case-only differences between files.) #g From nobody Wed Apr 13 03:59:14 2016 Return-Path: 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 3E63D12D597; Wed, 13 Apr 2016 03:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 as8PN5iFr5FQ; Wed, 13 Apr 2016 03:59:13 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A5412D0F2; Wed, 13 Apr 2016 03:59:12 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqIVo-0002zT-f3; Wed, 13 Apr 2016 11:59:08 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqIVo-00076r-E4; Wed, 13 Apr 2016 11:59:08 +0100 Message-ID: <570E267A.2070801@ninebynine.org> Date: Wed, 13 Apr 2016 11:59:06 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 10:59:14 -0000 On 13/04/2016 09:28, Matthew Kerwin wrote: >> 2. Append the transformed segment and a delimiting slash >>> >> character "/" to the URI. >>> >> >>> >> 6. If the path includes a file name: >>> >> >>> >> 1. Transform the file name to a path segment as above. >>> >> >>> >> 2. Append the transformed segment to the URI. >>> >> >> > >> >A slash is required at the end of a directory, even if there is no file >> >name? >> > >> > > If you're using it as a directory then yes. If you're using it as the > ultimate object (the "file") then no. We defined "file" as an "object" in > the file system earlier, which (going with the UNIX interpretation that > everything is a file) can include directories. As far as I know most > non-UNIXy systems around today can deal with this interpretation too. > Should I spell it out, or leave it up to interpretation? > I'd also say "yes". This is an area where URI resolution works differently to file path resolution (on some systems), so it's not just an academic point. If you don't include the trailing "/" on a directory used as a base URI, then the final directory segment gets dropped when performing URI resolution. Developers working in this space will know this anyway, but I think it's important. Also, "file:///home/user" and "file:///home/user/" are different URIs per RFC3986. It's usially a good idea to avoid gratuitous URI aliasing, which suggests it would be good practice to always include the trailing "/". #g -- From nobody Wed Apr 13 07:13:11 2016 Return-Path: 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 AEDC612DEE9; Wed, 13 Apr 2016 07:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 PxdwNkAbZmQl; Wed, 13 Apr 2016 07:13:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2799312DE72; Wed, 13 Apr 2016 07:13:09 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3DED8kc015365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 07:13:08 -0700 To: Graham Klyne References: <570D4C99.1030405@dcrocker.net> <570E225B.4090504@ninebynine.org> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570E53EB.60108@dcrocker.net> Date: Wed, 13 Apr 2016 07:12:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570E225B.4090504@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2016 07:13:08 -0700 (PDT) Archived-At: Cc: Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:13:10 -0000 On 4/13/2016 3:41 AM, Graham Klyne wrote: > On 13/04/2016 09:28, Matthew Kerwin wrote: >> But to reiterate, it's already implemented pretty widely so I don't think >> it can count as an "experimental scheme" -- rather, this would be an >> experiment in restandardising a diverged and stagnant scheme. > > +1 > > file:// URIs are *very* widely used - I don't think it makes sense to > call them "experimental". I think it should be standards-track, but if > the community can't agree then I'd suggest "informational" with > permanent registration. I need to clarify the basis for suggesting Experimental status. (And I had to explain this a few times before posting the review, so it's no surprise I need to do it on-list.) The motivation is not concern whether 'file:' is deployed and used. Of course it is and very widely and very heavily. The concern is with the specification itself. If it is seeking to document existing practice, the question is whether it does that well and usefully. So the idea behind Experimental -- and I see this as especially strong /because/ there already is very wide use of the file: construct -- is to publish the draft and see whether the community adopts use of it, to cover that existing practise. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 13 07:18:51 2016 Return-Path: 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 D019212D6D9; Wed, 13 Apr 2016 07:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8_PVvVJZHg6X; Wed, 13 Apr 2016 07:18:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30C412D126; Wed, 13 Apr 2016 07:18:49 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3DEIljr015572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 07:18:48 -0700 References: <570D4C99.1030405@dcrocker.net> <570E2373.20209@ninebynine.org> To: Matthew Kerwin From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570E553E.7090305@dcrocker.net> Date: Wed, 13 Apr 2016 07:18:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570E2373.20209@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2016 07:18:49 -0700 (PDT) Archived-At: Cc: Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: [apps-discuss] Implementation (was - Re: Review of draft-ietf-appsawg-file-scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:18:51 -0000 On 4/13/2016 3:46 AM, Graham Klyne wrote: > On 13/04/2016 09:28, Matthew Kerwin wrote: >>> > >>>> >> o the use of slashes to denote boundaries between directory >>>> levels >>>> >> of a hierarchical file system; and >>>> >> >>>> >> o the requirement that client software convert the file URI >>>> into a >>>> >> file name in the local file name conventions. >>>> >> >>> > >>> >*** Hmmm. A requirement like that moves this from being a URI >>> >specification to being a file protocol specification... >>> > >>> > >> Thank you for saying that, you've triggered a bit of a light-bulb moment >> for me about why I've had so much trouble getting this draft straight >> in my >> head -- maybe it is actually a protocol spec. That said, I'd rather >> cut it >> back to be a URI scheme spec. If we need to define the protocol in >> future, >> then that's a future issue. >> > > Yes, I think staying clear of "protocol" is probably best. One of the challenges in writing Internet technical specifications, is to make sure that the focus is on bits over the wire, rather than code on a machine. The former is system-independent. The latter always suffers the risk of being implementation-dependent. Even the primary use of file: for "local" environments needs this distinction, in terms of talking only about abstractions. The writing style requirements for making this work well have a variety of characteristics and common practices. I think there's no guide for this, though. So it's more clinical art than mechanical science. One, trivial suggestion that occurs to me is to not use the word implementation -- unless specification reviewing implementation history or the like -- and instead use the word 'use'. It's a gimmick, but it might help. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 13 07:21:18 2016 Return-Path: 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 6210512DC1F; Wed, 13 Apr 2016 07:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 gpuVW2ztdloD; Wed, 13 Apr 2016 07:21:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872DB12DBD3; Wed, 13 Apr 2016 07:21:14 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3DELBgK015619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 07:21:11 -0700 References: <570D4C99.1030405@dcrocker.net> <570E267A.2070801@ninebynine.org> To: Graham Klyne , Matthew Kerwin , Dave Crocker From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570E55CE.2010608@dcrocker.net> Date: Wed, 13 Apr 2016 07:21:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570E267A.2070801@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2016 07:21:11 -0700 (PDT) Archived-At: Cc: Apps Discuss , 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 Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:21:16 -0000 On 4/13/2016 3:59 AM, Graham Klyne wrote: >>> >A slash is required at the end of a directory, even if there is no file >>> >name? >>> > >>> > >> If you're using it as a directory then yes. If you're using it as the >> ultimate object (the "file") then no. We defined "file" as an "object" in >> the file system earlier, which (going with the UNIX interpretation that >> everything is a file) can include directories. As far as I know most >> non-UNIXy systems around today can deal with this interpretation too. >> Should I spell it out, or leave it up to interpretation? >> > > I'd also say "yes". > > This is an area where URI resolution works differently to file path > resolution (on some systems), so it's not just an academic point. There is enough history with yes-vs-no about terminating syntax characters -- cf, trailing dot in a domain name -- that it might help to include an emphasizing/clarifying comment exactly along the lines of Grahams text, just above. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 13 09:56:01 2016 Return-Path: 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 C6D3D12DB7C; Wed, 13 Apr 2016 09:55:59 -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 1pN8jJfoDJXu; 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 E140A12D9C2; Wed, 13 Apr 2016 09:55:57 -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=NiSnLoYJRE3B06v9r8hT99tfYkSyqkrCfYwJnBS6Glg=; b=IWFv4m8n0aQP7flhrswrwHhxCtXfDCMZ3lQVL6DFYZIy7c2y1n245sEUolBzXeUSaeJJgWm7jhstndwxmdSjFfaa3aTZNUOWrf0C7CglQ3C0voD7Yth4cRyn1QvtK23SFfx1mX9A5js4N92lafVczwmxg7fAi9I6s8Fb+OctxJY= 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:54 +0000 Message-ID: <01ba01d195a4$eadbbee0$4001a8c0@gateway.2wire.net> From: t.petch To: Graham Klyne , Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> <570E225B.4090504@ninebynine.org> Date: Wed, 13 Apr 2016 17:42:45 +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: f4c26897-63be-440b-497e-08d363bc7aed X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 2:9yi8PY7+X47E09SZyIptXO9IwpEx0kh6ZuxB18YrqRba8ZU/TQ9vKKfjMnhuz5yk5OIW1FrG37egSOvNkAL881HSRBSTv9Ts68AtNC5RZ2BIM0T4yOYHEVfWZ+gVWhtGZnWgc/BLCLQvPa4cGUbePSyWkff6f9FL1cjYmMZfxEdXsGtA7f2psq6t7I7GeMM2; 3:WQF/TqUji/oL7brGGt0uKOtEDws7ZUGn330dCFybw9naJt5wRfG7K2sysxAzyksve7uA0voWpVNbu3/d8s065YC822QkV4IncCYb1kfC7KLBfp9OX7CJvLQ0DJ/h3gUz; 25:5dJ2NAh/ibo3pCCQB0rYlwtlQApMVmjzMi+7h5PDipio2i/R1uoAPO5T+SJ9wx73EQcrS+MJx7mS/qAX1SPmBCnn9j+kfl0mOSDIdpbDVp+ph/l5OvGraAg03+5tAlAUk4cv1mIOvGoAB/53A9sPchFXjMwiihWyRTNXt08bjAGHZ7HtoKnE5xlQjlNO4n6pufcNQqS2Rb0QP9eQza7a8hOAB5bh7sMRKQrXJeq6/7EN8AkMzaA8/YRB9k/Z4WLWS5rjPd3KPEbC547g7+gH08oQrIXVNt9WnAhPjLEMm3L/mHQsK4mUyJrQQcZHAo/sTkVtmqI365sLZRFc0FCs5w== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1620; X-Microsoft-Antispam-PRVS: 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:5ofjFnrD634z/QIM10aioGnLbPTWEBux5PGFm8QT5GNDnFbE0P3WOe8VhpY5dV/tN2vmwoBLlTB1ELX6EDXPuT7MFvDZ0JKYPTmbTA6tB1jvtTJxFHIlit2NEM1nu1bE9vs3yKwNGzwosNkKvLTUrEQXJfDNCmwHKDilxrdGDDWiWnJjkSjkr+4FJWtzD04LQdm83FbEuuDvWo8ZMUYkWWQs2WZYh8G1zY881zwLSRVpvUcjzoCCFx8N7ZarRns9BoXScYZvTX9ifvOmZyHhNGr902TGCNNN9aBELIOFaIcG+lbMAcwYLFEgUTMffIFX9kCWbH4MxfhzfsL/fl6ZAUNrH6DvkvkeTVsQVIP4rj/IeveP7XDzIOFSidNqKanh X-Forefront-PRVS: 0911D5CE78 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(76104003)(24454002)(377454003)(81166005)(5008740100001)(230700001)(586003)(4326007)(84392002)(15975445007)(42186005)(1456003)(77096005)(2906002)(9686002)(61296003)(1556002)(44716002)(62236002)(47776003)(230783001)(81816999)(50986999)(81686999)(76176999)(66066001)(86362001)(5001770100001)(5004730100002)(92566002)(3846002)(1096002)(6116002)(23756003)(19580405001)(19580395003)(189998001)(50226001)(50466002)(33646002)(74416001)(7726001)(4720700001); 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:Bj0cs3RXvfikmoP49UEVOuHRQYlRsr8eXu30vJg?= =?iso-8859-1?Q?N6ULidfbXLf7kw3ttIsp0Agm2bhMfb18SRImoZy82VY4pOTmeQsSf7lX8E?= =?iso-8859-1?Q?yk/MtwMfQM7xSdcdQiHMxxfJbFkYbVx5OhI6WDyq7lbTYlHEmsVrjqgyWI?= =?iso-8859-1?Q?K8GdUGPRpgI/jLtZRtW0dFV9PC8ahNXWhMuxyYyNxmnyPrWu0l8wpR8SGJ?= =?iso-8859-1?Q?7QM5dErldPtmvlxAS+I99ULxnQRsUWSDZ322XZjFbGyjI2FkzlmxXQBKIF?= =?iso-8859-1?Q?z6sM1SD544P7dgJZdEHEnvM8sq/X6tvp3JUU3KUD2Tbc/3d8XRwououcY/?= =?iso-8859-1?Q?y2mMI0H8JgkBoMT0K+n99AZ1uUApLMA3fPVXzQtOY97fT+OPLphbBeoDf9?= =?iso-8859-1?Q?VcWgR8y+dDmZxfsGlROcmZpRSliEWCwMareP96iS5p6vWGENrw6Ls94ou/?= =?iso-8859-1?Q?BI8s7uhcpS0T0DTCHqCRvlhgxG48C3oZ4DdwzzPBXHaXhMuhoF0gery4pm?= =?iso-8859-1?Q?C+WsZoTuBxUq9apJWYhBtP2aQg1UMyWU4fe8jsLeANUaBONambJuwkH51c?= =?iso-8859-1?Q?p91KISnn+1yLyXykO9U1KwySisL373h77jN6a+Sf8nfjBjqTn78R019ksc?= =?iso-8859-1?Q?OAMtlrSyTMJkijtXMNHlXK1Xe3UAtZmVDlJTiBzIZ2bjzBRgmpj+ozdsBu?= =?iso-8859-1?Q?JTmJjnKNXBduTOOpyAkDbrNOCgs/+9o4sJEPMhWMIx0VADdoc++ob7dnfS?= =?iso-8859-1?Q?FLAD+4JsSXE5uCa/eLaRaBeBdNxTptqKH1fyMZUhtJdccLG7Prl/ZuMwHP?= =?iso-8859-1?Q?1pGtNCGR5oK5YhXgSurrojxEtymiBmcC2KhdMxlZ/r/9cbRJH0PedxWgXM?= =?iso-8859-1?Q?17DPudfgpzk6cfJFRg1OZaDICNFWOXS8gVNtMqd92aEdS5B1rCcb8Ht0cW?= =?iso-8859-1?Q?uYPPkfV5L8o6x61JasuIwZjbQT4jZ90Ej2Goyb2nxijxu7rXAfJPcdrwdg?= =?iso-8859-1?Q?w0eCTcAW/isjm6dpBmzRHVH18t1YghB4JM0tirWEoxGYvq6i74HYyIy1GO?= =?iso-8859-1?Q?JrA/k143lmjVPT6Q7MJ+euIwW553LPXuRaZLfQxuEUh3x8iL+JYf0zPsbd?= =?iso-8859-1?Q?MCwPM+/OP43zlhXODVzXdoMIXIcoYwkEQorYitMmxP9Av/rn+JYSfiPqqP?= =?iso-8859-1?Q?QuJ5zWCafLTd69nq2it5c/iD5+TykfoKGjcoEB7FFIYqWsvyG/pJ0E=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 5:ey76PHnU+6VgeMVA4EVZu6bIHGIyTptstrTriifLgJ9n0B5UnisreqkWA+CazrpP+oL5qmzlXcVNX5UKwZh0b5HMl+YATXyl20ZTE++7LbBKFU6+kf045qflgAPMuC4LAhaSKg4wxvjLcxNvqzmS9g==; 24:zLbroSVSWD9ukwCgxLCqxhE2OIN3J4d1W3bOd2lL44agQwyaaFOoP6kc0DS3FveultQdo9+c3jBedUWnx4ErtYYbx10yRhobgWMPI9YBCZc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 16:55:54.3619 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1620 Archived-At: Cc: Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:56:00 -0000 ----- Original Message ----- From: "Graham Klyne" Sent: Wednesday, April 13, 2016 11:41 AM > On 13/04/2016 09:28, Matthew Kerwin wrote: > > For a specification involving such a potentially and presumably important > >> >capability, I think significant community support should be required... > >> >unless the spec is to be offered as Experimental, which is the most I'm > >> >inclined to recommend at this point... > >> > > >> > > > To be honest, if that's what you think is most suitable and if we can't > > improve it, I don't have a problem with Experimental. We're fighting > > against decades of stagnation and ennui; if an Experimental spec can kick > > some life into it and stir up the muck that's a good start. If something > > resolves out of it, then there's nothing wrong with redoing it "properly" > > in future, with more engagement and recent experience to call on. > > > > But to reiterate, it's already implemented pretty widely so I don't think > > it can count as an "experimental scheme" -- rather, this would be an > > experiment in restandardising a diverged and stagnant scheme. > > +1 > > file:// URIs are *very* widely used - I don't think it makes sense to call them > "experimental". I think it should be standards-track, but if the community > can't agree then I'd suggest "informational" with permanent registration. RFC2026 " The "Experimental" designation typically denotes a specification that is part of some research or development effort. " No, I do not think that this I-D comes into that category. Tom Petch > (I don't anticipate any spec needing to normatively reference file: URI > specifically, as opposed to URIs generically, so I don't see "informational" > causing any problems.) > > #g > -- > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Apr 13 09:56:12 2016 Return-Path: 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 To: Graham Klyne , Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> <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: 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: Cc: Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:56:01 -0000 ----- Original Message ----- From: "Graham Klyne" To: "Matthew Kerwin" ; "Dave Crocker" Cc: ; "Apps Discuss" 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 From nobody Wed Apr 13 09:56:13 2016 Return-Path: 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 208E312DC3A; Wed, 13 Apr 2016 09:56:02 -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 U3cbgB-ntYCn; Wed, 13 Apr 2016 09:55:59 -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 8C09312D85C; Wed, 13 Apr 2016 09:55:58 -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=9vLaK6lVqGN6iJEJqZpHXpiXTgWsH8fwCYfvrB5vU/w=; b=Uf7VSVY6hYjkzG6JhKeHGnzH7DejEtRSXegJj9Y1paJgAb1GZ/9Z5ZYShXeZGYPD2MFgPMqXN5l0hw4Tn/akNqWbdG18kR7IWJkbj5B+c6EpMfmWf9PXYyuhNh1tuwO4ZEUzaFQ76BZEmE1ejE1gUpfSpIlX6KZMuojoZhf/iMw= 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:55 +0000 Message-ID: <01bb01d195a4$eb38d300$4001a8c0@gateway.2wire.net> From: t.petch To: Graham Klyne , Matthew Kerwin , Dave Crocker References: <570D4C99.1030405@dcrocker.net> <570E267A.2070801@ninebynine.org> Date: Wed, 13 Apr 2016 17:51: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: 336847c9-a609-482f-1eff-08d363bc7b43 X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 2:o7FWz6eFn8D8tthkU4NxLKFBeK6KSm5Pv8eJufcj/qyT1OkQCSkd/ttdV5b9a+DFMgqIShvY85QYrAc5OXvMSALC8ezHpoWVohPkY8rtu6PDhi+Jz3GW+K8MZMeCikdq/YfKfRuWwYG7Eoh/brWTbZhvCrKDfiRVIp+/PhuwAT4WQj+t4t4p8t73vrngXhnr; 3:iHUnO8v+EdTPlJPFsvuweU+b1jSGNJJKaRZdGyawylNvmSQUsk8p9frRYtklssi3XmUySO6KRNdxst0TTBKxo7YRf2/GM7nMIxZScg3CWuc0pZjLNQIf71K3/Sw9mSen X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1620; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 25:8dWo0xKblgqdL5tKX1ui2PuvcGS2JcgQ3MiuGwZga3+cRhuvxxqnkZ98vKyKTi+fRSuiEVXFO+83daWPTdan78dwc+tcgXrXth8O3NsBNUosxEY+wF+gQpZUhhR245vax/lnZsdx+KANXZ2oxx09/WjfY8ISq8oVBnY1I16mDKJn3ON91QHM7UqbQnzNE8JByk3xxFnRYeMqMHckN3Q6cJwF+DpIvfzaDX+cuMA6zUMtNeh/A/EAdtw7yAIQkz/yUd6O1qGBo2UWuptkVjmiyxd5udB6kaF/CHXpN7C98aKr1tZcGcahDf/NmsghbFKTwb1yAZfRvP8lE0dyzS7gdIKg0NOlsWMaX4YPD1qWG92Z4rId7BObIe6JTcQZ8XtTs8or/XCyWM9TnmAENd0/MhrnV1gTdcI14+raWsiTaSVk//qyTaWx1uztbwMLOIwe3JnntrYQQqrFQUVVgHN1GWtKP7SD5nPWaomZ8zRH3cjYUVF3VaOCZZDcCcy0VKLa4yC2OoKcJH9bc0BILyPkPJU2uQMhRPKXi5eulHXwwiEtncZpICurfa1V/VpDe1x4J+cydgmHlfNuWm6kE0KrcCnjR9/OKC7uoP2kYjQkrFMXicUH+biHy1I4wa7HGbNm4i530ZpxXQpMhbsv4v+DBsqZmg1hselYDiHleFfrecBMG6D2oxhJANpWfY2VPuKA25fHaBCvi9QU4/T3XkWdsfslYc8+AIRhmmJZRa5mUI0= X-Microsoft-Antispam-PRVS: 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:E0V+b/jQD/lV0sz0ZhZn4kOOwbTDWQCy/U0x5fFwyfMhP3FfMCXS/FTQUqKpXIZPi3ic1Pv02EnyvaGy5vVST1DSVrYB7T1Lk/W/kyuX2PLI2tVbm3eMCoUwadqT/rDx3tm7Ujg/i0dd61f5T9oP7NH9nkkGnxUrPnwE49Bfk8t0/w9H+ZQe4lDwbVYNrvjkRRieBSjSwLpqA1AMuUPlq5IARgbPfNyt/Uzlhat8e9+58vsC3JEYmHKJNhbXAl9yapgxmG0s18fwUQiaK2+MdPLC64e9nJe8qlsw1JHQBdhsDSl/x2dZLEcy5KisGzYVj0JmyXYW407IHd3v5AupxcqtzmQf/2++6yfcUi08+d8r0cyY+v9b9kwnxZNURhnc X-Forefront-PRVS: 0911D5CE78 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(24454002)(377454003)(81166005)(5008740100001)(230700001)(586003)(4326007)(84392002)(15975445007)(42186005)(1456003)(77096005)(2906002)(9686002)(61296003)(1556002)(44716002)(62236002)(47776003)(230783001)(81816999)(50986999)(81686999)(76176999)(66066001)(86362001)(5001770100001)(5004730100002)(92566002)(3846002)(1096002)(6116002)(23756003)(19580405001)(19580395003)(189998001)(50226001)(50466002)(33646002)(74416001)(7726001)(4720700001); 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:W1v5tQdp4Ydq80a693rcBGVNz60PvwQj1V2FRDL?= =?iso-8859-1?Q?u1Wdq5G3ECj3KDs5Y6FLklDzzB6EeovYQ6pFdrfCSbCmrHvpYdBSnKTbq2?= =?iso-8859-1?Q?rjsVX5KPAhSOV9YwHehppban5L2cbKfT1fOESq8kK5JA+1heOu8QuUxZew?= =?iso-8859-1?Q?W9d/VZDciB9FlIFZSMrUV/Un9zZCDGH+snTTU+BH39BRyG2OzcUXCTHbtb?= =?iso-8859-1?Q?A/p40MV7sVYdVwtJ+J6oj+/DpjIxHi2vPh1ox2O9c6iSOI96pas/ajh7oB?= =?iso-8859-1?Q?W97A4G68YxYKdgtzkB3dhfskWhAs7Ny4au9CmvcU40PixBSUCqQV1uqFZh?= =?iso-8859-1?Q?ndkcYiSrH5VMjeAYSWtj6Fy1QArQsuLYIuDXR3mvEDlmTIPtldrPFIkKdO?= =?iso-8859-1?Q?msKLpcC3LVk+Q4PbQ+tBjXWosCdhuoY+6ngKzJs/pZVJ4JRr51CtkcY8yG?= =?iso-8859-1?Q?M9EKaS/M+r0MDqX3Z/tO8sU6qxKDyF+ZRjlMjYvpaRPjbqsLhdPjzZjRDc?= =?iso-8859-1?Q?855S4ip2Jd6xjvLcpd0ilGnrrbPE8WuYOeJMQXBaGCeMJhm12B8DgfWY5/?= =?iso-8859-1?Q?Vgc+F4ckCr3T2ryciv7AU6bj5VagD8h1HVZwcQJl9vsRT/qoLxB9S/MGW7?= =?iso-8859-1?Q?i9G4IeB9oA+CAWNw6TIYLvCORaV5q8JyEFdeyW9YjujE8lmwC1Tb8G5Ski?= =?iso-8859-1?Q?dGRVIuY20gqt5js9XAg6x5AfyUnBZUOxJoud9fdi9IymJG9nPpauefPxo8?= =?iso-8859-1?Q?h1FoxELjF8hbVoMksYgGfkgeS60fViPWInJlR5uxheOC55PUhG8Lg4a+JC?= =?iso-8859-1?Q?G37p6nd8SCVIbUiTPz2mkoO8QlZAOv64Ai7kBH+OTHD2J7hk7oZrcjzwBu?= =?iso-8859-1?Q?JAy3MMPxhOtSXyljXe0dF0BhWgyhSAuhGEiJ5o1EpWs43wP6QcKsJtioN6?= =?iso-8859-1?Q?thJWIb/eSl31vp4gLRXt/2RLUUZtsn0nsyy+K1DSF6xxiBulC6QJIbdj73?= =?iso-8859-1?Q?cAMwl7a+eFmwwTlygyhJxiPDGJSlCJcdES1eHD6IWzjH472qXiRdQQnWHj?= =?iso-8859-1?Q?UzzngoH5FMjqxM0eTVw1GMS8uklWjaxTzpNR3PCG0kb1Zk/ha8qu1xwYu3?= =?iso-8859-1?Q?6FIIkUmVtnBMm4kcGUaTfBqP7HcbyHXRvTfC0CLK4R4crLBSZBKcYbCPRi?= =?iso-8859-1?Q?Q9J6SdEtYrQaxZ3+Nn7QXMrYv5DRJcMJg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1620; 5:A9GA2cL6jDleY8SFtJMGO2yKZc8r0YUWsAu3SCOJ0BtOAPrQVOTqkq2NxF/zn3Mu86qLyE5iIzbUaA7tVnhzDVL41AoxKbDvsmNnjU+c3ZaMfPnPnbO0ajN27JNSLprVOhAYVpQDkMNzjl41cfy/cQ==; 24:MB379LhlbskpbvF+aZ0zSlXbZ9K0LXSyRvxa00gtuJAlr6JvttN1LoajQbgUi1E5jb6rdpxAKTN5QLmqx9lA759f2NJRmNEpnIuGcxeu3d4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 16:55:55.8932 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1620 Archived-At: Cc: Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:56:02 -0000 ----- Original Message ----- From: "Graham Klyne" Sent: Wednesday, April 13, 2016 11:59 AM > On 13/04/2016 09:28, Matthew Kerwin wrote: > >> 2. Append the transformed segment and a delimiting slash > >>> >> character "/" to the URI. > >>> >> > >>> >> 6. If the path includes a file name: > >>> >> > >>> >> 1. Transform the file name to a path segment as above. > >>> >> > >>> >> 2. Append the transformed segment to the URI. > >>> >> > >> > > >> >A slash is required at the end of a directory, even if there is no file > >> >name? > >> > > >> > > > If you're using it as a directory then yes. If you're using it as the > > ultimate object (the "file") then no. We defined "file" as an "object" in > > the file system earlier, which (going with the UNIX interpretation that > > everything is a file) can include directories. As far as I know most > > non-UNIXy systems around today can deal with this interpretation too. > > Should I spell it out, or leave it up to interpretation? > > > > I'd also say "yes". > > This is an area where URI resolution works differently to file path resolution > (on some systems), so it's not just an academic point. > > If you don't include the trailing "/" on a directory used as a base URI, then > the final directory segment gets dropped when performing URI resolution. > > Developers working in this space will know this anyway, but I think it's important. > > Also, "file:///home/user" and "file:///home/user/" are different URIs per > RFC3986. It's usially a good idea to avoid gratuitous URI aliasing, which > suggests it would be good practice to always include the trailing "/". I agree. I am used to Windows where a trailing slash on a URI makes a substantive difference. Tom Petch > > #g > -- > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Apr 13 11:01:48 2016 Return-Path: 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 8E09B12DCED for ; Wed, 13 Apr 2016 11:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it 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 xsx4TTbbqBq7 for ; Wed, 13 Apr 2016 11:01:45 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26ACD12DC46 for ; Wed, 13 Apr 2016 11:01:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1460570501; bh=B4c4WpepQsa/Fqfd39NjI7QuwM77/rtDoRD9s1FVKWo=; l=3593; h=To:References:Cc:From:Date:In-Reply-To; b=Vn5//qdkVK+wgIgLaotTdnPYH0lKmS6j96QwKsNEZzs5A/YU2FA2jGgZMogsgEozt F+NAScJETAzmCCkB0kXjMYM1VqlNl0QLP9G1pT+V9OW3papEK5D5cLAXz6yLcud8IC M5jZJx5q0pVvihZAgU7pgCK7mRBq8m2DAcalgvh4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 13 Apr 2016 20:01:41 +0200 id 00000000005DC044.00000000570E8985.000046FC To: "Murray S. Kucherawy" References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> From: Alessandro Vesely Message-ID: <570E8985.7080708@tana.it> Date: Wed, 13 Apr 2016 20:01:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: Matthias Leisi , AppsAWG , iana-prot-param-comment@iana.org Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 18:01:47 -0000 On Mon 04/Apr/2016 23:11:22 +0200 Murray S. Kucherawy wrote: > On Mon, Apr 4, 2016 at 9:20 AM, Alessandro Vesely wrote: > >> Can people subscribe to iana-prot-param-comment's? > > Not without just starting to Cc: them (i.e., it's not a list or UI I can > access), but I'm also not sure it's a good idea to burden their ticketing > system with a lot of traffic; they don't need to be involved at this phase. The traffic is not so much. The problem is it doesn't seem to be publicly accessible. > If you want to discuss this in a public forum, apps-discuss@ietf.org is > certainly a valid choice. If you want to seek publication via the IETF > stream (which seems a legitimate thing to do), I would eventually move it > to dispatch@ietf.org. Hm... adding CC AppsAWG. Let's see if anybody is interested. I still don't think it is worth publishing the I-D, but maybe IETF's list archives can be considered permanent documents, which can be referenced by items added after Expert Review, no? > I had a look at your -04. Thank you for addressing most of my comments and > suggestions; it's certainly better. A few non-editorial issues remain: > > - The original ptype.property list has not been updated as discussed, so > the main problem remains. The "dns" ptype has its own table there. Added a more text. I don't think this is a useless ptype, since so much stuff is DNS-based... > - You might want to include an example of use, perhaps in an appendix or in > a new Section 2.1, so people can see what's going on. A bare example was there already. Fully expanded. So delighted of the new text, I managed to screw up policy.txt, which is exactly what was to be exemplified :-/ It should read: Authentication-Results: mta.example.org; dnswl=pass dns.zone=list.dnswl.example policy.ip=127.0.10.1 policy.txt="fwd.example http://fwd.example/s?s=100" > - You mention the need to "determine the color of x". Doesn't an MTA > making a query to a DNSxL know what the color of "x" is already? Yes. This is detailed in the last paragraph of the example (A.1). > - Section 2 changed "fail" to "none", but Table 3 in Section 3 did not. Thanks. > - There is now a reference to RFC7719, but no use of that reference > anywhere in the body of the document. Dropped. Ale -------- Forwarded Message -------- Subject: New Version Notification for draft-vesely-authmethod-dnswl-05.txt Date: Wed, 13 Apr 2016 10:19:28 -0700 From: internet-drafts@ietf.org To: Alessandro Vesely A new version of I-D, draft-vesely-authmethod-dnswl-05.txt has been successfully submitted by Alessandro Vesely and posted to the IETF repository. Name: draft-vesely-authmethod-dnswl Revision: 05 Title: DNSWL Email Authentication Method Extension Document date: 2016-04-13 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-vesely-authmethod-dnswl-05.txt Status: https://datatracker.ietf.org/doc/draft-vesely-authmethod-dnswl/ Htmlized: https://tools.ietf.org/html/draft-vesely-authmethod-dnswl-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-vesely-authmethod-dnswl-05 Abstract: This document describes an additional Email Authentication Method compliant with RFC 7601. The method consists in looking up the sender'IP in a DNS whitelist. 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. The IETF Secretariat From nobody Wed Apr 13 11:15:12 2016 Return-Path: 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 F2CC312D7BF for ; Wed, 13 Apr 2016 11:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 j7UUg7Ijo9eZ for ; Wed, 13 Apr 2016 11:15:09 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E42012B069 for ; Wed, 13 Apr 2016 11:15:05 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id t129so80770903vkg.2 for ; Wed, 13 Apr 2016 11:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kmsxYGbq1du6OtTez7nNl/1sSusokOb8evTlQgFVAHM=; b=AwwUDXiFOOvrlD3FaQ0JIcc8J5xZJLmXTtPsfybVHzevtw8IuKrb0uHpA4wrjPruwm Q0h758Ci4RRB27IAuDdQLLepDXpDRTBMqkFqgPNIRctYtfVj6wrXHSrYsOV7ue/tBkth BE0h109YhBOkikMlB6zyJRa5VeYeH0vPKdLWtlUEc+j2dop31GDNXmhadwi3aveuQQI5 r1dNzo2fypPWjzmIINonKbp/1aL0Yj55wl6p3gOlsXgLY7yPZfqruTg862HQMgrRlyz/ ybU+66917URbwFW9Qps/H05KqOfkXmfeuaBceavVbyQtjhHWDHaJZZSGqhd/5tExgRSN PySQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kmsxYGbq1du6OtTez7nNl/1sSusokOb8evTlQgFVAHM=; b=Ewa7VZa0x078Pl5hDxitnFUqm+r4xhtlYGuw2Oov+vL9aolBeZOpbeE8Wlhpzj9eyG f8y9qqSmU4B1sMcVuuvitRZtIkoqiMpU275dJHETO+nf5kM67ENjEzb4KcJjT070bLLZ JEY2jZ0L5977rAWcmoDodeakwgwy5529YGSKZeswjVn96nCRpgshZZ04GHacbjYp+uFC ggB07qZoQS+JMbTpy/FBl2URswBzRn59jiISzBLNO7tQHipY2Y/SFnOr12J1YHyeA9LF TVg0k4Wfyula3EJcHq5fNS8JZJhavfNRqwKOlQ4ka1YJqs11yr8JcjgnVyqVcugDRqot DgbA== X-Gm-Message-State: AOPr4FW+6lMd6ESmFaWtZs4nIg8sEGjXqdSPgOCUul6lSq0GCV3GZ9p3tfEKcvcXhojxozfxqAHk+QdyruaHAg== MIME-Version: 1.0 X-Received: by 10.31.171.143 with SMTP id u137mr5525398vke.88.1460571304526; Wed, 13 Apr 2016 11:15:04 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Wed, 13 Apr 2016 11:15:04 -0700 (PDT) In-Reply-To: <570E8985.7080708@tana.it> References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> <570E8985.7080708@tana.it> Date: Wed, 13 Apr 2016 11:15:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a1143e99cc6b8ec053061c11a Archived-At: Cc: Matthias Leisi , AppsAWG , iana-prot-param-comment@iana.org Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 18:15:11 -0000 --001a1143e99cc6b8ec053061c11a Content-Type: text/plain; charset=UTF-8 On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely wrote: > I still don't think it is worth publishing the I-D, but maybe IETF's list > archives can be considered permanent documents, which can be referenced by > items added after Expert Review, no? > That seems... unconventional at least. I would rather see something published. Going via the ISE, if you're worried about the slog through the IETF Stream, seems like a perfectly viable option. > I had a look at your -04. Thank you for addressing most of my comments > and > > suggestions; it's certainly better. A few non-editorial issues remain: > > > > - The original ptype.property list has not been updated as discussed, so > > the main problem remains. > > The "dns" ptype has its own table there. Added a more text. I don't think > this is a useless ptype, since so much stuff is DNS-based... > I explained in my previous replies why I don't think "dns" is a viable choice for a ptype. I never said it was "useless", but it doesn't fit within the framework described by RFC7601 or its antecedents. I proposed an alternative that I claim does fit. Have you rejected it? > > - You might want to include an example of use, perhaps in an appendix or > in > > a new Section 2.1, so people can see what's going on. > > A bare example was there already. Fully expanded. > It looks great, modulo the issue above. -MSK --001a1143e99cc6b8ec053061c11a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely <vesely@= tana.it> wrote:
I still don't think it is wo= rth publishing the I-D, but maybe IETF's list
archives can be considered permanent documents, which can be referenced by<= br> items added after Expert Review, no?

Th= at seems... unconventional at least.=C2=A0 I would rather see something pub= lished.=C2=A0 Going via the ISE, if you're worried about the slog throu= gh the IETF Stream, seems like a perfectly viable option.

> I had a look at your -04.=C2=A0 Thank you for address= ing most of my comments and
> suggestions; it's certainly better.=C2=A0 A few non-editorial issu= es remain:
>
> - The original ptype.property list has not been updated as discussed, = so
> the main problem remains.

The "dns" ptype has its own table there.=C2=A0 Added a mor= e text.=C2=A0 I don't think
this is a useless ptype, since so much stuff is DNS-based...

I explained in my previous replies why I don't th= ink "dns" is a viable choice for a ptype.=C2=A0 I never said it w= as "useless", but it doesn't fit within the framework describ= ed by RFC7601 or its antecedents.=C2=A0 I proposed an alternative that I cl= aim does fit.=C2=A0 Have you rejected it?
=C2=A0
> - You might want to include an example of use, perhap= s in an appendix or in
> a new Section 2.1, so people can see what's going on.

A bare example was there already.=C2=A0 Fully expanded.

It looks great, modulo the issue above.

-MSK
--001a1143e99cc6b8ec053061c11a-- From nobody Wed Apr 13 13:08:50 2016 Return-Path: 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 E6A7512D98D for ; Wed, 13 Apr 2016 13:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 EOrJ8CxgUEhI for ; Wed, 13 Apr 2016 13:08:48 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE9612D67F for ; Wed, 13 Apr 2016 13:08:48 -0700 (PDT) Received: (qmail 44556 invoked from network); 13 Apr 2016 20:08:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Apr 2016 20:08:47 -0000 Date: 13 Apr 2016 20:08:25 -0000 Message-ID: <20160413200825.15190.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <570E53EB.60108@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 20:08:50 -0000 >So the idea behind Experimental -- and I see this as especially strong >/because/ there already is very wide use of the file: construct -- is to >publish the draft and see whether the community adopts use of it, to >cover that existing practise. I coulda sworn that's what Proposed Standard means. R's, John PS: More concretely, what's the timeline for the experiment and how will we tell what the results are? From nobody Wed Apr 13 14:09:00 2016 Return-Path: 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 E500E12D7FA; Wed, 13 Apr 2016 14:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iBR9N5ZJJdK3; Wed, 13 Apr 2016 14:08:56 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD7D12D59F; Wed, 13 Apr 2016 14:08:55 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g185so84716330ioa.2; Wed, 13 Apr 2016 14:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=c9LOnWzRgZcO2CBnEmTGw4R/XmdH+uKczkp0u85cyog=; b=qaQFQ9AX3dNicYSe7tOOS2k0DyR5nV23Hr330Uiw39L5wiBUmRnTbCdsrzmLRequWl oQXQK5/Z8ujADQjj7n+U3wQLpAptoVAp0QSv1h6vyFt9cNP7aagI9kdmpRArwlilADKq rmqKS9C+F8chJltQG0JdNteUv/4L/P1wGhCscesTlp0gNHFB/fp+sjqACbMRb6+GNpdJ 3IUCwyeNfZt4HrpQgfuQMmN6gwUmrXXGV8OQMVZSibnFfRfHpF5//h9+2lZsyDn8YVRR NLXh4trekPMBlT4vOs0j5uDQGKv7gy6SGyqsx4X6Yh/jKXu8ux68YcwLBf+fIG8TzJoW 9DSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=c9LOnWzRgZcO2CBnEmTGw4R/XmdH+uKczkp0u85cyog=; b=JJXcE08VsYQWk8ivVM4DVuTvidQ7xDMt6czYVdS+4yVa4zaKrdCfRmrEWd6SlXzHCh WXasd4hoxROa4Lso62MppZsmAyrFTsHkpEmd63BPKC7n6SFxnohcMfvb+Uxb29VTexdD 2sXZ66Or6P5ec76qT+V64U/Xx3stHdL4fkrhS7r6jqTCSS3PUFP/BJP9DNiOLRQHhf3E SG+chR02fELRgYf1U25+XICS6YtAFH0MQ/9+6OjBDRGaA/6cvYdxRDQA9h2NcEnX2fJA fnvOfXlBTMkburSC+x2KOnL50VYoHlyQkJ0yRjWTvtvxvA7WoQvKURHu61zWad2/KaaA iw6Q== X-Gm-Message-State: AOPr4FXDvYEcHnpswL3n5u/yny04rAHUqzNLlsRbJzOKPSTkswCj6IRDFnrsc6r693UXp3lkHZoXZxK7jIrCKA== MIME-Version: 1.0 X-Received: by 10.107.15.159 with SMTP id 31mr12251198iop.3.1460581734926; Wed, 13 Apr 2016 14:08:54 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Wed, 13 Apr 2016 14:08:54 -0700 (PDT) In-Reply-To: <570E20D3.5000002@ninebynine.org> References: <570D4C99.1030405@dcrocker.net> <570E20D3.5000002@ninebynine.org> Date: Thu, 14 Apr 2016 07:08:54 +1000 X-Google-Sender-Auth: ucKDMA6tXulthdtaNFaGEBPui2k Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a113ee86879cfed0530642f69 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker , Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:08:58 -0000 --001a113ee86879cfed0530642f69 Content-Type: text/plain; charset=UTF-8 On 13 April 2016 at 20:34, Graham Klyne wrote: > > As for other URI specs that don't define a protocol... > > urn: > acct: > about: > cid: > mid: > ni: > (etc) > > (That's from a very brief look at > http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) > > Urgh, of course you're right, and I knew about those. In my mind I was still hung up on the difference between a purely naming scheme (like urn) and a very dereferenceable one (like mid). As far as precedent, mid: and cid: are both dereferenceable URLs (that is, they support an operation like HTTP's GET), but they're really old so don't have the formalisms we expect in a modern spec. (In fact, they seem to assume that the fact that they can get 'got' at all is basically implied by the fact that they're URLs. (I'm sorry for writing that sentence.)) acct: and ni: are nice and modern, but don't define any methods per se (although they do point to webfinger and/or define a mapping to HTTP URIs). Given the precedent, and Dave's protocol-vs-format comment, I'm wondering if it's even appropriate to include methods in the file: spec at all (BCP 35 only says the definition SHOULD include operations.) Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a113ee86879cfed0530642f69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



Urgh, of course you're right, and I kne= w about those. In my mind I was still hung up on the difference between a p= urely naming scheme (like urn) and a very dereferenceable one (like mid).

As far as precedent, mid: and cid: are both= dereferenceable URLs (that is, they support an operation like HTTP's G= ET), but they're really old so don't have the formalisms we expect = in a modern spec. (In fact, they seem to assume that the fact that they can= get 'got' at all is basically implied by the fact that they're= URLs. (I'm sorry for writing that sentence.))

=
acct: and ni: are nice and modern, but don't define any method= s per se (although they do point to webfinger and/or define a mapping to HT= TP URIs).

Given the precedent, and Dave= 9;s protocol-vs-format comment, I'm wondering if it's even appropri= ate to include methods in the file: spec at all (BCP 35 only says the defin= ition SHOULD include operations.)

Cheers=
--=C2=A0
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113ee86879cfed0530642f69-- From nobody Wed Apr 13 14:15:42 2016 Return-Path: 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 EB53012D506; Wed, 13 Apr 2016 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sRpsJtKGZ0sI; Wed, 13 Apr 2016 14:15:39 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE9C12D18F; Wed, 13 Apr 2016 14:15:39 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id gy3so132092175igb.0; Wed, 13 Apr 2016 14:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=yYxpPKrjK1E/zSfuandGLldDzvOEJh40RbFc3+iBQa0=; b=1GH+Sb7Co1fsZ+t/GY5tH6iT7ieJNI3In26cQy6whsNeWYyO8/SM9AW/lvjduscFiC V+vFe4wboUH47wPGqwHrMPugK5TCTslA75oTE78bnzG2pb9MfGBjP9rjH/g0MHLZLvME vVaGJMRt8ChaBZNH5Ez+gaUbFFkOeIMvd3mg2pk4KXFi66FjiZiQUJkH3YbGPjdgBvrb 0vRCFOOM26nyuhfjBdOnqvmJvmnOE+/6x8NGXhmiotccBdLPRJrs2U4tIabYqkwdbhlK c7ls2K73SQ45C5/CTCLHZufjV8Riy9CqpuYl3jMqkv3DvzDZvAr/Lnl1KaUm+0eH9Pkl k+HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yYxpPKrjK1E/zSfuandGLldDzvOEJh40RbFc3+iBQa0=; b=OIx1OLI8HyT1TMfAnj0vLw83zv4mjhFVKjn+whD2WkSN2wgZYlRsqFj/Mem+pIKX3D HCOiAYy3lKkQTmnyHtp6qdC+o6sTunu6IAg3tnU4rl/7EHPlZyhOyAAQ/ZqKJlBN7Lc2 m2hxG3D8G8yPtntk/BEtptIw5x5mVL6BidVLcPoraR4+1sRiVcZ6+HGvcDH4UVUCxec/ UKYHM2r5NN2adNGTO8HauRPZGpOC0Zf9Zde0Wu+wiP9W9FYCmj+0TVR5m/mOsERHENcW ERJCfO+c1AFl6oPPle+Qxv6R6YzRadqILtsR35OgmRnf/zisbnI5kT3WpynjN4puqjwl EzKQ== X-Gm-Message-State: AD7BkJJDzuOm39F67d1e0MkeSqBm6IMbv2fNkvPvv4qiBkCzosoeMtbiMQMu7hPlkixeO1+Q3kUqMGWceh/KoA== MIME-Version: 1.0 X-Received: by 10.50.27.39 with SMTP id q7mr34334470igg.34.1460582138453; Wed, 13 Apr 2016 14:15:38 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Wed, 13 Apr 2016 14:15:38 -0700 (PDT) In-Reply-To: References: <570D4C99.1030405@dcrocker.net> Date: Thu, 14 Apr 2016 07:15:38 +1000 X-Google-Sender-Auth: WWGXUaLMoEBpr3Rk15zXpO8gBX8 Message-ID: From: Matthew Kerwin To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7b10ce15872b3b05306447a0 Archived-At: Cc: Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 21:15:41 -0000 --047d7b10ce15872b3b05306447a0 Content-Type: text/plain; charset=UTF-8 On 13 April 2016 at 18:28, Matthew Kerwin wrote: > > On 13 April 2016 at 05:29, Dave Crocker wrote: > >> >> >>> >>> Throughout this document the term "local" is used to describe files >>> that can be accessed directly through the local file system. It is >>> important to note that a local file may not be physically located on >>> the local machine, for example if a networked file system is >>> transparently mounted into the local file system. >>> >> >> I'm not exactly sure what 'accessed directly' means, in the modern world >> of file systems. Unfortunately, this is cast as a major point of >> concern in the document. How is 'directly' different from 'no authority >> value is specified'? >> >> > Um, I mean something like "...can be access through the local file system > API without explicitly establishing network connections or engaging network > protocols." I don't know if that's any better. > > Actually that's not precisely what I mean either. I think what I mean is: can be accessed using only the information included in the file path (i.e. not relying on other information such as a network address.) That definition is a bit hairy for file naming schemes that include network addresses (like UNC, or VMS with a node reference.) Cheers -- Matthew Kerwin http://matthew.kerwin.net.au/ --047d7b10ce15872b3b05306447a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 April 2016 at 18:28, Matthew Kerwin &= lt;matthew@kerwi= n.net.au> wrote:

= On 13 April 2016 at 05:29, Dave Crocker <dhc2@dcrocker.net> = wrote:



=C2=A0 =C2=A0Throughout this document the term "local" is used to= describe files
=C2=A0 =C2=A0that can be accessed directly through the local file system.= =C2=A0 It is
=C2=A0 =C2=A0important to note that a local file may not be physically loca= ted on
=C2=A0 =C2=A0the local machine, for example if a networked file system is =C2=A0 =C2=A0transparently mounted into the local file system.

I'm not exactly sure what 'accessed directly' means, in the mod= ern world
of file systems.=C2=A0 Unfortunately, this is cast as a major point of
concern in the document.=C2=A0 How is 'directly' different from = 9;no authority
value is specified'?


Um, I mean something like "...can be acce= ss through the local file system API without explicitly establishing networ= k connections or engaging network protocols." I don't know if that= 's any better.


Actually that's not precisely what I mean either. I think wha= t I mean is: can be accessed using only the information included in the fil= e path (i.e. not relying on other information such as a network address.)

That definition is a bit hairy for file nam= ing schemes that include network addresses (like UNC, or VMS with a node re= ference.)

Cheers
--
=
=C2=A0 Matthew Kerwin
= =C2=A0 http://m= atthew.kerwin.net.au/
--047d7b10ce15872b3b05306447a0-- From nobody Wed Apr 13 15:41:19 2016 Return-Path: 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 1AE4112D7E8 for ; Wed, 13 Apr 2016 15:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 OmpoUvgNplMJ for ; Wed, 13 Apr 2016 15:41:16 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB67D12D6C9 for ; Wed, 13 Apr 2016 15:41:16 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3DMfEQA021090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 15:41:15 -0700 References: <20160413200825.15190.qmail@ary.lan> To: John Levine , apps-discuss@ietf.org From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570ECB02.8060300@dcrocker.net> Date: Wed, 13 Apr 2016 15:41:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160413200825.15190.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2016 15:41:15 -0700 (PDT) Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 22:41:18 -0000 On 4/13/2016 1:08 PM, John Levine wrote: >> So the idea behind Experimental -- and I see this as especially strong >> /because/ there already is very wide use of the file: construct -- is to >> publish the draft and see whether the community adopts use of it, to >> cover that existing practise. > > I coulda sworn that's what Proposed Standard means. Thought my text explained why not. I'll try again: When a specification carries risk of affecting existing operations, there often is a requirement for it to demonstrate acceptable safety, prior to classing it as Proposed. Given that this specification relates to existing use of an extremely important construct -- and especially given how little community review it has received -- I'm suggesting invoking the safety path. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 13 17:02:35 2016 Return-Path: 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 4D06A12E407 for ; Wed, 13 Apr 2016 17:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 XYAqTUK_6fIp for ; Wed, 13 Apr 2016 17:02:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD77A12E3AF for ; Wed, 13 Apr 2016 17:02:31 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A01C722E25B; Wed, 13 Apr 2016 20:02:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <20160413200825.15190.qmail@ary.lan> Date: Thu, 14 Apr 2016 10:02:24 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> References: <20160413200825.15190.qmail@ary.lan> To: General discussion of application-layer protocols X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Dave Crocker Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 00:02:34 -0000 The draft states: """ This document defines a syntax that is compatible with most extant = implementations, while attempting to push towards a stricter subset of = "ideal" constructs. In many cases it simultaneously acknowledges and = deprecates some less common or outdated constructs. """ I'm concerned about how well this draft aligns with current and future = behaviour of common clients (especially, but not exclusively, Web = browsers), especially since it's making decisions about deprecation and = subsetting. Have we had any input or statements of support from those communities? Is there a test suite or other data to validate the decisions made? Absent those things, I question whether it should be published at all. = Experimental doesn't seem like the correct path, because the experiment = would effectively be to "see if this sticks." It's one thing to define a = new protocol extension with the hope that it will get traction in time; = it's another to do hope-based definition of existing protocol = constructs. Regards, > On 14 Apr 2016, at 6:08 AM, John Levine wrote: >=20 >> So the idea behind Experimental -- and I see this as especially = strong=20 >> /because/ there already is very wide use of the file: construct -- is = to=20 >> publish the draft and see whether the community adopts use of it, to=20= >> cover that existing practise. >=20 > I coulda sworn that's what Proposed Standard means. >=20 > R's, > John >=20 > PS: More concretely, what's the timeline for the experiment and how > will we tell what the results are? >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Wed Apr 13 19:11:11 2016 Return-Path: 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 BCA9E12DDCD for ; Wed, 13 Apr 2016 19:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UbvrOPzjdFZi for ; Wed, 13 Apr 2016 19:11:06 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5390412DDC7 for ; Wed, 13 Apr 2016 19:11:06 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g185so90596627ioa.2 for ; Wed, 13 Apr 2016 19:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=X/Nw383dVpTGHP4n7gF6Vqh7f4R9MJBjcnvOIX1q4K8=; b=IKicnF44Dq/tK2jKAFTyhSVxARqhDufq5mrkJzvNsKDialLvqpdrnDoPZOqjA/lQW7 Aaimtepb05HJ+A0wGnVRAUMFMn5FiuuMSx/U7iLRXngZR7uDNot8IgCOJYtxFWIYC2i0 W+K/dIXA3qaFo/igEVFV2HER83fyvzTwOIDRES/YgDiF4gon8bzOPv7AmElmlbB59P8p 7rRdFkW1dN4M/8Gm7yFqF6lxUEpCjeA317a3auokMo/Ryo0ZIJQDA2iO/e1PjOSK4/+D ub1245LiEvxmB0sSjcJrdHZX0LEw3umeD+bOHwtKSflHvGplyZbEwGllbWtUXBflfVIW rhoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=X/Nw383dVpTGHP4n7gF6Vqh7f4R9MJBjcnvOIX1q4K8=; b=TshR8mmniyI5NtR6AMJjU5r0u8Bg0qyNGxOOQ/GFwa+TBspVW303YWQlgHisOqZZRL DTdt452dV49SUbseneScKzqjvlFsheelZXemBlUJ8Tz7dyGSH/HY+xgAHqz5m63CcIf4 70+6rryQAw4vQTGzVX8qo9iC3j/+sfRtCEHXZfQNNDEUxbx9BTBvWzR+3Yf86LpUtANg hNfVywkzgv75GOzEStrzvxUPMP4QSMWKulKtCd3Zic+KXmcY5aSNxL47myNi/8X5iC8t RlANymJb0MznQupPPqn/UrA4zTB5JkT3TY2x1V9lgmLU/Py9BpIVgOcM8hMZFRkCryZJ ZaJw== X-Gm-Message-State: AOPr4FVYHoFfx4UpR5TEJwQSeajy8B9gncuPwp0FsrRO8ImRvoVG/IjKYXX6AWzO+XQnD219/OKzyzLWlaZ/ng== MIME-Version: 1.0 X-Received: by 10.107.15.159 with SMTP id 31mr13186423iop.3.1460599865715; Wed, 13 Apr 2016 19:11:05 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Wed, 13 Apr 2016 19:11:05 -0700 (PDT) In-Reply-To: <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> Date: Thu, 14 Apr 2016 12:11:05 +1000 X-Google-Sender-Auth: uDXspI-gHix1UFjG1zBf-pb-WlY Message-ID: From: Matthew Kerwin To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113ee86827b163053068688b Archived-At: Cc: Dave Crocker , General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 02:11:10 -0000 --001a113ee86827b163053068688b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 April 2016 at 10:02, Mark Nottingham wrote: > The draft states: > > """ > This document defines a syntax that is compatible with most extant > implementations, while attempting to push towards a stricter subset of > "ideal" constructs. In many cases it simultaneously acknowledges and > deprecates some less common or outdated constructs. > """ > > Actually since Dave's review the working copy now says: """ =E2=80=8BThis document specifies a syntax that is compatible with most exta= nt implementations. It also documents other less common or outdated constructs= . """ =E2=80=8BThat is, the idealism and deprecation are both removed. Essentiall= y it's an update of the syntax from RFC 1738 to fit better with 3986, and some information regarding unspecified edge cases and implementation-specific divergences. As I mentioned in my reply to Dave's review, I want to work out how to clarify the intention and structure of the document; I think this helps inform that. I'm concerned about how well this draft aligns with current and future > behaviour of common clients (especially, but not exclusively, Web > browsers), especially since it's making decisions about deprecation and > subsetting. > > Have we had any input or statements of support from those communities? > > A little, mostly tangential or out of band. Is it typical for lots of entities to do a similar thing in different ways, and block standardisation by not engaging? It sounds snarky, but I'm genuinely asking, since I'm still quite new to this whole open standardisation thing and don't know the politics of it. If it's my fault for not appropriately seeking that engagement, I'll happily go seeking it (even if it's too late for this draft.) Is there a test suite or other data to validate the decisions made? > > Nope. How would that look? Would a list of URIs and the expected outcomes of parsing/dereferencing them (alongside metrics of known implementations that pass/fail) be enough? Absent those things, I question whether it should be published at all. > Experimental doesn't seem like the correct path, because the experiment > would effectively be to "see if this sticks." It's one thing to define a > new protocol extension with the hope that it will get traction in time; > it's another to do hope-based definition of existing protocol constructs. > > Since everyone "does" file URIs, but they all do it differently, and the spec that defines it is ancient, underspecified, and officially obsolete, would you suggest instead I write an informational RFC describing the situation and what everyone is doing right now? Because I really don't want to walk away and leave the situation the way it currently is. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113ee86827b163053068688b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 14 April 2016 at 10:02, Mark Nottingham <mnot@mnot.net> wrote:
The draft states:

"""
This document defines a syntax that is compatible with most extant implemen= tations, while attempting to push towards a stricter subset of "ideal&= quot; constructs.=C2=A0 In many cases it simultaneously acknowledges and de= precates some less common or outdated constructs.
"""


Actually since Dave's rev= iew the working copy now says:

""= ;"
=E2=80=8BThis document specifies a syntax that is com= patible with most extant implementations. It also documents other less comm= on or outdated constructs.
"""

=
=E2=80=8BThat is, the idealism and deprecation are both remov= ed. Essentially it's an update of the syntax from RFC 1738 to fit bette= r with 3986, and some information regarding unspecified edge cases and impl= ementation-specific divergences.

As I ment= ioned in my reply to Dave's review, I want to work out how to clarify t= he intention and structure of the document; I think this helps inform that.=


I'm concerned about how well this draft aligns with current and future = behaviour of common clients (especially, but not exclusively, Web browsers)= , especially since it's making decisions about deprecation and subsetti= ng.

Have we had any input or statements of support from those communities?


A little, mostly tangential o= r out of band.

Is it typical for lots of= entities to do a similar thing in different ways, and block standardisatio= n by not engaging? It sounds snarky, but I'm genuinely asking, since I&= #39;m still quite new to this whole open standardisation thing and don'= t know the politics of it.

If it's my = fault for not appropriately seeking that engagement, I'll happily go se= eking it (even if it's too late for this draft.)

Is there a test suite or other data to validate the decisions made?


Nope. How would that look? Wo= uld a list of URIs and the expected outcomes of parsing/dereferencing them = (alongside metrics of known implementations that pass/fail) be enough?

Absent those things, I question whether it should be published at all. Expe= rimental doesn't seem like the correct path, because the experiment wou= ld effectively be to "see if this sticks." It's one thing to = define a new protocol extension with the hope that it will get traction in = time; it's another to do hope-based definition of existing protocol con= structs.


Since everyone "does" fi= le URIs, but they all do it differently, and the spec that defines it is an= cient, underspecified, and officially obsolete, would you suggest instead I= write an informational RFC describing the situation and what everyone is d= oing right now? Because I really don't want to walk away and leave the = situation the way it currently is.

Cheers=
--
=C2=A0 Matthew= Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113ee86827b163053068688b-- From nobody Wed Apr 13 19:28:43 2016 Return-Path: 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 0D4B912E5F8 for ; Wed, 13 Apr 2016 19:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 uckO8H2tsG5e for ; Wed, 13 Apr 2016 19:28:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8201012E121 for ; Wed, 13 Apr 2016 19:28:41 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3E2SdRg007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 19:28:40 -0700 References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> To: Matthew Kerwin , Mark Nottingham From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570F0057.3030409@dcrocker.net> Date: Wed, 13 Apr 2016 19:28:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2016 19:28:40 -0700 (PDT) Archived-At: Cc: Dave Crocker , General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 02:28:43 -0000 On 4/13/2016 7:11 PM, Matthew Kerwin wrote: > On 14 April 2016 at 10:02, Mark Nottingham >wrote: > Actually since Dave's review the working copy now says: > > """ > ​This document specifies a syntax that is compatible with most extant > implementations. It also documents other less common or outdated constructs. > """ just to lighten things up with a bit of superficial nit-picking about wording: http://grammarist.com/usage/existent-extant/ > ​That is, the idealism and deprecation are both removed. Essentially > > I'm concerned about how well this draft aligns with current and > future behaviour of common clients (especially, but not exclusively, > Web browsers), especially since it's making decisions about > deprecation and subsetting. > > Have we had any input or statements of support from those communities? > > > A little, mostly tangential or out of band. > > Is it typical for lots of entities to do a similar thing in different > ways, and block standardisation by not engaging? It sounds snarky, but > I'm genuinely asking, since I'm still quite new to this whole open > standardisation thing and don't know the politics of it. This is why focusing on bits over the wire is better than talking about software implementation details. If the 'different ways' mean different bits over the wire, then they are using different formats or different protocols. And they won't interoperate. If they generate/parse the same bits and same semantics over the wire, this we don't care how the built the software to do it, because they /do/ interoperate. > Is there a test suite or other data to validate the decisions made? > > > Nope. How would that look? Would a list of URIs and the expected > outcomes of parsing/dereferencing them (alongside metrics of known > implementations that pass/fail) be enough? There has long been a part of the world that seeks to test network software with comformance suites, and the like. The historical alternative in the IETF world is interoperability test between real implementations, rather than having independent implementations bang against an artificial, third-party 'test suite'. (On the other hand, test suites can be very efficient for aiding basic debugging...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 13 19:55:12 2016 Return-Path: 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 9EEDD12D924 for ; Wed, 13 Apr 2016 19:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6AMYobQybUET for ; Wed, 13 Apr 2016 19:55:08 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C809912DA2C for ; Wed, 13 Apr 2016 19:55:07 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id g185so91334357ioa.2 for ; Wed, 13 Apr 2016 19:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=3XkVwCiVWZkv1chM3dqfoFtMdcavqKz23Fm3W7k0Lks=; b=IbZbosrudfSSrd4VTHziwGHwHOPwlpcrCBm93/SMSthhTI8RHy3czqS13ZEdVVf0H7 X+a7rNo+IwDjeNUK1jueSI1khQMhLZxtf4M48nMtZp4Cm098QUxkoVQEgRzjIwzNPSvg UzkwZyTqzsEIKzx5v8WRafANun+StBAWLyKUFVvdV8oX+vOHeMsItEfS+akbWQAlCHOs nnyNcnjGqPwnlHg3mQX8oCXWFZq5/8ONjcjLe3gqWxif6EOt8EyOyy5eVyWmkjcfIco+ biDHa6DiHFV6QnfwZ33n9EptEs6arlu4BkDkOBngPjzfMSD+BNvdbOonsjzbxDzqnt3A MpPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3XkVwCiVWZkv1chM3dqfoFtMdcavqKz23Fm3W7k0Lks=; b=XGlLd4JSnXCkSsW8H3ZF4sFZTp2L2V47al8vGOi3DXF7eHk84lrs6/cVQwDM/HBWje TmFaFznPb6V8giZLTobyxa2UQgp/dafFrcxYU++hyOQ07clXORRRWOiQ8wMPMeen3cTi dB9WsrbHNE3rF23SUEQXwsrXhVS82+/PYZUniJGKFXnZsnLqVSPYkQlHLc0TXOYeciWn adZlEvr6Sl+mjuJVNYB6t2gPTvga47emiEgDuxDI7/Sz2XZDV9X3tiQV+WpqHVnZ/3SN 1RmtvwD0HOfB6RmAUYaCWUWbe0fDBvByYv3Z8Q5wLWdHl7WgflX9YEUiIHODmBJG7K4m suKA== X-Gm-Message-State: AOPr4FXpl+5uanzgITwxP/hWPQBNBnCODHlNKkoeUOKCyqkgKNQyBloNzwbJaeDIm5SDh8pY9PS+jn8qBUZsYw== MIME-Version: 1.0 X-Received: by 10.107.15.159 with SMTP id 31mr13311213iop.3.1460602507206; Wed, 13 Apr 2016 19:55:07 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Wed, 13 Apr 2016 19:55:07 -0700 (PDT) In-Reply-To: <570F0057.3030409@dcrocker.net> References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> <570F0057.3030409@dcrocker.net> Date: Thu, 14 Apr 2016 12:55:07 +1000 X-Google-Sender-Auth: VYGKzBRo-CDXd08KT9YpWK4Bjyk Message-ID: From: Matthew Kerwin To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113ee86899a94f0530690526 Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 02:55:10 -0000 --001a113ee86899a94f0530690526 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 April 2016 at 12:28, Dave Crocker wrote: > On 4/13/2016 7:11 PM, Matthew Kerwin wrote: > >> On 14 April 2016 at 10:02, Mark Nottingham > >wrote: >> Actually since Dave's review the working copy now says: >> >> """ >> =E2=80=8BThis document specifies a syntax that is compatible with most e= xtant >> implementations. It also documents other less common or outdated >> constructs. >> """ >> > > just to lighten things up with a bit of superficial nit-picking about > wording: > > http://grammarist.com/usage/existent-extant/ > > Fair enough. I think I did mean 'extant', but I'm not super invested in the word. > =E2=80=8BThat is, the idealism and deprecation are both removed. Essentia= lly >> >> > I'm concerned about how well this draft aligns with current and >> future behaviour of common clients (especially, but not exclusively, >> Web browsers), especially since it's making decisions about >> deprecation and subsetting. >> >> Have we had any input or statements of support from those communitie= s? >> >> >> A little, mostly tangential or out of band. >> >> Is it typical for lots of entities to do a similar thing in different >> ways, and block standardisation by not engaging? It sounds snarky, but >> I'm genuinely asking, since I'm still quite new to this whole open >> standardisation thing and don't know the politics of it. >> > > This is why focusing on bits over the wire is better than talking about > software implementation details. If the 'different ways' mean different > bits over the wire, then they are using different formats or different > protocols. And they won't interoperate. > > If they generate/parse the same bits and same semantics over the wire, > this we don't care how the built the software to do it, because they /do/ > interoperate. > > The 'different ways' are actually different bits over the wire. Mostly those are the bits that weren't part of the original spec, but were widely deemed useful/necessary. I've tried to sidestep too much controversy by continuing not to specify them, but I did write down some of the ways some folk have decided to represent them. > > Is there a test suite or other data to validate the decisions made? >> >> >> Nope. How would that look? Would a list of URIs and the expected >> outcomes of parsing/dereferencing them (alongside metrics of known >> implementations that pass/fail) be enough? >> > > There has long been a part of the world that seeks to test network > software with comformance suites, and the like. The historical alternati= ve > in the IETF world is interoperability test between real implementations, > rather than having independent implementations bang against an artificial= , > third-party 'test suite'. > > (On the other hand, test suites can be very efficient for aiding basic > debugging...) > > Mostly I just looked at the various browsers and APIs and worked out what they had in common. It's hard to define an interoperability test for file URIs, since they really only "interoperate" by being parsed/dereferenced from shared hypertext documents -- i.e. basically a 'test suite.' Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113ee86899a94f0530690526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 April 2016 at 12:28, Dave Crocker <= ;dhc2@dcrocker.net> wrote:
On = 4/13/2016 7:11 PM, Matthew Kerwin wrote:
On 14 April 2016 at 10:02, Mark Nottingham <mnot@mnot.net
<mailto:mnot@mnot.net= >>wrote:
Actually since Dave's review the working copy now says:

"""
=E2=80=8BThis document specifies a syntax that is compatible with most exta= nt
implementations. It also documents other less common or outdated constructs= .
"""

just to lighten things up with a bit of superficial nit-picking about wordi= ng:

=C2=A0 =C2=A0http://grammarist.com/usage/existent-exta= nt/


Fair enough. I think I= did mean 'extant', but I'm not super invested in the word.


=E2=80=8BThat is, the idealism and deprecation are both removed. Essentiall= y


=C2=A0 =C2=A0 I'm concerned about how well this draft aligns with curre= nt and
=C2=A0 =C2=A0 future behaviour of common clients (especially, but not exclu= sively,
=C2=A0 =C2=A0 Web browsers), especially since it's making decisions abo= ut
=C2=A0 =C2=A0 deprecation and subsetting.

=C2=A0 =C2=A0 Have we had any input or statements of support from those com= munities?


A little, mostly tangential or out of band.

Is it typical for lots of entities to do a similar thing in different
ways, and block standardisation by not engaging? It sounds snarky, but
I'm genuinely asking, since I'm still quite new to this whole open<= br> standardisation thing and don't know the politics of it.

This is why focusing on bits over the wire is better than talking about sof= tware implementation details.=C2=A0 If the 'different ways' mean di= fferent bits over the wire, then they are using different formats or differ= ent protocols.=C2=A0 And they won't interoperate.

If they generate/parse the same bits and same semantics over the wire, this= we don't care how the built the software to do it, because they /do/ i= nteroperate.


The 'different way= s' are actually different bits over the wire. Mostly those are the bits= that weren't part of the original spec, but were widely deemed useful/= necessary. I've tried to sidestep too much controversy by continuing no= t to specify them, but I did write down some of the ways some folk have dec= ided to represent them.

=C2=A0

=C2=A0 =C2=A0 Is there a test suite or other data to validate the decisions= made?


Nope. How would that look? Would a list of URIs and the expected
outcomes of parsing/dereferencing them (alongside metrics of known
implementations that pass/fail) be enough?

There has long been a part of the world that seeks to test network software= with comformance suites, and the like.=C2=A0 The historical alternative in= the IETF world is interoperability test between real implementations, rath= er than having independent implementations bang against an artificial, thir= d-party 'test suite'.

(On the other hand, test suites can be very efficient for aiding basic debu= gging...)


Mostly I just looked= at the various browsers and APIs and worked out what they had in common. I= t's hard to define an interoperability test for file URIs, since they r= eally only "interoperate" by being parsed/dereferenced from share= d hypertext documents -- i.e. basically a 'test suite.'

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--001a113ee86899a94f0530690526-- From nobody Wed Apr 13 20:06:20 2016 Return-Path: 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 2B97A12DD2D for ; Wed, 13 Apr 2016 20:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 pnR-GKh2wJWF for ; Wed, 13 Apr 2016 20:06:18 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A91E12DC3F for ; Wed, 13 Apr 2016 20:06:18 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3E36G46012343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Apr 2016 20:06:17 -0700 References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> <570F0057.3030409@dcrocker.net> To: Matthew Kerwin , Dave Crocker From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570F0928.4020307@dcrocker.net> Date: Wed, 13 Apr 2016 20:06:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Apr 2016 20:06:17 -0700 (PDT) Archived-At: Cc: Mark Nottingham , General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:06:19 -0000 On 4/13/2016 7:55 PM, Matthew Kerwin wrote: > This is why focusing on bits over the wire is better than talking > about software implementation details. If the 'different ways' mean > different bits over the wire, then they are using different formats > or different protocols. And they won't interoperate. > > If they generate/parse the same bits and same semantics over the > wire, this we don't care how the built the software to do it, > because they /do/ interoperate. > > > The 'different ways' are actually different bits over the wire. Mostly > those are the bits that weren't part of the original spec, but were > widely deemed useful/necessary. I've tried to sidestep too much > controversy by continuing not to specify them, but I did write down some > of the ways some folk have decided to represent them. OK. My advice: If there is a common core of bits over the wire that they all do do, but then some /additional/ bits over the wire that are different, then write the spec for the common parts and note (but do not document) that there are various independent extensions. Treat any effort to document the variations as completely separate from the common core. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 13 22:35:32 2016 Return-Path: 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 39C2912E49A for ; Wed, 13 Apr 2016 22:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 tO_uW75EmMxL for ; Wed, 13 Apr 2016 22:35:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8157612E4C3 for ; Wed, 13 Apr 2016 22:35:27 -0700 (PDT) Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 52A7D22E1F3; Thu, 14 Apr 2016 01:35:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: <570F0928.4020307@dcrocker.net> Date: Thu, 14 Apr 2016 15:35:16 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <694AED88-B641-4FDD-B033-9C038879A062@mnot.net> References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> <570F0057.3030409@dcrocker.net> <570F0928.4020307@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.3124) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 05:35:31 -0000 What do you consider "the wire" for the purposes of the file:// URL = scheme? > On 14 Apr 2016, at 1:06 PM, Dave Crocker wrote: >=20 > On 4/13/2016 7:55 PM, Matthew Kerwin wrote: >> This is why focusing on bits over the wire is better than talking >> about software implementation details. If the 'different ways' = mean >> different bits over the wire, then they are using different = formats >> or different protocols. And they won't interoperate. >>=20 >> If they generate/parse the same bits and same semantics over the >> wire, this we don't care how the built the software to do it, >> because they /do/ interoperate. >>=20 >>=20 >> The 'different ways' are actually different bits over the wire. = Mostly >> those are the bits that weren't part of the original spec, but were >> widely deemed useful/necessary. I've tried to sidestep too much >> controversy by continuing not to specify them, but I did write down = some >> of the ways some folk have decided to represent them. >=20 >=20 > OK. My advice: >=20 > If there is a common core of bits over the wire that they all do = do, but then some /additional/ bits over the wire that are different, = then write the spec for the common parts and note (but do not document) = that there are various independent extensions. >=20 > Treat any effort to document the variations as completely separate = from the common core. >=20 >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Thu Apr 14 03:17:50 2016 Return-Path: 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 EC15712E3A2 for ; Thu, 14 Apr 2016 03:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 BcHHlBsM8zQD for ; Thu, 14 Apr 2016 03:17:43 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BCB12E395 for ; Thu, 14 Apr 2016 03:17:41 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqeKy-0000L2-s6; Thu, 14 Apr 2016 11:17:24 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqeKy-0002Ip-Hs; Thu, 14 Apr 2016 11:17:24 +0100 Message-ID: <570F6E32.5060808@ninebynine.org> Date: Thu, 14 Apr 2016 11:17:22 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham , Dave Crocker References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> <570F0057.3030409@dcrocker.net> <570F0928.4020307@dcrocker.net> <694AED88-B641-4FDD-B033-9C038879A062@mnot.net> In-Reply-To: <694AED88-B641-4FDD-B033-9C038879A062@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:17:49 -0000 I'm not sure if this will help, or just add more noise, but... TL;DR: I don't think the "over the wire" issue should be elevated to the level of dogma. Systems are more complicated than that. ... For me, as a developer, the value of a file:// URI is not what gets sent "over the wire", but what does *not* get sent over the wire. I mainly work on applications for "small data" (but very heterogeneous). I create data that can be served on the web, or locally from a file system. The data itself is location agnostic (i.e. portable), and internally uses relative URI references. The existence of file: URIs is important to this mechanism because they can be used locally as a base URI to access data that is stored locally. So why do I feel the file: is an important specification that impacts interoperability in a network protocol suite? 1. it can be used uniformly as part of a structure that does operate predominantly over the network. 2. It can be used to provide a local context for interpreting data that *has* been sent "over the wire". This is why I have said that (for me at least), the most important part of the file: URI spec is that it behaves consistently with respect to URI resolution. #g -- On 14/04/2016 06:35, Mark Nottingham wrote: > What do you consider "the wire" for the purposes of the file:// URL scheme? > > >> On 14 Apr 2016, at 1:06 PM, Dave Crocker wrote: >> >> On 4/13/2016 7:55 PM, Matthew Kerwin wrote: >>> This is why focusing on bits over the wire is better than talking >>> about software implementation details. If the 'different ways' mean >>> different bits over the wire, then they are using different formats >>> or different protocols. And they won't interoperate. >>> >>> If they generate/parse the same bits and same semantics over the >>> wire, this we don't care how the built the software to do it, >>> because they /do/ interoperate. >>> >>> >>> The 'different ways' are actually different bits over the wire. Mostly >>> those are the bits that weren't part of the original spec, but were >>> widely deemed useful/necessary. I've tried to sidestep too much >>> controversy by continuing not to specify them, but I did write down some >>> of the ways some folk have decided to represent them. >> >> >> OK. My advice: >> >> If there is a common core of bits over the wire that they all do do, but then some /additional/ bits over the wire that are different, then write the spec for the common parts and note (but do not document) that there are various independent extensions. >> >> Treat any effort to document the variations as completely separate from the common core. >> >> >> d/ >> >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Apr 14 03:21:01 2016 Return-Path: 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 4F06112DD6D for ; Thu, 14 Apr 2016 03:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 HHck7wA1uIAT for ; Thu, 14 Apr 2016 03:20:59 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C584512DD26 for ; Thu, 14 Apr 2016 03:20:58 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1aqeOD-0003cb-bY; Thu, 14 Apr 2016 11:20:45 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.103]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aqeOD-0001dZ-KK; Thu, 14 Apr 2016 11:20:45 +0100 Message-ID: <570F6EFB.9050209@ninebynine.org> Date: Thu, 14 Apr 2016 11:20:43 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Mark Nottingham , General discussion of application-layer protocols References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> In-Reply-To: <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Dave Crocker Subject: Re: [apps-discuss] Experimental (was - Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:21:01 -0000 On 14/04/2016 01:02, Mark Nottingham wrote: > Is there a test suite or other data to validate the decisions made? Not specifically that I know of, but there are test suites for URIs in general that describe resolution behaviours that file:// URIs should conform to by virtue of following rules set out by RFC3986. #g -- From nobody Thu Apr 14 06:49:30 2016 Return-Path: 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 4846812D640 for ; Thu, 14 Apr 2016 06:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 BaL07uVwuYe8 for ; Thu, 14 Apr 2016 06:49:28 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AFA12D6C8 for ; Thu, 14 Apr 2016 06:49:25 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u3EDnOE7009150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Apr 2016 06:49:25 -0700 References: <20160413200825.15190.qmail@ary.lan> <14F6E2A0-8F9A-4855-9DA3-BBA383196790@mnot.net> <570F0057.3030409@dcrocker.net> <570F0928.4020307@dcrocker.net> <694AED88-B641-4FDD-B033-9C038879A062@mnot.net> To: Mark Nottingham From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <570F9FE4.7010405@dcrocker.net> Date: Thu, 14 Apr 2016 06:49:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <694AED88-B641-4FDD-B033-9C038879A062@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 14 Apr 2016 06:49:25 -0700 (PDT) Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Experimental (was - Re: Review of draft-ietf-appsawg-file-scheme) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:49:29 -0000 On 4/13/2016 10:35 PM, Mark Nottingham wrote: > What do you consider "the wire" for the purposes of thefile:// URL scheme? the bits that are exchanged 'between' producer and consumer. by whatever mechanism does that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 14 23:32:56 2016 Return-Path: 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 6DA7012DFB8; Thu, 14 Apr 2016 23:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V9MtJWb8a_sS; Thu, 14 Apr 2016 23:32:53 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1529D12DFAB; Thu, 14 Apr 2016 23:32:53 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id kb1so5629897igb.0; Thu, 14 Apr 2016 23:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=qna0XoOS73oABzfY7/F/ZplcbBBWXNfz3q24T0YEsu0=; b=UoG7sPhlfU96subdLZ6qQbmZnGWUhUmps3wHgiHt42rEuUcGoEv9h26P/gC9fYkAXw y+l0krdLNLbkfxedBzuXND7wVFDjooHsw5BPjaBx4tobOAItDczvo4aGJv9gy8yaSfvi i+nHZYG5mZGn97wGJi9DeYi6rwR+z9ZLLuXhssWw9Ty9ryac5mJmGUpZYJxSpuBXAttX vOSXEj1s3CdVCs4yN1gurwyxPGNNI9cdWqo+ULvKZGi7cS7PunBNGkRhuq8EJNc+3vDf tl2Y76yDgE2rdylLYqGUHQzZn0EiOLzb1NV2/u4BM6xnrl/kdV2zKL6RyTPXs+NLL5vc UZhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qna0XoOS73oABzfY7/F/ZplcbBBWXNfz3q24T0YEsu0=; b=FpseiaNsY7tRWdO2Y9nbtcSj/8Ac/gyAsNHMNL+EX/e61UGd8m2WF/V8Rs1f4GMBNP pLva79Po89QE/cNUVd6osGy7t/arr5RlA0MrI4qTw60SQJAKiFy9Yf0aML6We6u4Dth8 uIECecwOdrasIptF9KOvyUTLEUH5A36pF88LjNkucyXaKB1MIaZd6nwHJKA5AHIovpVD znphi4bT/q81kFGw7dn/tL+REny4aBuzQ1s+5NtI0XZZsNWTvpwJW0mP7vCDRVcPZ8QY zcjHx4DdgRcKc3OWmyJTypysZprv59dRB9Rtofl8viraD1vfZNC8Z1LDt0jpCf45Sna4 2wBw== X-Gm-Message-State: AOPr4FURi9k+dATnvbtLDwuWhvlf9rSBLAliIf2M4jIF15OdtNt5Yx8u4TdJy8QYkeWBR6cldqpcriwvzIMaiw== MIME-Version: 1.0 X-Received: by 10.50.27.39 with SMTP id q7mr2928975igg.34.1460701972302; Thu, 14 Apr 2016 23:32:52 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Thu, 14 Apr 2016 23:32:52 -0700 (PDT) In-Reply-To: <570E267A.2070801@ninebynine.org> References: <570D4C99.1030405@dcrocker.net> <570E267A.2070801@ninebynine.org> Date: Fri, 15 Apr 2016 16:32:52 +1000 X-Google-Sender-Auth: 1xUeRAFSrRel2eduVUIEIkpa_qI Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7b10ce152e94110530802ec6 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker , Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 06:32:55 -0000 --047d7b10ce152e94110530802ec6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 April 2016 at 20:59, Graham Klyne wrote: > On 13/04/2016 09:28, Matthew Kerwin wrote: > >> 2. Append the transformed segment and a delimiting slash >>> >>>> >> character "/" to the URI. >>>> >> >>>> >> 6. If the path includes a file name: >>>> >> >>>> >> 1. Transform the file name to a path segment as above. >>>> >> >>>> >> 2. Append the transformed segment to the URI. >>>> >> >>>> >>> > >>> >A slash is required at the end of a directory, even if there is no fil= e >>> >name? >>> > >>> > >>> >> If you're using it as a directory then yes. If you're using it as the >> ultimate object (the "file") then no. We defined "file" as an "object" i= n >> the file system earlier, which (going with the UNIX interpretation that >> everything is a file) can include directories. As far as I know most >> non-UNIXy systems around today can deal with this interpretation too. >> Should I spell it out, or leave it up to interpretation? >> >> > I'd also say "yes". > > This is an area where URI resolution works differently to file path > resolution (on some systems), so it's not just an academic point. > > If you don't include the trailing "/" on a directory used as a base URI, > then the final directory segment gets dropped when performing URI > resolution. > > Developers working in this space will know this anyway, but I think it's > important. > > =E2=80=8BThat's a good point. In my working copy I've added this as a footn= ote to the algorithm: "" Some file systems allow directory objects to be treated as files in some cases. This can be reflected in a file URI by using the name of the ultimate directory as the file name (such that the URI does not have a trailing slash "/"). Be aware that merging a relative URI reference to such a base URI as per Section 5.2 of [RFC3986] could remove the directory name from the resulting target URI. "" Editorially a footnote might not be the best way to do it, but it gets the words in there. Does that cover it? Also, "file:///home/user" and "file:///home/user/" are different URIs per > RFC3986. It's usially a good idea to avoid gratuitous URI aliasing, whic= h > suggests it would be good practice to always include the trailing "/". > > It's true that they are different URIs; in the same way https://example.com/foo and https://example.com/foo/ are different URIs. In that case it's the webserver itself that redirects a request for the former to the latter. I don't know if we really need to say anything more about it here, especially since we've pointed out an actual functional difference. --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7b10ce152e94110530802ec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 13 April 2016 at 20:59, Graham Klyne <gk@ninebynine.= org> wrote:
On 13/04/201= 6 09:28, Matthew Kerwin wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2.=C2=A0 Append the transformed segment and a d= elimiting slash
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 character "/" t= o the URI.
>>
>>=C2=A0 =C2=A0 6.=C2=A0 If the path includes a file name:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 1.=C2=A0 Transform the file name to a p= ath segment as above.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 2.=C2=A0 Append the transformed segment= to the URI.
>>
>
>A slash is required at the end of a directory, even if there is no file=
>name?
>
>
If you're using it as a directory then yes. If you're using it as t= he
ultimate object (the "file") then no. We defined "file"= as an "object" in
the file system earlier, which (going with the UNIX interpretation that
everything is a file) can include directories. As far as I know most
non-UNIXy systems around today can deal with this interpretation too.
Should I spell it out, or leave it up to interpretation?


I'd also say "yes".

This is an area where URI resolution works differently to file path resolut= ion (on some systems), so it's not just an academic point.

If you don't include the trailing "/" on a directory used as = a base URI, then the final directory segment gets dropped when performing U= RI resolution.

Developers working in this space will know this anyway, but I think it'= s important.


=E2=80=8BThat's a good po= int. In my working copy I've added this as a footnote to the algorithm:=

""
Some file syst= ems allow directory objects to be treated as files
in some ca= ses.=C2=A0 This can be reflected in a file URI by using the
n= ame of the ultimate directory as the file name (such that the URI does
not have a trailing slash "/").=C2=A0 Be aware that mer= ging a relative URI
reference to such a base URI as per Secti= on 5.2 of [RFC3986] could
remove the directory name from the = resulting target URI.
""

Editorially a footnote might not be the best way to do it, but it ge= ts the words in there. Does that cover it?


Also, "file:///home/user" and "file:///home/user/" are = different URIs per RFC3986.=C2=A0 It's usially a good idea to avoid gra= tuitous URI aliasing, which suggests it would be good practice to always in= clude the trailing "/".


It's true that they are different URIs;= in the same way https://example.com/fo= o and https://example.com/foo/= are different URIs. In that case it's the webserver itself that redire= cts a request for the former to the latter. I don't know if we really n= eed to say anything more about it here, especially since we've pointed = out an actual functional difference.

--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--047d7b10ce152e94110530802ec6-- From nobody Fri Apr 15 00:10:31 2016 Return-Path: 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 D162612D806; Fri, 15 Apr 2016 00:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1VARQNUESFko; Fri, 15 Apr 2016 00:10:28 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB7612DBFB; Fri, 15 Apr 2016 00:10:15 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 2so126926194ioy.1; Fri, 15 Apr 2016 00:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=U+HU7AA5Kbjb3I9o1TI/6KnQC3KmiT1wUlr6tI4yEc8=; b=irLN9rnPgZGlBijNCF+Rv+nd3/SbJ93+0+v/MR+gCi60dz5Rz29CJt4f2mLsVinKV8 yji+EXlgMhOhUdHd8J2PnWHwdHr+XKBNlbou3ni19SeLZXK4w65yphQUq2Tpstyk+bg9 xYagqbS1NU3hyqLsk0a0Q+sGc2BkG65dglT37sIHxLd145Hcwp8t5qLPsXe2uixqhlMW kdutojH0Eekb0+jiiqNSJJryNvHTr8AII43YYnSCGclxqmnT5WNp1Nk5ya/pt4ugznJp R/A2SQpqGCuEO9b+PTBP00u6Xh6uiau9lZoAbeaYW64fkEEN2gOAT2lnLzTSKPGHhiBX RyRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=U+HU7AA5Kbjb3I9o1TI/6KnQC3KmiT1wUlr6tI4yEc8=; b=CplDIBiigzYKQ7FyG3BZHQZyPRAdip4X3iifp5ZytlVJBAH9QZbdtYD5Fg9at/DdJe wK7gvPwzpv5HHlL98Fme3b7px3uizO4FZRGL1D1FjpoczHlXYQeFR5+pA2hZ6idxlQ/f ueak8Z9JyGCQY8VwAF2Kyq8bBbAztfQnimnQHRKae6N98pyD4u5Eh01JLKTUzQ8MwKiW 6gixMEGyooBuZOKKoVti6PdjHDG50cPaxKl4zTlLcCYio1mJT9B1XuEidyso8d1QI4xj MRNILmNEwSRshlbB+unfb8EvJsd5PMKCbXbFsmM3JwMNLOBPWMAOSV9+PMjddaXPeF5a aMPA== X-Gm-Message-State: AOPr4FWg4BSzz0JAdzhJLHHl7YzoXl1RkZ1UezC5hfdIm2uQYLkl5e/Blc+UkS8n6WVRoTVJj5amVUYy9bidKA== MIME-Version: 1.0 X-Received: by 10.107.15.159 with SMTP id 31mr20345189iop.3.1460704214274; Fri, 15 Apr 2016 00:10:14 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.166.78 with HTTP; Fri, 15 Apr 2016 00:10:14 -0700 (PDT) In-Reply-To: <570E2510.4040408@ninebynine.org> References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> Date: Fri, 15 Apr 2016 17:10:14 +1000 X-Google-Sender-Auth: cixo86svRJR24LQ7fOteQ_4NjN0 Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=001a113ee868d07ac7053080b39c Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker , Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 07:10:30 -0000 --001a113ee868d07ac7053080b39c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13 April 2016 at 20:53, Graham Klyne wrote: > =E2=80=8B=E2=80=8B > > (Local interpretation may not be, but I'd suggest that's a local > implementation issue. At most, make a note as a local handling issue in > the appendices? Hmmm... are there any security considerations here that > should be flagged - relating to possible unexpected aliasing from case-on= ly > differences between files.) > > I think the talk about case-sensitivity is worthwhile keeping inline, even if it's touching on system-specific issues. Regarding security considerations, I've added some tentative hand-waving: "" Some file systems have case-sensitive file naming and some do not. Care must (?) be taken to avoid issues resulting from possibly unexpected aliasing from case-only differences between file paths or URIs. "" I'm open to suggestions for improvement (or deletion.) Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a113ee868d07ac7053080b39c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 13 April 2016 at 20:53, Graham Klyne <gk@ninebynine.org><= /span> wro= te:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
=E2=80=8B=E2=80=8B

(Local interpretation may not be, but I'd suggest that's a local im= plementation issue.=C2=A0 At most, make a note as a local handling issue in= the appendices? Hmmm... are there any security considerations here that sh= ould be flagged - relating to possible unexpected aliasing from case-only d= ifferences between files.)


I think the talk about case-sensitivity is worthwhile keeping inline, e= ven if it's touching on system-specific issues.

Regarding security considerations, I've added some tentative = hand-waving:

""
<= div class=3D"gmail_default">Some file systems have case-sensitive file nami= ng and some do not.
Care must (?) be take= n to avoid issues resulting from possibly
unexpected aliasing from case-only differences between file paths or
=
URIs.
""

I'm open to suggestions for improvement (or d= eletion.)

Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.= net.au/
--001a113ee868d07ac7053080b39c-- From nobody Fri Apr 15 00:17:28 2016 Return-Path: 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 F378A12E09F; Fri, 15 Apr 2016 00:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Bw7GfyOMUSYa; Fri, 15 Apr 2016 00:17:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A17E12E049; Fri, 15 Apr 2016 00:17:25 -0700 (PDT) Received: from [192.168.178.20] ([93.217.126.86]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LwZtX-1bqF3s35zz-018Mwb; Fri, 15 Apr 2016 09:16:19 +0200 To: Matthew Kerwin , Graham Klyne References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> From: Julian Reschke Message-ID: <5710953E.5040505@gmx.de> Date: Fri, 15 Apr 2016 09:16:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Xv1fTtG/WjZMz9eItMJnMNwazZ11Gql//kEkzr1WSUGuuA4KNxo PCawxxoBXjoqhmmYebo7wyamiAlrWHpgK57Z2ZIHO62lVVRn7PTWxVQEyziS9Xcm1pwrKIf q/JkAPzopl5RvW/jHPVcsL0Wfyljnzq97NgQt9rOktUAcAjGLD3gcHoGx683/mMJIpEs2Zp ZoCEWkOJ5aa3KG+4Nwgyg== X-UI-Out-Filterresults: notjunk:1;V01:K0:lDbsnlhxwdk=:DTBbY89rSVHDeRHKm93zcD nC4OHyWrN/Ui5XufVLUpFdeiEhtPu0GqLp8qz6cVLS/5PAOL2LJYZQWONIzThY+YR7C+kyRe4 OZHaPkVajRtsqBcJJkGV8XB52/FPXb74LKt+AMof/8fnltM4ppX8i9lm1n6yj3DKGmbprdVR4 Li6VDP9Tr+U7n7m9tcheR8UptesgiUH0HRkkxDR4NNJTW+N3MmqxpWok/mBgbP/Rwn6xTTcHj 70o5jNWRyQjMxevgE6IlKz4dUm4fSkv28yI2gfMqHZrwdAN/wvzZFtvHN3fBOfATRP/gackD3 Bbvt0s86bgigbjustjT3a7ygGYuZJpkQPgz0+lX43P3Yr7YQ1cYJTN+tT41bp7CMr3P0cG91Z iebjAe5nDGxE7R4zcHqvp2LMKG8BsLpnL/ARYN4NblBhgNSk3aVFHZr5OnxQXW5C3dVPstCSt M5SoHTOjsrTrkw34n1B4SnZwY6VVbbTV6eE0vuYRP420WQ8jE7YrVWmC0AatdTZUgw9zC7XDV PjpRGTIgLkLUxjqK5QY8wl9r0AnssKVTXbqpx00LQpRTrIP84rZTGOp6BS4/oZtojyMDe9ME2 AOS6PA0vNxfZ65KrIrFZnWswYsxqcAhkWRgWXxOaD9LjC9HWJyQ34xDRPq+GvXvNQ+5FmxTr+ i8v8lFy3LbUS9YDRDEbpRhTKivOjYX4SrSNzG9oeIruRlSBgnDTNcyztf6VeTbXkG61lSJN0p ZH+KeEo6BJM3Zm2HNyOHbzm2H03Y/25h3nr+xGCQCG8JEzBLyELkJi4Ohj2Pa7tJgDTxmzQ8e IRPmnqP Archived-At: Cc: Apps Discuss , Dave Crocker , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 07:17:27 -0000 On 2016-04-15 09:10, Matthew Kerwin wrote: > On 13 April 2016 at 20:53, Graham Klyne >wrote: > > ​​ > > (Local interpretation may not be, but I'd suggest that's a local > implementation issue. At most, make a note as a local handling > issue in the appendices? Hmmm... are there any security > considerations here that should be flagged - relating to possible > unexpected aliasing from case-only differences between files.) > > > I think the talk about case-sensitivity is worthwhile keeping inline, > even if it's touching on system-specific issues. > > Regarding security considerations, I've added some tentative hand-waving: > > "" > Some file systems have case-sensitive file naming and some do not. > Care must (?) be taken to avoid issues resulting from possibly > unexpected aliasing from case-only differences between file paths or > URIs. > "" > > I'm open to suggestions for improvement (or deletion.) case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive (others) ...so maybe mention all the three cases. Best regards, Julian PS: it might also be good to touch Unicode normalization forms... From nobody Fri Apr 15 04:15:07 2016 Return-Path: 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 787E212D565 for ; Fri, 15 Apr 2016 04:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 SkNOfdnDLdln for ; Fri, 15 Apr 2016 04:15:04 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A23D12D688 for ; Fri, 15 Apr 2016 04:15:04 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1ar1iD-0004JB-gN; Fri, 15 Apr 2016 12:14:57 +0100 Received: from modemcable171.142-37-24.static.videotron.ca ([24.37.142.171] helo=[192.168.55.105]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ar1iC-00052t-MB; Fri, 15 Apr 2016 12:14:57 +0100 Message-ID: <5710CD2D.6040103@ninebynine.org> Date: Fri, 15 Apr 2016 12:14:53 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <570D4C99.1030405@dcrocker.net> <570E267A.2070801@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Dave Crocker , Apps Discuss Subject: [apps-discuss] New information relating to 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 11:15:06 -0000 Yesterday, in discussion with one of the original authors of RFC 1738, I learned something about file:// URIs that I had not previously realized. The upshot of this for me, in particular with references to Mark Nottingham's comment (https://mailarchive.ietf.org/arch/msg/apps-discuss/pZG6iMoerYpa5qq6BkHa8j0Nfjo), is that there may be parts of this spec that go beyond the clarification exercise required to maintain file:// URI scheme as a standard-track specification. I offer a new (not detailed) review with suggestions for elements that might be dropped, in the hope that what remains is truly just a clarification rather than a modification of the RFC1732 description of file:// URIs. (My own experience and use of file:// URIs is not affected by what I learned, and in my previous reviews have assumed that contributions relating to UNC files in particular were based on appropriate knowledge or experience.) ... I have learned that the intent of including a hostname component was *not* to allow some kind of cross-host file access to be invoked, but to act as a signal to software using the URI that was not running on the specified host that the corresponding resource was not dereferencable. This is supported by, or at least consistent with, a close reading of the relevant text in https://tools.ietf.org/html/rfc1738#section-3.10: [[ A file URL takes the form: file:/// where is the fully qualified domain name of the system on which the is accessible, and is a hierarchical directory path of the form //.../. ]] Also, RFC 1630 is more explicit that the file scheme is for *local* file access. The following from https://tools.ietf.org/html/rfc1630 is much clearer about this than RFC1738: [[ file The other URI schemes (except nntp) share the property that they are equally valid at any geographical place. There is however a real practical requirement to be able to generate a URL for an object in a machine's local file system. The syntax is similar to the ftp syntax, but in this case the slash is used to donate boundaries between directory levels of a hierarchical file system is used. The "client" software converts the file URL into a file name in the local file name conventions. This allows local files to be treated just as network objects without any necessity to use a network server for access. This may be used for example for defining a user's "home" document in WWW. There is clearly a danger of confusion that a link made to a local file should be followed by someone on a different system, with unexpected and possibly harmful results. Therefore, the convention is that even a "file" URL is provided with a host part. This allows a client on another system to know that it cannot access the file system, or perhaps to use some other local mecahnism to access the file. The special value "localhost" is used in the host field to indicate that the filename should really be used on whatever host one is. This for example allows links to be made to files which are distribted on many machines, or to "your unix local password file" subject of course to consistency across the users of the data. A void host field is equivalent to "localhost". ]] Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-06 again in light of this, I have the following comments: ... Section 1: [[ This document defines a syntax that is compatible with most extant implementations, while attempting to push towards a stricter subset of "ideal" constructs. In many cases it simultaneously acknowledges and deprecates some less common or outdated constructs. ]] I don't think "deprecates" is right here, as it doesn't discourage any behaviours specifically allowed by RFC1732. (cf. Mark's comment.) ... Section 1.2: It now seems to me that the role of a host name in UNC name is quite different to its (original) role in a file:// URI. In light of this, should this section be dropped? ... Section 2: [[ file-auth = [ userinfo "@" ] host ]] The inclusion of "userinfo @" is an extension to previous *specifications* of the file URI. As such, I question whether this change should be included. Dropping it doesn't affect compatibility with RFC3986. ... Section 3: [[ This specification neither defines nor forbids a mechanism for accessing non-local files. See SMB [MS-SMB], NFS [RFC7530], NCP [NOVELL] for examples of protocols that can be used to access files over a network. Also see Appendix C.2 for a non-normative discussion on translating non-local file URIs to and from UNC strings. ]] Given the new information noted, this seems extraneous to me. Suggest dropping. ... Section 3.1: There is an option to include the host name even for local files, as an indication that the same file should not be expected to exist on other hosts. I think the default position, in practice, is to not specify a host name. But if the applications expects that the full absolute URI may be passed to another system it may make sense to include it to avoid dereferencing the value in an inappropriate context. ... Section 3.2: Given the new information noted, this section seems extraneous to me. Suggest dropping. ... Section 4: Given the new information, the discussion of encoding when sending a file URI to a different system seems less relevant. I would be inclined to drop all but the first paragraph of this section. ... Section 6: If the userinfo option is removed (see above), the final paragraph becomes moot. Suggest drop. ... Appendix A: The characterization of "local" and "non-local" files isn't really germane. Suggest drop the sub-categorization and just list the examples. ... (I'm not reviewing Appendices B and C at this time, as they aren't affected by my new perspective.) ... #g -- From nobody Sat Apr 16 08:20:58 2016 Return-Path: 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 DA01912DA3D for ; Sat, 16 Apr 2016 08:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it 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 SHkNxzL6ylKq for ; Sat, 16 Apr 2016 08:20:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F30312D9FC for ; Sat, 16 Apr 2016 08:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1460820052; bh=kQQrA5Ott3LdFxpdPTu/VJi8YTa/GV20dUkPjpwxbAo=; l=1920; h=To:References:Cc:From:Date:In-Reply-To; b=sJdf//R/Gzh64QZNs6eO5VUpsoiUQ3FjBDZeiZunTB/cWSqcFNnxUhc/uOveOuFWn ldU8u6z+bNQJTpkkQRGvzMbYh7pRyfaguWoKer7/d4fUOUNePzoapkum7t8lW/hGfk bEbB0Y4KZGnVldrp1ildSEIkNMDEZ5/E56BSJzxE= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 16 Apr 2016 17:20:52 +0200 id 00000000005DC050.0000000057125854.0000099C To: "Murray S. Kucherawy" References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> <570E8985.7080708@tana.it> From: Alessandro Vesely Message-ID: <57125854.2030307@tana.it> Date: Sat, 16 Apr 2016 17:20:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: Matthias Leisi , AppsAWG , iana-prot-param-comment@iana.org Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 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, 16 Apr 2016 15:20:58 -0000 On Wed 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote: > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely wrote: > >> I still don't think it is worth publishing the I-D, but maybe IETF's list >> archives can be considered permanent documents, which can be referenced by >> items added after Expert Review, no? > > That seems... unconventional at least. I would rather see something > published. Going via the ISE, if you're worried about the slog through the > IETF Stream, seems like a perfectly viable option. I think that is called RFC Required, not Expert Review. >>> I had a look at your -04. Thank you for addressing most of my comments >>> and suggestions; it's certainly better. A few non-editorial issues >>> remain: >>> >>> - The original ptype.property list has not been updated as discussed, >>> so the main problem remains. >> >> The "dns" ptype has its own table there. Added a more text. I don't think >> this is a useless ptype, since so much stuff is DNS-based... > > I explained in my previous replies why I don't think "dns" is a viable > choice for a ptype. I never said it was "useless", but it doesn't fit > within the framework described by RFC7601 or its antecedents. I proposed > an alternative that I claim does fit. Have you rejected it? Yes, I rejected your proposal to use policy.zone=lists.dnswl.example, because it disagrees with the only existing implementation. When that was discussed, the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is a zone in the DNS, according to, say, RFC5782. Nobody realized that "dns" is not a valid RFC7601 ptype (and I still don't understand why). Since I'm neither the maintainer of the existing implementation, nor the only user of that feature, I cannot change the syntax arbitrarily. Making a registration that disagrees with the terrain seems pointless to me. Ale From nobody Sat Apr 16 08:38:28 2016 Return-Path: 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 52A6E12E3CC for ; Sat, 16 Apr 2016 08:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 26BIxFDmoqGq for ; Sat, 16 Apr 2016 08:38:26 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB04E12E3C7 for ; Sat, 16 Apr 2016 08:38:25 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c4so178752832vkb.3 for ; Sat, 16 Apr 2016 08:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9h3nbtqvNXZusM5xkq98UPM7+VWgoPfnHYZCO342RlI=; b=KBQA4EWvOVQa4M3q+Ji9w//kl93FeoEhPdI1x7m8HGV2ZXaOnnXGLsmIpN84mO9PEj rFoAn1SsCeRk9M/q4EPuz9XgIP0DY6amm7GAjLFDMDj6j13Ay8g11PLMZekFeYAqtO/I sZdawwCmqij1fsCvrRnnmlY4HrOXAVxel9AUNhtHYkvzhrvhC7JPI3jcN/1qbgdb8zC1 bsMg50NkOA3rJMdRW7PN20mjnGfQ6zEtKBhxLgzyu6Tju4AenKSeAFdZqKXtMddCfIU9 p782q15z/5riwzXCGmUnNDX6AXEThoF3iS5dqghyNquBFiMoX6NeX84juKWcJO5kJbfd HL/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9h3nbtqvNXZusM5xkq98UPM7+VWgoPfnHYZCO342RlI=; b=OKkrvppc3dYMtAfIWrlKjvG77bm9vIxi0N+2jAZs6zqxVUm4jF/FWIFZ8djEfeoJck SRWTQvSv9QWotCqMfA+B+VAjAGEuWsYWMMpxUponTEM2SlG4ONZtyDsJeA8mXTSXFGgy cX7Y87D01NfuzuPULfxk73JvBgA5Xb+hita+XRJ7a29cvUFL+uuNHuRnw4BIq5tv46+V /XzyueC2yYrltHSDYPshGzsq9tR6Ws1I+w4RP0avCoGZ+ySMiOmdaMV83Jm/YNVaQSIB R/67CZSbunGpXmYyED0ZcsBDX5En9RmrUpYMLCaEacMk0SaJSxC2eLOr4rPoKeDM0GDN T2ZA== X-Gm-Message-State: AOPr4FXsXJZrVZerNX8y+kUF8YQD8K91/hzxpz6Jgu4sAXDGN0mgB/bT7m0Ac0OzL6pW7jNW9p40bE/Y74TX0g== MIME-Version: 1.0 X-Received: by 10.159.54.239 with SMTP id p102mr1188483uap.99.1460821104810; Sat, 16 Apr 2016 08:38:24 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Sat, 16 Apr 2016 08:38:24 -0700 (PDT) In-Reply-To: <57125854.2030307@tana.it> References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> <570E8985.7080708@tana.it> <57125854.2030307@tana.it> Date: Sat, 16 Apr 2016 08:38:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=94eb2c04cbba0865e105309beb04 Archived-At: Cc: Matthias Leisi , AppsAWG Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 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, 16 Apr 2016 15:38:27 -0000 --94eb2c04cbba0865e105309beb04 Content-Type: text/plain; charset=UTF-8 [dropping the IANA address because it keeps creating tickets in their system] On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely wrote: > On Wed 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote: > > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely > wrote: > > > >> I still don't think it is worth publishing the I-D, but maybe IETF's > list > >> archives can be considered permanent documents, which can be referenced > by > >> items added after Expert Review, no? > > > > That seems... unconventional at least. I would rather see something > > published. Going via the ISE, if you're worried about the slog through > the > > IETF Stream, seems like a perfectly viable option. > > I think that is called RFC Required, not Expert Review. > It would if I had asserted that you have to publish an RFC, but that's not what I said. I was making a suggestion about one way to publish it, and since you already have a draft, you're part way there. Yes, I rejected your proposal to use policy.zone=lists.dnswl.example, > because > it disagrees with the only existing implementation. When that was > discussed, > the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is a > zone in > the DNS, according to, say, RFC5782. Nobody realized that "dns" is not a > valid > RFC7601 ptype (and I still don't understand why). > I've gone over the "why" with you at some length both at the Berlin meeting and now on a thread subsequent to your request to IANA. While I'm sympathetic to some degree with the "installed base" argument, I don't think it's reasonable to accept a registration that doesn't fit within the defining RFC merely because there's a single existing incorrect implementation. -MSK --94eb2c04cbba0865e105309beb04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[dropping the IANA address because it keeps creating ticke= ts in their system]

On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vese= ly <vesely@tana.it> wrote:
On Wed= 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote:
> On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely <vesely@tana.it> wrote:
>
>> I still don't think it is worth publishing the I-D, but maybe = IETF's list
>> archives can be considered permanent documents, which can be refer= enced by
>> items added after Expert Review, no?
>
> That seems... unconventional at least.=C2=A0 I would rather see someth= ing
> published.=C2=A0 Going via the ISE, if you're worried about the sl= og through the
> IETF Stream, seems like a perfectly viable option.

I think that is called RFC Required, not Expert Review.

It would if I had asserted that you have to publish= an RFC, but that's not what I said.=C2=A0 I was making a suggestion ab= out one way to publish it, and since you already have a draft, you're p= art way there.

Yes, I rejected your proposal to use policy.zone=3Dlists.dnswl.example, bec= ause
it disagrees with the only existing implementation.=C2=A0 When that was dis= cussed,
the syntax dns.zone=3Dlists.dnswl.example was chosen because a DNSxL is a z= one in
the DNS, according to, say, RFC5782.=C2=A0 Nobody realized that "dns&q= uot; is not a valid
RFC7601 ptype (and I still don't understand why).
=
I've gone over the "why" with you at some leng= th both at the Berlin meeting and now on a thread subsequent to your reques= t to IANA.

While I'm sympathetic to some degree with the "i= nstalled base" argument, I don't think it's reasonable to acce= pt a registration that doesn't fit within the defining RFC merely becau= se there's a single existing incorrect implementation.

-MSK
--94eb2c04cbba0865e105309beb04-- From nobody Sat Apr 16 09:10:57 2016 Return-Path: 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 3565112D717 for ; Sat, 16 Apr 2016 09:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 MfNRg6ajUQKy for ; Sat, 16 Apr 2016 09:10:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9C912D133 for ; Sat, 16 Apr 2016 09:10:51 -0700 (PDT) Received: from [192.168.111.103] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 08817C40152; Sat, 16 Apr 2016 11:10:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1460823049; bh=zI/QO8bkOGSbHRmn7bxUBJ3YScj8bsaAvte8RZlTrdM=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=ZY/SxYIQl/DUL3poeK47ozNof/oycj8SWy8ZFn9BPEMSdUvDj30liRjHoYldn4rtd Gj9j0zWNj0uCONLpd5x47UpuVlaojsw3HUdcUGF3Z4rySLiSHlogAynotQheZZJrjH Dg9kkYGeKnLP0dbKX9NW24ytpnlB52YNb4rANndE= User-Agent: K-9 Mail for Android In-Reply-To: References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> <570E8985.7080708@tana.it> <57125854.2030307@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 16 Apr 2016 12:10:47 -0400 To: "Murray S. Kucherawy" , Alessandro Vesely Message-ID: Archived-At: Cc: Matthias Leisi , AppsAWG Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 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, 16 Apr 2016 16:10:54 -0000 On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" wrote: >[dropping the IANA address because it keeps creating tickets in their >system] > >On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely >wrote: > >> On Wed 13/Apr/2016 20:15:04 +0200 Murray S. Kucherawy wrote: >> > On Wed, Apr 13, 2016 at 11:01 AM, Alessandro Vesely > >> wrote: >> > >> >> I still don't think it is worth publishing the I-D, but maybe >IETF's >> list >> >> archives can be considered permanent documents, which can be >referenced >> by >> >> items added after Expert Review, no? >> > >> > That seems... unconventional at least. I would rather see >something >> > published. Going via the ISE, if you're worried about the slog >through >> the >> > IETF Stream, seems like a perfectly viable option. >> >> I think that is called RFC Required, not Expert Review. >> > >It would if I had asserted that you have to publish an RFC, but that's >not >what I said. I was making a suggestion about one way to publish it, >and >since you already have a draft, you're part way there. > >Yes, I rejected your proposal to use policy.zone=lists.dnswl.example, >> because >> it disagrees with the only existing implementation. When that was >> discussed, >> the syntax dns.zone=lists.dnswl.example was chosen because a DNSxL is >a >> zone in >> the DNS, according to, say, RFC5782. Nobody realized that "dns" is >not a >> valid >> RFC7601 ptype (and I still don't understand why). >> > >I've gone over the "why" with you at some length both at the Berlin >meeting >and now on a thread subsequent to your request to IANA. > >While I'm sympathetic to some degree with the "installed base" >argument, I >don't think it's reasonable to accept a registration that doesn't fit >within the defining RFC merely because there's a single existing >incorrect >implementation. While I normally give pragmatic arguments (like alignment to existing practice) a lot of weight, in this case I agree with Murray that it would be a mistake. If you look at the discussion of iprev in http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same ground as this proposal with regards to ptype selection. I believe it's clear that policy is the correct choice. In order to add the proposed new ptype, I think the ptype definition in http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed and that would require a standards track update to RFC 7601. I don't think you want to go down that path. Scott K From nobody Sun Apr 17 22:13:09 2016 Return-Path: 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 364C912E029 for ; Sun, 17 Apr 2016 22:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OpD0sSG2Zl35 for ; Sun, 17 Apr 2016 22:13:02 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E439712E024 for ; Sun, 17 Apr 2016 22:13:01 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id g8so71097342igr.0 for ; Sun, 17 Apr 2016 22:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=yTfsSjrtgUs8pCyJ5V3+xwWF/j0SPsDrgOSeCp86Pxo=; b=r+0CiZ92Ldk/lX0PN2FmfIZWujE90ZNUaRxI8SMoz5uK33KYO7bNjpmRHhTBEzej2D MZMoM/3NeQMt4hdmha5kvXFG++gQmWNrAQPpJEU6PoO20KNq8c4dvJJuCbdOkxrxtQx4 18+xm6kFhWkeGq1boZKgM7UhbtTpAsdekQGHzUwt7E2DB6yfXwqwznLZAXo7lT3lV0rT 3edMNPdFjcfc1rOrCxU/4trUsQj1Ym/gqzAT+3b3SXfSQxilpw/tYKBpVHtp7KgH1fPY 1vEiRmgrEB1+xCWzMpEh5sig9rbi1eX5eAjPH+ztr51lWxokNuqwFibcSabF42Ws4zGR EA2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yTfsSjrtgUs8pCyJ5V3+xwWF/j0SPsDrgOSeCp86Pxo=; b=gAm0xLz3oaUNy5PCXM7pAn296gDLKhP0v3kvUNXp32HiOfS6iGnglBc836q38TcgOV x24dG/KT86BsSAmteawSieaGu6LsI1Dw/Ob17Fm/7TPl+kzyK6sNkLMs6thbAilxSeDI +6AwdiiVC9n16uoEdeb3BO2TdzZ9QR+iZZFrMkHhl5sfQDAnGHudecEoGfToxuKwss5l ss5tpqm1UhJdEPJ9D0TrXuoH6dkZ6Hc9O/kaL2eCqebx90Znyel6SN1rbY3AC4CAAX7C SAbi6TDuNgG6EuNViEcuR4lKSPU6MSngvn4Kqp3XsEwpfITlE+uThfdJDiqtqxgXoNrj Y0kg== X-Gm-Message-State: AOPr4FVwbaQZlrlXix5VkMl6NyNUlkqf3gl5BQPg+bj2M0JG9jYvrF8jixVP1NqrPcoaPd0z41GdGDhucL3LYw== MIME-Version: 1.0 X-Received: by 10.50.62.113 with SMTP id x17mr17486562igr.34.1460956381177; Sun, 17 Apr 2016 22:13:01 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.4.2 with HTTP; Sun, 17 Apr 2016 22:13:01 -0700 (PDT) In-Reply-To: <5710CD2D.6040103@ninebynine.org> References: <570D4C99.1030405@dcrocker.net> <570E267A.2070801@ninebynine.org> <5710CD2D.6040103@ninebynine.org> Date: Mon, 18 Apr 2016 15:13:01 +1000 X-Google-Sender-Auth: F5G6qfXUSG97x86mmB5FbMkFVWk Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7bb0414e21f3be0530bb6aa4 Archived-At: Cc: Dave Crocker , Apps Discuss Subject: Re: [apps-discuss] New information relating to 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 05:13:08 -0000 --047d7bb0414e21f3be0530bb6aa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for some Monday reading to keep my mind occupied :) On 15 April 2016 at 21:14, Graham Klyne wrote: > Yesterday, in discussion with one of the original authors of RFC 1738, I > learned something about file:// URIs that I had not previously realized. > > The upshot of this for me, in particular with references to Mark > Nottingham's comment ( > https://mailarchive.ietf.org/arch/msg/apps-discuss/pZG6iMoerYpa5qq6BkHa8j= 0Nfjo), > is that there may be parts of this spec that go beyond the clarification > exercise required to maintain file:// URI scheme as a standard-track > specification. > > I offer a new (not detailed) review with suggestions for elements that > might be dropped, in the hope that what remains is truly just a > clarification rather than a modification of the RFC1732 description of > file:// URIs. > > (My own experience and use of file:// URIs is not affected by what I > learned, and in my previous reviews have assumed that contributions > relating to UNC files in particular were based on appropriate knowledge o= r > experience.) > > This is toeing the edge of a catch-22; when I first came up with a draft it was very minimal update from RFC 1738's ABNF to match RFC 3986. The very strong suggestion then was that this wouldn't be enough, and I should address all the other cruft that's built up over the decades. Part of that cruft is in handling file URIs with a non-localhost hostname like UNC paths. ... > > I have learned that the intent of including a hostname component was *not= * > to allow some kind of cross-host file access to be invoked, but to act as= a > signal to software using the URI that was not running on the specified ho= st > that the corresponding resource was not dereferencable. > This is supported by, or at least consistent with, a close reading of the > relevant text in https://tools.ietf.org/html/rfc1738#section-3.10: > > [[ > A file URL takes the form: > > file:/// > > where is the fully qualified domain name of the system on > which the is accessible, and is a hierarchical > directory path of the form //.../. > ]] > > I entirely agree. That's why I have this text: "A file URI can be dependably dereferenced or translated to a local file path only if it is local. A file URI is considered =E2=80=9Clocal=E2=80=9D if it has no file-a= uth, or the file-auth is the special string =E2=80=9Clocalhost=E2=80=9D." I should note that there is some historical baggage here. If I'm on a machine called "fred", can I dereference this URL? "file://fred/tmp/foo" Surely, according to the spec, the answer is "yes". Otherwise putting anything other than "localhost" in the 'host' part of the URL makes it undereferenceable. However as I understand it most implementations actually went with "no" (the heuristic presumably being: only a URL with a blank or "localhost" host can be dereferenced). Then on top of that some (notably Windows and IE) extended the heuristic to be "if the host is blank, it's local; otherwise it's a network share." So in Windows "file://localhost/tmp/foo" is accessed via SMB. On this final point, after much discussion and back and forth, I went with RFC 1738's specification of "localhost", leaving Windows and IE noncompliant. So I'm not as far from 1738 as I could be. Also, RFC 1630 is more explicit that the file scheme is for *local* file > access. The following from https://tools.ietf.org/html/rfc1630 is much > clearer about this than RFC1738: > > [[ > file > > The other URI schemes (except nntp) share the property that they are > equally valid at any geographical place. > > There is however a real practical requirement to be able to generate > a URL for an object in a machine's local file system. > > The syntax is similar to the ftp syntax, but in this case the slash > is used to donate boundaries between directory levels of a > hierarchical file system is used. The "client" software converts the > file URL into a file name in the local file name conventions. This > allows local files to be treated just as network objects without any > necessity to use a network server for access. This may be used for > example for defining a user's "home" document in WWW. > > There is clearly a danger of confusion that a link made to a local > file should be followed by someone on a different system, with > unexpected and possibly harmful results. Therefore, the convention > is that even a "file" URL is provided with a host part. This allows > a client on another system to know that it cannot access the file > system, or perhaps to use some other local mecahnism to access the > file. > > The special value "localhost" is used in the host field to indicate > that the filename should really be used on whatever host one is. > This for example allows links to be made to files which are > distribted on many machines, or to "your unix local password file" > subject of course to consistency across the users of the data. > > A void host field is equivalent to "localhost". > ]] > > This text was dropped when it was effectively replaced by RFC 1738. It also says "...or perhaps to use some other local mechanism to access the file." In either case, I don't believe I've violated the intent (or at least the letter) of 1738 too badly. It may be my failure to communicate -- we'll see as I address the comments below. > Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-06 > again in light of this, I have the following comments: > > ... > > Section 1: > > [[ > This document defines a syntax that is compatible with most extant > implementations, while attempting to push towards a stricter subset > of "ideal" constructs. In many cases it simultaneously acknowledges > and deprecates some less common or outdated constructs. > ]] > > I don't think "deprecates" is right here, as it doesn't discourage any > behaviours specifically allowed by RFC1732. (cf. Mark's comment.) > > As per my replies to Dave and Mark, this wording is already changed. ... > > Section 1.2: > > It now seems to me that the role of a host name in UNC name is quite > different to its (original) role in a file:// URI. In light of this, > should this section be dropped? > > They both name files, and potentially allow files to be dereferenced. That's what I mean by "similar technologies." If it was "identical but for syntax" I wouldn't bother working on the file URI scheme. ... > > Section 2: > > [[ > file-auth =3D [ userinfo "@" ] host > ]] > > The inclusion of "userinfo @" is an extension to previous *specifications= * > of the file URI. As such, I question whether this change should be > included. Dropping it doesn't affect compatibility with RFC3986. > > Hmm, possibly. I'm trying to recall what discussions and ideas lead to it looking the way it does in the draft. It may just be because that's what is currently allowed/expected by those who do "use some other local mechanism to access the file." It could be removed to the relevant appendices, I think, without any issues= . ... > > Section 3: > > [[ > This specification neither defines nor forbids a mechanism for > accessing non-local files. See SMB [MS-SMB], NFS [RFC7530], NCP > [NOVELL] for examples of protocols that can be used to access files > over a network. Also see Appendix C.2 for a non-normative discussion > on translating non-local file URIs to and from UNC strings. > ]] > > Given the new information noted, this seems extraneous to me. Suggest > dropping. > > I admit it might come across that having the references here are a weaselly way of saying, "I won't tell you what to do, but you should do this." I think they belong in the document somewhere, though; perhaps in a relevant appendix. ... > > Section 3.1: > > There is an option to include the host name even for local files, as an > indication that the same file should not be expected to exist on other > hosts. > > I think the default position, in practice, is to not specify a host name. > But if the applications expects that the full absolute URI may be passed = to > another system it may make sense to include it to avoid dereferencing the > value in an inappropriate context. > > I might just remove section 3.1 altogether; it should be enough to have the ABNF syntax and then describe in prose the way the segments map to their equivalents in a file path. Lazily, that also puts the burden of identifying and dealing with all these edge cases on not-me. All I really wanted to emphases was that you can't use backslashes, even in Windows. ... > > Section 3.2: > > Given the new information noted, this section seems extraneous to me. > Suggest dropping. > > ...or moving to an appendix, since in my experience lots of file URL minters expect this to be a thing that works. ... > > Section 4: > > Given the new information, the discussion of encoding when sending a file > URI to a different system seems less relevant. I would be inclined to dr= op > all but the first paragraph of this section. > > =E2=80=8BExcept that there's no rule that says "you MUST NOT send a file UR= I to another computer". Imagine you're into modding your favourite obscure video game, but most of the cool developers are Ukrainian. You unzip a self-contained bundle of libraries and some very beautiful hand-crafted HTML-based documentation where all the relative URLs look like "%E3%B3%E4/123.jpg". A clever person knows the percent-encoded bit is in Windows-1251 and matches the directory called "=D0=B3=D1=96=D0=B4", but a dumb computer doesn't. So we do still need to document cross-system encoding. That said, on re-reading I do think the first sentence isn't so much an introductory statement for the other two as a condensed and less-specified restatement. I should work on it. ... > > Section 6: > > If the userinfo option is removed (see above), the final paragraph become= s > moot. Suggest drop. > > ... > > Appendix A: > > The characterization of "local" and "non-local" files isn't really > germane. Suggest drop the sub-categorization and just list the examples. > > ... > > (I'm not reviewing Appendices B and C at this time, as they aren't > affected by my new perspective.) > > ... > > So in summary you're suggesting: 1. if the hostname is given and resolves to the local machine, it's the same as "localhost" 2. remove the userinfo from the authority 3. don't mention UNC or network shares or "non-local" files in the main tex= t Is that right (if glib)? Regarding #1, we might have issues with Windows, IE, and Chrome, among others. For #2 I'll need to ask around and see what is expected here. And as to #3, I don't know. I might be able to clean it up much more as part of my effort to make the whole thing more readable and clear of purpose. I'll give it some solid work this afternoon and tomorrow. Cheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7bb0414e21f3be0530bb6aa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for s= ome Monday reading to keep my mind occupied :)

On 15 April 2016 at 21:14, Graham Klyne = <gk@ninebynine.org> wrote:
Yesterday, in= discussion with one of the original authors of RFC 1738, I learned somethi= ng about file:// URIs that I had not previously realized.

The upshot of this for me, in particular with references to Mark Nottingham= 's comment (https:= //mailarchive.ietf.org/arch/msg/apps-discuss/pZG6iMoerYpa5qq6BkHa8j0Nfjo), is that there may be parts of this spec that go beyond the clarificatio= n exercise required to maintain file:// URI scheme as a standard-track spec= ification.

I offer a new (not detailed) review with suggestions for elements that migh= t be dropped, in the hope that what remains is truly just a clarification r= ather than a modification of the RFC1732 description of file:// URIs.

(My own experience and use of file:// URIs is not affected by what I learne= d, and in my previous reviews have assumed that contributions relating to U= NC files in particular were based on appropriate knowledge or experience.)<= br>




...

I have learned that the intent of including a hostname component was *not* = to allow some kind of cross-host file access to be invoked, but to act as a= signal to software using the URI that was not running on the specified hos= t that the corresponding resource was not dereferencable.

This is supported by, or at least consistent with, a close reading of the r= elevant text in https://tools.ietf.org/html/rfc1738#= section-3.10:

[[
=C2=A0 =C2=A0A file URL takes the form:

=C2=A0 =C2=A0 =C2=A0 =C2=A0file://<host>/<path>

=C2=A0 =C2=A0where <host> is the fully qualified domain name of the s= ystem on
=C2=A0 =C2=A0which the <path> is accessible, and <path> is a hi= erarchical
=C2=A0 =C2=A0directory path of the form <directory>/<directory>= /.../<name>.
]]


I entirely agree. That's = why I have this text: "A file URI can be dependably dereferenced or tr= anslated to a local file path only if it is local. A file URI is considered= =E2=80=9Clocal=E2=80=9D if it has no file-auth, or the file-auth is the sp= ecial string =E2=80=9Clocalhost=E2=80=9D."

I should note that there is some historical baggage here. If I'm = on a machine called "fred", can I dereference this URL? "fil= e://fred/tmp/foo"

Surely, according t= o the spec, the answer is "yes". Otherwise putting anything other= than "localhost" in the 'host' part of the URL makes it = undereferenceable. However as I understand it most implementations actually= went with "no" (the heuristic presumably being: only a URL with = a blank or "localhost" host can be dereferenced).
<= br>
Then on top of that some (notably Windows and IE) extende= d the heuristic to be "if the host is blank, it's local; otherwise= it's a network share." So in Windows "file://localhost/tmp/f= oo" is accessed via SMB. On this final point, after much discussion an= d back and forth, I went with RFC 1738's specification of "localho= st", leaving Windows and IE noncompliant.

So I'm not as far from 1738 as I could be.

Also, RFC 1630 is more explicit that the file scheme is for *local* file ac= cess.=C2=A0 The following from https://tools.ietf.org/html/rfc163= 0 is much clearer about this than RFC1738:

[[
file

=C2=A0 =C2=A0The other URI schemes (except nntp) share the property that th= ey are
=C2=A0 =C2=A0equally valid at any geographical place.

=C2=A0 =C2=A0There is however a real practical requirement to be able to ge= nerate
=C2=A0 =C2=A0a URL for an object in a machine's local file system.

=C2=A0 =C2=A0The syntax is similar to the ftp syntax, but in this case the = slash
=C2=A0 =C2=A0is used to donate boundaries between directory levels of a
=C2=A0 =C2=A0hierarchical file system is used.=C2=A0 The "client"= software converts the
=C2=A0 =C2=A0file URL into a file name in the local file name conventions.= =C2=A0 This
=C2=A0 =C2=A0allows local files to be treated just as network objects witho= ut any
=C2=A0 =C2=A0necessity to use a network server for access.=C2=A0 This may b= e used for
=C2=A0 =C2=A0example for defining a user's "home" document in= WWW.

=C2=A0 =C2=A0There is clearly a danger of confusion that a link made to a l= ocal
=C2=A0 =C2=A0file should be followed by someone on a different system, with=
=C2=A0 =C2=A0unexpected and possibly harmful results.=C2=A0 Therefore, the = convention
=C2=A0 =C2=A0is that even a "file" URL is provided with a host pa= rt.=C2=A0 This allows
=C2=A0 =C2=A0a client on another system to know that it cannot access the f= ile
=C2=A0 =C2=A0system, or perhaps to use some other local mecahnism to access= the
=C2=A0 =C2=A0file.

=C2=A0 =C2=A0The special value "localhost" is used in the host fi= eld to indicate
=C2=A0 =C2=A0that the filename should really be used on whatever host one i= s.
=C2=A0 =C2=A0This for example allows links to be made to files which are =C2=A0 =C2=A0distribted on many machines, or to "your unix local passw= ord file"
=C2=A0 =C2=A0subject of course to consistency across the users of the data.=

=C2=A0 =C2=A0A void host field is equivalent to "localhost".
]]


This text was dropped when it= was effectively replaced by RFC 1738. It also says "...or perhaps to = use some other local mechanism to access the file."

In either case, I don't believe I've violated = the intent (or at least the letter) of 1738 too badly. It may be my failure= to communicate -- we'll see as I address the comments below.



Reviewing https://tools.ietf.org/html/d= raft-ietf-appsawg-file-scheme-06 again in light of this, I have the fol= lowing comments:

...

Section 1:

[[
This document defines a syntax that is compatible with most extant
=C2=A0 =C2=A0implementations, while attempting to push towards a stricter s= ubset
=C2=A0 =C2=A0of "ideal" constructs.=C2=A0 In many cases it simult= aneously acknowledges
=C2=A0 =C2=A0and deprecates some less common or outdated constructs.
]]

I don't think "deprecates" is right here, as it doesn't d= iscourage any behaviours specifically allowed by RFC1732.=C2=A0 (cf. Mark&#= 39;s comment.)


As per my replies to Dave and= Mark, this wording is already changed.


...

Section 1.2:

It now seems to me that the role of a host name in UNC name is quite differ= ent to its (original) role in a file:// URI.=C2=A0 In light of this, should= this section be dropped?


They both name files, and pot= entially allow files to be dereferenced. That's what I mean by "si= milar technologies." If it was "identical but for syntax" I = wouldn't bother working on the file URI scheme.

...

Section 2:

[[
=C2=A0 =C2=A0 =C2=A0 file-auth=C2=A0 =C2=A0 =C2=A0 =3D [ userinfo "@&q= uot; ] host
]]

The inclusion of "userinfo @" is an extension to previous *specif= ications* of the file URI.=C2=A0 As such, I question whether this change sh= ould be included. Dropping it doesn't affect compatibility with RFC3986= .


Hmm, possibly. I'm trying= to recall what discussions and ideas lead to it looking the way it does in= the draft. It may just be because that's what is currently allowed/exp= ected by those who do "use some other local mechanism to access the fi= le."

It could be removed to the relev= ant appendices, I think, without any issues.


=
...

Section 3:

[[
=C2=A0 =C2=A0This specification neither defines nor forbids a mechanism for=
=C2=A0 =C2=A0accessing non-local files.=C2=A0 See SMB [MS-SMB], NFS [RFC753= 0], NCP
=C2=A0 =C2=A0[NOVELL] for examples of protocols that can be used to access = files
=C2=A0 =C2=A0over a network.=C2=A0 Also see Appendix C.2 for a non-normativ= e discussion
=C2=A0 =C2=A0on translating non-local file URIs to and from UNC strings. ]]

Given the new information noted, this seems extraneous to me.=C2=A0 Suggest= dropping.


I admit it might come across = that having the references here are a weaselly way of saying, "I won&#= 39;t tell you what to do, but you should do this." I think they belong= in the document somewhere, though; perhaps in a relevant appendix.

...

Section 3.1:

There is an option to include the host name even for local files, as an ind= ication that the same file should not be expected to exist on other hosts.<= br>
I think the default position, in practice, is to not specify a host name.= =C2=A0 But if the applications expects that the full absolute URI may be pa= ssed to another system it may make sense to include it to avoid dereferenci= ng the value in an inappropriate context.


I might just remove section 3= .1 altogether; it should be enough to have the ABNF syntax and then describ= e in prose the way the segments map to their equivalents in a file path. La= zily, that also puts the burden of identifying and dealing with all these e= dge cases on not-me.

All I really wanted t= o emphases was that you can't use backslashes, even in Windows.

...

Section 3.2:

Given the new information noted, this section seems extraneous to me.=C2=A0= Suggest dropping.


...or moving to an appendix, = since in my experience lots of file URL minters expect this to be a thing t= hat works.


...

Section 4:

Given the new information, the discussion of encoding when sending a file U= RI to a different system seems less relevant.=C2=A0 I would be inclined to = drop all but the first paragraph of this section.


=E2=80=8BExcept that there= 9;s no rule that says "you MUST NOT send a file URI to another compute= r".

Imagine you're into modding y= our favourite obscure video game, but most of the cool developers are Ukrai= nian. You unzip a self-contained bundle of libraries and some very beautifu= l hand-crafted HTML-based documentation where all the relative URLs look li= ke "%E3%B3%E4/123.jpg". A clever person knows the percent-encoded= bit is in Windows-1251 and matches the directory called "=D0=B3=D1=96= =D0=B4", but a dumb computer doesn't.

So we do still need to document cross-system encoding. That said, on r= e-reading I do think the first sentence isn't so much an introductory s= tatement for the other two as a condensed and less-specified restatement. I= should work on it.


...

Section 6:

If the userinfo option is removed (see above), the final paragraph becomes = moot.=C2=A0 Suggest drop.

...

Appendix A:

The characterization of "local" and "non-local" files i= sn't really germane. Suggest drop the sub-categorization and just list = the examples.

...

(I'm not reviewing Appendices B and C at this time, as they aren't = affected by my new perspective.)

...


So in summ= ary you're suggesting:

1. if the hostn= ame is given and resolves to the local machine, it's the same as "= localhost"

2. remove the userinfo fr= om the authority

3. don't mention UNC = or network shares or "non-local" files in the main text

Is that right (if glib)?

Regarding #1, we might have issues with Windows, IE, and Chrome, amo= ng others.

For #2 I'll need to ask aro= und and see what is expected here.

And as= to #3, I don't know. I might be able to clean it up much more as part = of my effort to make the whole thing more readable and clear of purpose. I&= #39;ll give it some solid work this afternoon and tomorrow.
<= br>
Cheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--047d7bb0414e21f3be0530bb6aa4-- From nobody Sun Apr 17 23:07:23 2016 Return-Path: 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 E1E5912DACF; Sun, 17 Apr 2016 23:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.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 89ohuoYkFm2c; Sun, 17 Apr 2016 23:07:20 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0133.outbound.protection.outlook.com [104.47.93.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B8512DB76; Sun, 17 Apr 2016 23:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HWnOzliG74QtuzjXt2TQUwxv5volXfWNLbjHX9ZWKck=; b=vW8keg22l4Byuua8eqDcL9KuvbgC/yBxyughzUirjlgwXY4qpnhq575SfAd1Ya9zIEZ37fj++KllZRYZPTpCYZSnwpr+nF8/zC7pvBQgXtgqedYs0DuKt8kyq/rD9tWlXU6lFRKuuk3bI8ZJ+UIxsrPzAJM0IV//09H1nUrkASQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 18 Apr 2016 06:07:16 +0000 To: Julian Reschke , Matthew Kerwin , Graham Klyne References: <570D4C99.1030405@dcrocker.net> <570E2510.4040408@ninebynine.org> <5710953E.5040505@gmx.de> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <57147992.70504@it.aoyama.ac.jp> Date: Mon, 18 Apr 2016 15:07:14 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5710953E.5040505@gmx.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0047.jpnprd01.prod.outlook.com (10.165.48.157) To TYXPR01MB0926.jpnprd01.prod.outlook.com (10.168.45.21) X-MS-Office365-Filtering-Correlation-Id: 4091b3da-9813-45e1-8472-08d3674fb15a X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 2:pj/kgIcCqOrKCIZdoU0xfW33acVEWWosA6wA/DULT/+Hd3iZB/TVClJq2nysAThpK6C+452a3JsYR36nSvX+24pmIIeJKAK2la2TuNxPUeECNGegoaHoTqditKuSx6JPDewl9ayxCFF8bcALcWze++Mc1G2UBXr8ozbT4wQyJFraHumajq2OqQKk7BNAviIK; 3:cW6lXben8sZ53TMkVpkB0HQVZ9fOu7zpoJMusimuq2zuuhZxHuJhOOJ/HkyKnNU7XTpWZr9j7gLa6gHRG2xzdeOr+N9lrmjOCWTcWGKVYX83Jxa6GI3/ylmUmb1x6rfG; 25:WS4qJrnnF+mAhLVF4LUH+yc1iZ9ZtFWg4UONf/dLW1aUiG5tqTK4uEvVd2FBKhudjaf8Do3KHUXH5NcpzZdKIlDUaUKy4GT82rS86abS5QMCzu2iLQobUM/yibBp5aiynQKvdbkGZZlgkeQCkUiV5kM6xISyB7aeTiVu6f9PCsTLoOAZsOiLmulvu0nromfs1sXlIK1DQsxa4vjthE8L5OpbRxV1yNgE5Pb0uvKYq5WHT6A2+cja3XLSB3zBwTm8hv6C1GguzNAY36GsyjWKQGkKOF7lwcrtPnjAvWdYLBIqal6uOusP5XYTPElrwGSnG8NZ4NumfmiUwdNyi270oA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TYXPR01MB0926; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:TYXPR01MB0926; BCL:0; PCL:0; RULEID:; SRVR:TYXPR01MB0926; X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 4:I3hVXKB5HZSk7JPrN8X+0Eob/H0hRLlVrN+shRmrBHKkRAkmw7fYFsXePrvmDyMhjQE+LwNXN6AT0pJmxZhsnhSaFMCTMkjCSkSqFbiVQc2fYWIP+Ht/e1D0ei+9JY2RLiXS4No3CNz15uQVvV3NtKDA6oxbHbEmclmZFTrrzxA5iPZ6t+NB9BUsZvLm2axmOdF7YgEwICtXLjmtb4uixf89umx57e6Bjp7UKe4LWJLMy30HTKRw5hHZ21w2rtUP7SoVjmW2ZgtlGGSHXlB+F4ZflSeEnjRCYfPxmZXiYvfFldUbRE+Oi3DUY+v3elAERKhb3lSZ2PWuWxzwDuzSsAOLG4qL2hvz13tCDjrnQq/+wuy/uVmRH2rFYwBpH6eJ+i7joiI00ioz5no65ONeH5o36bK4ikt4h2RREVERsXzEsmofQp1i70mM8P6hI0Se X-Forefront-PRVS: 0916FC3A18 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(230700001)(42186005)(4326007)(64126003)(65816999)(6116002)(3846002)(586003)(86362001)(47776003)(50466002)(66066001)(5001770100001)(50986999)(93886004)(54356999)(76176999)(65806001)(5004730100002)(77096005)(5008740100001)(122286003)(23676002)(81166005)(117636001)(2950100001)(74482002)(65956001)(230783001)(83506001)(92566002)(189998001)(7059030)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYXPR01MB0926; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWVhQUjAxTUIwOTI2OzIzOlRFY25hSlBWWFNnNnIxSGN0Q1N0Zm9UYTZs?= =?utf-8?B?RTU0ZzhvY1pHRFgrbWdlVXhSbjlCVDFKdncxWDZ5QW4yK0doeGVVNm5IZ1FQ?= =?utf-8?B?ZHVTL2hZNnFZUmNuT1EvVWs0NUdrK01acGt5RDdIaHg3ZGZNZlMvakhVSUxU?= =?utf-8?B?aEdSR1VsQlVybHl5cm1ydmpRZ3Uvbkk1N1BjR2VHVkd3Uy9wNXBHY212T1Aw?= =?utf-8?B?WDBKb1YwMkIzMGI1YzJkc1VoN3lNUm9LSkdIa214bDhtUWxCVytSTzJMa1RH?= =?utf-8?B?b1BjQ0VaMWg2RmtKbXNVa29KaUNGUXQxMDg4aUxtSjZvZmpRL2tmUHBwU2NU?= =?utf-8?B?d1RlNTQ1ck5zSS8zcVlvTVJaWTJlc2ttQ2UyazA3Y0k3YzAxaHZmZC81V2hr?= =?utf-8?B?YSs5RFd4Y3FmcjFEemNFWTc5cVF3Um1jaHNadGpXYVBFblU1M1g5L0s4eFEz?= =?utf-8?B?UWVFK3FVWUovK21NZmk3VG9qYzUvMTVBYW96WlM1WkczM1BRNFhaby94Qk4w?= =?utf-8?B?ODgxL1BJQlJVSi9ON3N3RFQ1NlZ3TzErVmlXRmlnM3Y3MHZSbUF3MW5VZExH?= =?utf-8?B?ZmdGbk5uckFENE5SU3Q2eTBQWHU5dWY1cWN5ZitLRU9tODBKdStydnMrZnBy?= =?utf-8?B?TmdSbkw5N1RjRjh0ay9lYVRZbHh0dDBkbGJlbWIrUVFuM0dlL3BIRUtaenNV?= =?utf-8?B?VVhLRjdEMXl4dUp6RjBZcVRER3ZJenVQdlQyY29oRE5CREExcDkzWndiN2Ro?= =?utf-8?B?UmxrNjJaOEFXR3pvbXA0d3NIM0lmN0Q4TzhsSm1ONklkY1lmZ1FtVXN0NC9X?= =?utf-8?B?NjAzUXhydFZxSFB4UkMwSmpETFJkZFF3WG5UTnNCOXYwZVFKSER1UFZLU2dS?= =?utf-8?B?ajVUeXcwZ3pmZ0g0Sy9ON2NtYm1mMDlMd3FoMlkwZUR3OHpGSitBbCtJOFZB?= =?utf-8?B?dTFkMW41ZjZsZ1VpdDBJdjhCT0Q5dHA0RC84bC9JKzI0VlZ5MnR0V2JDYkZk?= =?utf-8?B?TUVjU0lzZ1dBQThtNS9ETFkwNTZsV0dZRWZ6cis1T3dyaFVXcnBoQmJmbmdR?= =?utf-8?B?dUFqMEQvQ1RYcEw2RGd0Uy9FemtkTHBqOU0rT3ZOYW4xbVBSa1lyQVJONTRL?= =?utf-8?B?MW0rNi9Kc2dOYXFBWVArSUZMT1RWdGtlUnV3WjI2WW0xM1JEc3pJWmZETkJ4?= =?utf-8?B?ZVlFeXREekxBenc1Nmp1b1dxUkkrMTgwV1ZSdDRlWjVrYnFFazNJbTNEanpi?= =?utf-8?B?Unc0amRweVNWNmx5eUtHUFdoWlJ3U0o0eVVnYXFlTkczeGd0cmc2V3NmelNY?= =?utf-8?B?U3Z0K2NFUU5LRXN0MkpLZndDWmhlMUU1c3I2SkQ5eEVrQXR1K3lLZG5peXdl?= =?utf-8?Q?zMcAcwap?= X-Microsoft-Exchange-Diagnostics: 1; TYXPR01MB0926; 5:zXze4D24PhgZ0O5z3ViXMT2sj2/oyQ1I4jqvsG82Uz7vvY5WpjCSI0io8fSQGKJFPknjtb6hxjZXHheG7DYFdPeDCsSiRGyZaD362rJKboCfdvbMU7F4KRfh1AzlbOveLbSuJBBv63oNqFP6jw9QEQ==; 24:retvDxUT4i0zZynMyyeA85FjlyuNI9MqzKscaWzfMg2vN2i0dwX5/Olw2MuxA1mzsO9ieCtBnoqADtgnusE28RYHdngNkRyVTLUxkEvVbsc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2016 06:07:16.3229 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYXPR01MB0926 Archived-At: Cc: draft-ietf-appsawg-file-scheme@ietf.org, Dave Crocker , Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 06:07:23 -0000 On 2016/04/15 16:16, Julian Reschke wrote: > case-insensitive (DOS?) < case-preserving (NTFS) < case-sensitive (others) DOS, at least to the extent I know it from modern Windows, is also case-preserving. > ...so maybe mention all the three cases. > > Best regards, Julian > > PS: it might also be good to touch Unicode normalization forms... Yes, this is relevant, because Apple is essentially NFD, but Windows and Linux don't care and usually are NFC. Regards, Martin. From nobody Mon Apr 18 00:01:03 2016 Return-Path: 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 5C4E312D8E7; Mon, 18 Apr 2016 00:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OuinYDTUz7tT; Mon, 18 Apr 2016 00:01:00 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157A412D998; Mon, 18 Apr 2016 00:01:00 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id e185so209690077vkb.1; Mon, 18 Apr 2016 00:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/hJ+x8XeKZELk5RrKyAFaQRaIbwTZSDhN6/cX2qlZgU=; b=0HA9nsxxKND0yEBZF2M3ewSqXGKXmllmzQ06COnPPxikhuGncfgyurLULgS1eXiWrR esoq4DChHjIjBxq5HOfPElMFok8zFXSVOZahP5H6xBlTLPzZ/uWhI+6mIYndgyFF6vAh 5ce381d9aJnPI60IkjWRIDir0aIhmqkULQwdWCWUP9cH0Q6HtNWvXjPcxFEup7B8HLBW XAu99jUDZI29RubeDJdg7OE5LzRNVBp+xvYOk7+v/nzekJ1fSXTjmxChJakahs78bW8e +oN/VVJe9lKsg3WysKhygJ6xwwoLPKZUwx99K/THa9XUUgrTYrY7xwDX3/D9hhyMZ8NN 2q7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/hJ+x8XeKZELk5RrKyAFaQRaIbwTZSDhN6/cX2qlZgU=; b=k3hO018waXxqsCYGMWKzWy6m/h4BDb04dKX1CkwDPDxhr1FQBkDvGU+EHGlt13JM3O ii6dZZowXxjclsCzzohctFGLR3Rjisfb/TstdYNQN2rCAmf9p6bJc+bWyj9K/FaZ92uv RTSWTMSbzk5MeCxIcXgzMK0UK5SyXNMDBcxFkDStin99iB2nQ9/+4SbN6DNgQIIJdpM8 Y+GlaD8FRXEcgpspFr+YIEHYInyqTvc1appdOcjofHvr/hUyZiK/mpuAD9PJE35jw3s8 CV9/XXB4+/0YDW3Z3ji0+hznrHLi0EVH4Sm2DBK3GbA5f+psFmT5We5cHRmHp1ZPvhBZ DQ7w== X-Gm-Message-State: AOPr4FV7RNAvGIQV75v++MDKzSgs5ph57p4yhk26r1pTxpWYWk0k0aEsTGJQu/pZ2gOg1DUsut1ZaemBMr7sPw== MIME-Version: 1.0 X-Received: by 10.176.1.54 with SMTP id 51mr17412266uak.123.1460962859161; Mon, 18 Apr 2016 00:00:59 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Mon, 18 Apr 2016 00:00:59 -0700 (PDT) In-Reply-To: <570D4C99.1030405@dcrocker.net> References: <570D4C99.1030405@dcrocker.net> Date: Mon, 18 Apr 2016 00:00:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113c86a8401fb30530bcec09 Archived-At: Cc: art-ads@ietf.org, Apps Discuss , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 07:01:01 -0000 --001a113c86a8401fb30530bcec09 Content-Type: text/plain; charset=UTF-8 On a purely procedural note: Given the renewed activity here and the interest in making changes, I presume this will be reworked enough now to warrant an eventual second Working Group Last Call. Unless there's objection to doing so, I'll move the document back to that state. -MSK --001a113c86a8401fb30530bcec09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On a purely procedural note:

Given = the renewed activity here and the interest in making changes, I presume thi= s will be reworked enough now to warrant an eventual second Working Group L= ast Call.=C2=A0 Unless there's objection to doing so, I'll move the= document back to that state.

-MSK
--001a113c86a8401fb30530bcec09-- From nobody Mon Apr 18 01:03:34 2016 Return-Path: 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 E240A12DFE1 for ; Mon, 18 Apr 2016 01:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 chJb8gKCtn9B for ; Mon, 18 Apr 2016 01:03:31 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E36912DB56 for ; Mon, 18 Apr 2016 00:55:36 -0700 (PDT) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1as41p-0008S3-fT; Mon, 18 Apr 2016 08:55:29 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=sasharissa.local) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1as41p-000CCz-LS; Mon, 18 Apr 2016 08:55:29 +0100 Message-ID: <571492EF.30703@ninebynine.org> Date: Mon, 18 Apr 2016 08:55:27 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin References: <570D4C99.1030405@dcrocker.net> <570E267A.2070801@ninebynine.org> <5710CD2D.6040103@ninebynine.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Cc: Dave Crocker , Apps Discuss Subject: Re: [apps-discuss] New information relating to 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 08:03:33 -0000 Matthew, (FWIW, I think you've done sterling work on this spec, and I'd hate to see it die like previous efforts did - my suggestions are offered in the hope of a route to sufficient consensus to allow it to proceed. I've spoken to a few developers last week at the WWW conference about this, and the general feeling I get is that they'd like to see file:// URIs "back in the fold", primarily for their use as a unifying mechanism for local and web access. My suggested approach to achieve this has been to stick very close to the intent of earlier file:// specs, while bringing it inline with RFC3986. To the extent that documented extensions have community consensus I see no cause to pull them; my comments have come from a place of uncertainty about this.) On 18/04/2016 06:13, Matthew Kerwin wrote: > Hi, > > Thanks for some Monday reading to keep my mind occupied :) > > On 15 April 2016 at 21:14, Graham Klyne > wrote: > > Yesterday, in discussion with one of the original authors of RFC 1738, I > learned something about file:// URIs that I had not previously realized. > > The upshot of this for me, in particular with references to Mark > Nottingham's comment > (https://mailarchive.ietf.org/arch/msg/apps-discuss/pZG6iMoerYpa5qq6BkHa8j0Nfjo), > is that there may be parts of this spec that go beyond the clarification > exercise required to maintain file:// URI scheme as a standard-track > specification. > > I offer a new (not detailed) review with suggestions for elements that might > be dropped, in the hope that what remains is truly just a clarification > rather than a modification of the RFC1732 description of file:// URIs. > > (My own experience and use of file:// URIs is not affected by what I > learned, and in my previous reviews have assumed that contributions relating > to UNC files in particular were based on appropriate knowledge or experience.) > > > This is toeing the edge of a catch-22; when I first came up with a draft it was > very minimal update from RFC 1738's ABNF to match RFC 3986. The very strong > suggestion then was that this wouldn't be enough, and I should address all the > other cruft that's built up over the decades. > > Part of that cruft is in handling file URIs with a non-localhost hostname like > UNC paths. Yeah. These discussions have been running a long while now, and some of the rest of the world is moving on. That seemed reasonable to me at the time as long as it wasn't controversial - but if it now looks like divergence from current practice then I'd suggest it be more clearly discursive, not normative. > > ... > > I have learned that the intent of including a hostname component was *not* > to allow some kind of cross-host file access to be invoked, but to act as a > signal to software using the URI that was not running on the specified host > that the corresponding resource was not dereferencable. > > > This is supported by, or at least consistent with, a close reading of the > relevant text in https://tools.ietf.org/html/rfc1738#section-3.10: > > [[ > A file URL takes the form: > > file:/// > > where is the fully qualified domain name of the system on > which the is accessible, and is a hierarchical > directory path of the form //.../. > ]] > > > I entirely agree. That's why I have this text: "A file URI can be dependably > dereferenced or translated to a local file path only if it is local. A file URI > is considered “local” if it has no file-auth, or the file-auth is the special > string “localhost”." Yes. For me, the new understanding calls for something something stronger, maybe along the lines of: "A file URI is intended to be dereferenced for local file access only. The presence of a host component in the URI is intended to be used as a signal to implementations that are running on hosts other than the one named that the file is not accessible to them." and maybe add (possibly in an appendix): "Some implementations allow a host component in file URIs to access files on non-local hosts - such behaviour is beyond the scope of this specification." > > I should note that there is some historical baggage here. If I'm on a machine > called "fred", can I dereference this URL? "file://fred/tmp/foo" > > Surely, according to the spec, the answer is "yes". Otherwise putting anything > other than "localhost" in the 'host' part of the URL makes it undereferenceable. Agreed. I think that's clear in the original RFC1630 text (but not so clear in RFC1732). > However as I understand it most implementations actually went with "no" (the > heuristic presumably being: only a URL with a blank or "localhost" host can be > dereferenced). Maybe so - I think that is something that got obscured in RFC1732. For myself, and developers I've spoken to, this is somewhat moot as the file:// URI is mostly used as a relative reference resolved against a locally generated base URI, or just specified locally. > > Then on top of that some (notably Windows and IE) extended the heuristic to be > "if the host is blank, it's local; otherwise it's a network share." So in > Windows "file://localhost/tmp/foo" is accessed via SMB. On this final point, > after much discussion and back and forth, I went with RFC 1738's specification > of "localhost", leaving Windows and IE noncompliant. I recall that, and I agree with the outcome re "localhost". (Implementations are always free to be non-compliant - it can hurt interop when they are, but in this case I think maybe not so much.) > > So I'm not as far from 1738 as I could be. Sure. I think it's the adaptations to bless remote file access that may be problematic - the rest looks fine to me. > > > Also, RFC 1630 is more explicit that the file scheme is for *local* file > access. The following from https://tools.ietf.org/html/rfc1630 is much > clearer about this than RFC1738: > > [[ > file > > The other URI schemes (except nntp) share the property that they are > equally valid at any geographical place. > > There is however a real practical requirement to be able to generate > a URL for an object in a machine's local file system. > > The syntax is similar to the ftp syntax, but in this case the slash > is used to donate boundaries between directory levels of a > hierarchical file system is used. The "client" software converts the > file URL into a file name in the local file name conventions. This > allows local files to be treated just as network objects without any > necessity to use a network server for access. This may be used for > example for defining a user's "home" document in WWW. > > There is clearly a danger of confusion that a link made to a local > file should be followed by someone on a different system, with > unexpected and possibly harmful results. Therefore, the convention > is that even a "file" URL is provided with a host part. This allows > a client on another system to know that it cannot access the file > system, or perhaps to use some other local mecahnism to access the > file. > > The special value "localhost" is used in the host field to indicate > that the filename should really be used on whatever host one is. > This for example allows links to be made to files which are > distribted on many machines, or to "your unix local password file" > subject of course to consistency across the users of the data. > > A void host field is equivalent to "localhost". > ]] > > > This text was dropped when it was effectively replaced by RFC 1738. It also says > "...or perhaps to use some other local mechanism to access the file." > > In either case, I don't believe I've violated the intent (or at least the > letter) of 1738 too badly. It may be my failure to communicate -- we'll see as I > address the comments below. > > > > Reviewing https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-06 > again in light of this, I have the following comments: > > ... > > Section 1: > > [[ > This document defines a syntax that is compatible with most extant > implementations, while attempting to push towards a stricter subset > of "ideal" constructs. In many cases it simultaneously acknowledges > and deprecates some less common or outdated constructs. > ]] > > I don't think "deprecates" is right here, as it doesn't discourage any > behaviours specifically allowed by RFC1732. (cf. Mark's comment.) > > > As per my replies to Dave and Mark, this wording is already changed. Ack. (I haven't seen the new text yet.) > > > ... > > Section 1.2: > > It now seems to me that the role of a host name in UNC name is quite > different to its (original) role in a file:// URI. In light of this, should > this section be dropped? > > > They both name files, and potentially allow files to be dereferenced. That's > what I mean by "similar technologies." If it was "identical but for syntax" I > wouldn't bother working on the file URI scheme. But the UNC form, to my perspective, is specifically about accessing files on different hosts - something which was not part of the original intent of file:. This is why I suggest it might be dropped (or moved to an informative appendix?). In the face of Mark's push-back, I think that in the absence of hard evidence of widespread implementation we need to focus on clarifying what is already stated in RFC1732, and bringing it in line with RFC3986. My understanding is that the primary purpose of this spec is to bring file:// URIs back onto the standards track following obsoleting of RFC1732, and that is something I'd really like to see myself. My suggestions are attempting to remove the obstacles to this. > > ... > > Section 2: > > [[ > file-auth = [ userinfo "@" ] host > ]] > > The inclusion of "userinfo @" is an extension to previous *specifications* > of the file URI. As such, I question whether this change should be > included. Dropping it doesn't affect compatibility with RFC3986. > > > Hmm, possibly. I'm trying to recall what discussions and ideas lead to it > looking the way it does in the draft. It may just be because that's what is > currently allowed/expected by those who do "use some other local mechanism to > access the file." > > It could be removed to the relevant appendices, I think, without any issues. I could live with that. I have never personally come across an implementation of file:// that uses that form (or if I did I didn't notice it). (See also comments at the end of this message.) > ... > > Section 3: > > [[ > This specification neither defines nor forbids a mechanism for > accessing non-local files. See SMB [MS-SMB], NFS [RFC7530], NCP > [NOVELL] for examples of protocols that can be used to access files > over a network. Also see Appendix C.2 for a non-normative discussion > on translating non-local file URIs to and from UNC strings. > ]] > > Given the new information noted, this seems extraneous to me. Suggest dropping. > > > I admit it might come across that having the references here are a weaselly way > of saying, "I won't tell you what to do, but you should do this." I think they > belong in the document somewhere, though; perhaps in a relevant appendix. > Now it's clearer to me that file:// was never intended to allow remote access, I think an appendix that positions it more clearly as a non-standard extension would be more appropriate if the text is to remain. > > ... > > Section 3.1: > > There is an option to include the host name even for local files, as an > indication that the same file should not be expected to exist on other hosts. > > I think the default position, in practice, is to not specify a host name. > But if the applications expects that the full absolute URI may be passed to > another system it may make sense to include it to avoid dereferencing the > value in an inappropriate context. > > > I might just remove section 3.1 altogether; it should be enough to have the ABNF > syntax and then describe in prose the way the segments map to their equivalents > in a file path. Lazily, that also puts the burden of identifying and dealing > with all these edge cases on not-me. > > All I really wanted to emphases was that you can't use backslashes, even in Windows. Ack. > > ... > > Section 3.2: > > Given the new information noted, this section seems extraneous to me. > Suggest dropping. > > > ...or moving to an appendix, since in my experience lots of file URL minters > expect this to be a thing that works. > Ack. > > ... > > Section 4: > > Given the new information, the discussion of encoding when sending a file > URI to a different system seems less relevant. I would be inclined to drop > all but the first paragraph of this section. > > > ​Except that there's no rule that says "you MUST NOT send a file URI to another > computer". Sure, but the intent of the original file:// spec is that if you do this, it not be dereferencable on that other computer. But I take your point, and agree, that encoding is still relevant for relative references. > > Imagine you're into modding your favourite obscure video game, but most of the > cool developers are Ukrainian. You unzip a self-contained bundle of libraries > and some very beautiful hand-crafted HTML-based documentation where all the > relative URLs look like "%E3%B3%E4/123.jpg". A clever person knows the > percent-encoded bit is in Windows-1251 and matches the directory called "гід", > but a dumb computer doesn't. > > So we do still need to document cross-system encoding. That said, on re-reading > I do think the first sentence isn't so much an introductory statement for the > other two as a condensed and less-specified restatement. I should work on it. > > > ... > > Section 6: > > If the userinfo option is removed (see above), the final paragraph becomes > moot. Suggest drop. > > ... > > Appendix A: > > The characterization of "local" and "non-local" files isn't really germane. > Suggest drop the sub-categorization and just list the examples. > > ... > > (I'm not reviewing Appendices B and C at this time, as they aren't affected > by my new perspective.) > > ... > > > So in summary you're suggesting: > > 1. if the hostname is given and resolves to the local machine, it's the same as > "localhost" Yes. (I believe that's the intent of the original spec.) > > 2. remove the userinfo from the authority I was, but see below. > > 3. don't mention UNC or network shares or "non-local" files in the main text > Yes. > Is that right (if glib)? > > Regarding #1, we might have issues with Windows, IE, and Chrome, among others. The point here, IMO, is not to *specify* all extension behaviours. Not including extension behaviours in the spec doesn't prohibit them. > > For #2 I'll need to ask around and see what is expected here. Hmmm, I can see your point here. This is an incompatible extension to the original spec, in the sense that including a userinfo would be a syntax violation. In light of my comment above, I see that may be too proscriptive. Maybe keeping it in the syntax (for compatibility), but being clear that its effect is not defined by this specification? > > And as to #3, I don't know. I might be able to clean it up much more as part of > my effort to make the whole thing more readable and clear of purpose. I'll give > it some solid work this afternoon and tomorrow. I think the key test here is whether it's seen as diverging from current practice - if there's consensus that this material does reflect current practice then I think there's no cause to pull it. I was responding mainly to the concern that the spec was defining extension behaviours that do not reflect current widespread practice. Thanks for your efforts! #g -- From nobody Mon Apr 18 04:21:23 2016 Return-Path: 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 EACEE12D880 for ; Mon, 18 Apr 2016 04:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it 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 QC8eVMEgWlri for ; Mon, 18 Apr 2016 04:21:19 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A2712D899 for ; Mon, 18 Apr 2016 04:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1460978476; bh=JEDQp/MkrA9VajbjAOVZOw7SPJhivAuyNLbQlJf1C70=; l=2522; h=To:References:Cc:From:Date:In-Reply-To; b=UtLisfZ+nrrwTsm86xnu19UVMFaB9ILBcjlvMiCndFqtSCq9URPHD9hNt2WOH4oFd GVzirgkm5S5/wNfwOQ8rio7xYWd2EJgWp6yqBfsxTqIHf5SgQdXvpcVZ+4JdgeJYiu F3NnwmvYeoWVJYAjA3D3bjbtf9T44mc/DZfuDyH4= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 18 Apr 2016 13:21:16 +0200 id 00000000005DC033.000000005714C32C.000060D5 To: Scott Kitterman , "Murray S. Kucherawy" References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> <570E8985.7080708@tana.it> <57125854.2030307@tana.it> From: Alessandro Vesely Message-ID: <5714C32C.6000905@tana.it> Date: Mon, 18 Apr 2016 13:21:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: Matthias Leisi , AppsAWG Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 11:21:22 -0000 On Sat 16/Apr/2016 18:10:47 +0200 Scott Kitterman wrote: > On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" wrote: >> On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely wrote: >> >>> Yes, I rejected your proposal to use policy.zone=lists.dnswl.example, >>> because it disagrees with the only existing implementation. When that >>> was discussed, the syntax dns.zone=lists.dnswl.example was chosen >>> because a DNSxL is a zone in the DNS, according to, say, RFC5782. >>> Nobody realized that "dns" is not a valid RFC7601 ptype (and I still >>> don't understand why). >> >> I've gone over the "why" with you at some length both at the Berlin >> meeting and now on a thread subsequent to your request to IANA. >> >> While I'm sympathetic to some degree with the "installed base" argument, >> I don't think it's reasonable to accept a registration that doesn't fit >> within the defining RFC merely because there's a single existing >> incorrect implementation. > > While I normally give pragmatic arguments (like alignment to existing > practice) a lot of weight, in this case I agree with Murray that it would be > a mistake. > > If you look at the discussion of iprev in > http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same > ground as this proposal with regards to ptype selection. I believe it's > clear that policy is the correct choice. I guess you mean the paragraph: The result is reported using a ptype of "policy" (as this is not part of any established protocol) and a property of "iprev". That looks like an explanation of the naming, it doesn't seem to mandate that every ptype must be "policy" unless the related property belongs to an established protocol. The definition of "policy" in Section 2.4 differs. Would a name like, say, client.ip=192.0.2.1 have been an equally valid choice? > In order to add the proposed new ptype, I think the ptype definition in > http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed and > that would require a standards track update to RFC 7601. I don't think you > want to go down that path. >From that definition it is not clear if or why a method is bound to use at most one ptype. My understanding was that RFC7410 allowed to add new ptypes as needed without having to update the A-R header field name definition each time. Can you envisage what kind of change would be required in order to call A DNS zone dns.zone? Ale From nobody Mon Apr 18 06:58:56 2016 Return-Path: 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 5494912D6AF for ; Mon, 18 Apr 2016 06:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gaws8HVBt2MI for ; Mon, 18 Apr 2016 06:58:49 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D1E12DA42 for ; Mon, 18 Apr 2016 06:58:49 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id t129so220951828vkg.2 for ; Mon, 18 Apr 2016 06:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Y6Nz5heH0jmDeuM6nmqpan4bBa519jxVdCutalZswbY=; b=oTGB+EUYMCkmM/rPLwM8jFOaVheYOp+rJ2KGes2ph6kiwWgThH9szKwd56wtdOA3z4 zRgqOz9O0160vgLXxGBvOH65HUl67p4W2pB/Cdnkf9HZFTsSCVzFnaQPW1uUx5P86X4Y IVykUjr/OAjKHRwRJ2V/LDZKfdsqnzoimbWN1GKAe/BEz4Am9IEshckCXiyGOSUcvBhq UYYAgaAhi3PbPP1MkAW7n+gLqOGpJe4GfmCbsfXt71nXl75rwZLSAleNqxZlhOrixnbu voma9RbA/yKr2HwN4yPikhg6Rala62FpYBcTVg/wqmp7D31iHbRSqRWo6vV6fIoD/LzI FFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Y6Nz5heH0jmDeuM6nmqpan4bBa519jxVdCutalZswbY=; b=S9eLUX9eT0rwEx96ravkk/YXEm/Wceo3U6uhPn6BX1jETHQGINMmoc/piYUM60BHDZ oAupVj8XB4JCzCu/52MaEW/IIUR4wJHPEI5jRLPDx9yWlJbE1hWiVQrMfAdWN/KGJcce vR2eZhnFvgQYuxC9f6q+DELNIVxXSQ5hzB7B8VWxg7SVP8Ha13g2ETR2hQDd+hKquhfk o1XK9bVNjc/lR5lXZ3LzO/u2nT97TYaYDGydVloycMyUcL8ets2ZSAUv4RMSTIGp26XZ pPLPSxOzAkeF/fiJf8F0JZ5RGzeF+qmORM2BKdV+zHNVduSEC10iODWs5I76PuFDbKTW M4cQ== X-Gm-Message-State: AOPr4FV+5lp0oYPKCbwqK7SxVzlAao68NAnITEBivaZXxOWsFf/yVGqSH7SBAuXeuE9Ic723fGqojNTlmL4KZw== MIME-Version: 1.0 X-Received: by 10.31.54.139 with SMTP id d133mr18505554vka.132.1460987928153; Mon, 18 Apr 2016 06:58:48 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Mon, 18 Apr 2016 06:58:48 -0700 (PDT) In-Reply-To: <5714C32C.6000905@tana.it> References: <57025643.7040101@tana.it> <5702946B.30307@tana.it> <570E8985.7080708@tana.it> <57125854.2030307@tana.it> <5714C32C.6000905@tana.it> Date: Mon, 18 Apr 2016 06:58:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a114383507a95290530c2c25a Archived-At: Cc: Scott Kitterman , Matthias Leisi , AppsAWG Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:58:55 -0000 --001a114383507a95290530c2c25a Content-Type: text/plain; charset=UTF-8 On Mon, Apr 18, 2016 at 4:21 AM, Alessandro Vesely wrote: > > If you look at the discussion of iprev in > > http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact > same > > ground as this proposal with regards to ptype selection. I believe it's > > clear that policy is the correct choice. > > I guess you mean the paragraph: > > The result is reported using a ptype of "policy" (as this is not part > of any established protocol) and a property of "iprev". > > That looks like an explanation of the naming, it doesn't seem to mandate > that > every ptype must be "policy" unless the related property belongs to an > established protocol. The definition of "policy" in Section 2.4 differs. > In what way? > Would a name like, say, client.ip=192.0.2.1 have been an equally valid > choice? > I think it would. > From that definition it is not clear if or why a method is bound to use at > most > one ptype. > There is no such restriction. > My understanding was that RFC7410 allowed to add new ptypes as needed > without > having to update the A-R header field name definition each time. Can you > envisage what kind of change would be required in order to call A DNS zone > dns.zone? > There would have to be a property of the message derived from the DNS. The property you're trying to report, i.e. the name of the DNSWL you queried, is a local configuration choice rather than something extracted from either SMTP or the message itself, so it falls squarely within the definition of "policy". -MSK --001a114383507a95290530c2c25a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 18, 2016 at 4:21 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> If you look= at the discussion of iprev in
> http://tools.ietf.org/html/rfc7601#section-2.7.= 3 it covers the exact same
> ground as this proposal with regards to ptype selection.=C2=A0 I belie= ve it's
> clear that policy is the correct choice.

I guess you mean the paragraph:

=C2=A0 =C2=A0The result is reported using a ptype of "policy" (as= this is not part
=C2=A0 =C2=A0of any established protocol) and a property of "iprev&quo= t;.

That looks like an explanation of the naming, it doesn't seem to mandat= e that
every ptype must be "policy" unless the related property belongs = to an
established protocol.=C2=A0 The definition of "policy" in Section= 2.4 differs.

In what way?
=C2=A0
Would a name like, say, client.ip=3D192.0.2.1 have been an equally valid ch= oice?

I think it would.
=C2=A0
>From that definition it is not clear if or why a method is bound to use at = most
one ptype.

There is no such restriction= .
=C2=A0
My understanding was that RFC7410 allowed to add new ptypes as needed witho= ut
having to update the A-R header field name definition each time.=C2=A0 Can = you
envisage what kind of change would be required in order to call A DNS zone<= br> dns.zone?

There would have to be a prop= erty of the message derived from the DNS.=C2=A0 The property you're try= ing to report, i.e. the name of the DNSWL you queried, is a local configura= tion choice rather than something extracted from either SMTP or the message= itself, so it falls squarely within the definition of "policy".<= br>
-MSK
--001a114383507a95290530c2c25a-- From nobody Mon Apr 18 09:06:24 2016 Return-Path: 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 05EC712E1C8 for ; Mon, 18 Apr 2016 09:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 XkC0hCA3kN2M for ; Mon, 18 Apr 2016 09:06:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDC212E1A8 for ; Mon, 18 Apr 2016 09:06:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AAE0318000F; Mon, 18 Apr 2016 09:05:54 -0700 (PDT) To: superuser@gmail.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160418160554.AAE0318000F@rfc-editor.org> Date: Mon, 18 Apr 2016 09:05:54 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, apps-discuss@ietf.org, vesely@tana.it Subject: [apps-discuss] [Editorial Errata Reported] RFC7601 (4671) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 16:06:24 -0000 The following errata report has been submitted for RFC7601, "Message Header Field for Indicating Message Authentication Status". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7601&eid=4671 -------------------------------------- Type: Editorial Reported by: Ale Section: 2.3 Original Text ------------- The "ptype" in the ABNF above indicates the general type of property being described by the result being reported, upon which the reported result was based. Coupled with the "property", which is more specific, they indicate from which particular part of the message the reported data were extracted. Corrected Text -------------- The "ptype" in the ABNF above indicates the general type of property being described by the value being reported, upon which the reported result was based. Coupled with the "property", which is more specific, they indicate from which particular part of the message the reported "pvalue"s were extracted. Notes ----- The original text can be understood in multiple ways, depending on the meaning attributed to the term "result". The corrected text I submit is one of the possible interpretations. Note that if the first appearance of the term is assumed to be the ABNF "result", then ptype becomes an attribute of method, thereby setting a limit of one ptype per resinfo, as coincidentally it actually is. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7601 (draft-ietf-appsawg-rfc7001bis-11) -------------------------------------- Title : Message Header Field for Indicating Message Authentication Status Publication Date : August 2015 Author(s) : M. Kucherawy Category : PROPOSED STANDARD Source : ART Area General Application Working Group Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Apr 18 09:37:00 2016 Return-Path: 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 C9BC412E281 for ; Mon, 18 Apr 2016 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.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 QBCswt-k9pHU for ; Mon, 18 Apr 2016 09:36:57 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFBD12E27B for ; Mon, 18 Apr 2016 09:36:57 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4776DC4023D for ; Mon, 18 Apr 2016 11:36:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1460997415; bh=bRDLgS1VXjIsBWYtF4TeDpXSACgyr88ojpqIZz5bfIk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A/RTmwp1qDww3MTGMhIUKmF4Ux77EM6IIFiih69fsoipbRP7mLoOLNqkc++dlgXOE QZx/7d+ygFHhi/T/5bm4GV4gJEIonxl5LZuMXugGupNVx2GtDkj6pcOxlcYOVhKrbK 2jNIkcZ5DXGdZzkBgfQDDkiab+Ap1KMSpwaEcjEM= From: Scott Kitterman To: AppsAWG Date: Mon, 18 Apr 2016 12:36:54 -0400 Message-ID: <1549185.XWxuN1SgMG@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-83-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5714C32C.6000905@tana.it> References: <5714C32C.6000905@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 16:36:59 -0000 On Monday, April 18, 2016 01:21:16 PM Alessandro Vesely wrote: > On Sat 16/Apr/2016 18:10:47 +0200 Scott Kitterman wrote: > > On April 16, 2016 11:38:24 AM EDT, "Murray S. Kucherawy" wrote: > >> On Sat, Apr 16, 2016 at 8:20 AM, Alessandro Vesely wrote: > >>> Yes, I rejected your proposal to use policy.zone=lists.dnswl.example, > >>> because it disagrees with the only existing implementation. When that > >>> was discussed, the syntax dns.zone=lists.dnswl.example was chosen > >>> because a DNSxL is a zone in the DNS, according to, say, RFC5782. > >>> Nobody realized that "dns" is not a valid RFC7601 ptype (and I still > >>> don't understand why). > >> > >> I've gone over the "why" with you at some length both at the Berlin > >> meeting and now on a thread subsequent to your request to IANA. > >> > >> While I'm sympathetic to some degree with the "installed base" argument, > >> I don't think it's reasonable to accept a registration that doesn't fit > >> within the defining RFC merely because there's a single existing > >> incorrect implementation. > > > > While I normally give pragmatic arguments (like alignment to existing > > practice) a lot of weight, in this case I agree with Murray that it would > > be a mistake. > > > > If you look at the discussion of iprev in > > http://tools.ietf.org/html/rfc7601#section-2.7.3 it covers the exact same > > ground as this proposal with regards to ptype selection. I believe it's > > clear that policy is the correct choice. > > I guess you mean the paragraph: > > The result is reported using a ptype of "policy" (as this is not part > of any established protocol) and a property of "iprev". > > That looks like an explanation of the naming, it doesn't seem to mandate > that every ptype must be "policy" unless the related property belongs to an > established protocol. The definition of "policy" in Section 2.4 differs. > > Would a name like, say, client.ip=192.0.2.1 have been an equally valid > choice? > > In order to add the proposed new ptype, I think the ptype definition in > > http://tools.ietf.org/html/rfc7601#section-2.3 would have to be changed > > and > > that would require a standards track update to RFC 7601. I don't think > > you > > want to go down that path. > > From that definition it is not clear if or why a method is bound to use at > most one ptype. > > My understanding was that RFC7410 allowed to add new ptypes as needed > without having to update the A-R header field name definition each time. > Can you envisage what kind of change would be required in order to call A > DNS zone dns.zone? The definition of ptype includes: The "ptype" in the ABNF above indicates the general type of property being described by the result being reported, upon which the reported result was based. Coupled with the "property", which is more specific, they indicate from which particular part of the message the reported data were extracted. The exception to ptype + property indicating which particular part of the message from which the data is extracted is policy. Iprev falls into policy specifically because (IMO) there is nothing extracted from the message. All the information is from the IP connection (i.e. the address) and from DNS (the rdns lookup). This is exactly the same situation as your DNSWL proposal, so I see no reason to treat it differently. Furthermore, I think that paragraph would need to be changed (and not via errata) to broaden the ptype definition to do what you propose, so even if I thought a dns ptype was appropriate, it couldn't just be added to the registry. Iprev is connect IP plus DNS lookup. Perhaps if you could explain why you think your DNSWL proposal is somethine else, it would help? Scott K From nobody Mon Apr 18 10:47:40 2016 Return-Path: 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 D1B0512D7A0 for ; Mon, 18 Apr 2016 10:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DNmEY8IYDaJA for ; Mon, 18 Apr 2016 10:47:37 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A23412E13F for ; Mon, 18 Apr 2016 10:47:37 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id c4so229336240vkb.3 for ; Mon, 18 Apr 2016 10:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0oiQgKH5zaIxPO8aeay5Q4XAMs3+sRe3jdlQOtSsTmw=; b=FlF+BySpDljM91gB1smt4DxKT2vDC68SshlHUoM8SEevHn/NkyUBzleYwma2va+V9P eeDTXBB20dWA4MlpY3PTrEcg3sAPEeEFIilISkkERY+MWuf8aZzcxToXnYvaSRBcIdzH izRI5vLldpCkJ9RMGA6l67EmOlpr5FUo5K0m3LFJ3RUW6JxY+5iZpQD8EosKKxoeMPtK ryIHp0xsxb56rvHdPSHLTx5wG6R3Y6IYBv/ZiE4GKucZzSNVIxPfcov0eL6jqzp0vcI1 67VRDBL+zLPYyuIHSbb/DCuoh2HCf7BVx7ha24pEAIPqNbLx8mGLc5joPg9YbTsObp0X S7Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0oiQgKH5zaIxPO8aeay5Q4XAMs3+sRe3jdlQOtSsTmw=; b=dhWEltN9mNh2OPYUCQxkmKDAB5pbnQJTFtpg8qs0VT6UxeDPiJWf5iOpN/jBD3tv9Z S3PpELqBw2OOGmqFJaSMXmux9s+AvRuEf7ulzX865nDzD0A91Vwl0rJ0qY0X68AQds8C mxYfnNyOLBsyOmKp2LEXEOJ5RrPysBX9e9kGUmA19btAowWNd+d1q4GZY6m5LIucPGa7 paYerBUtDUUJDZr2klqltxmds5rygkr53Nc4OQn7+JZck7scrhBPjXoB2bBsSOct6RHR ji58Poh5ALenKtvYcL40R79Z8ZmUNKtMjSZ5RRIJXLZWFRjH0DOTuy0eN1hoPcslJ9bU 8SVg== X-Gm-Message-State: AOPr4FUYu44u1Y4NvzjHkHirK/hOzk8bdCym566kEsDvofHgt1Ju6y33lPjsTcg+fMhjmK/OKyzjCNhGPHo04w== MIME-Version: 1.0 X-Received: by 10.176.0.106 with SMTP id 97mr2605014uai.113.1461001656695; Mon, 18 Apr 2016 10:47:36 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Mon, 18 Apr 2016 10:47:36 -0700 (PDT) In-Reply-To: <20160418160554.AAE0318000F@rfc-editor.org> References: <20160418160554.AAE0318000F@rfc-editor.org> Date: Mon, 18 Apr 2016 10:47:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: RFC Errata System Content-Type: multipart/alternative; boundary=001a113e4d9cc3803f0530c5f495 Archived-At: Cc: Ben Campbell , Alessandro Vesely , IETF Apps Discuss , Alexey Melnikov Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC7601 (4671) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:47:38 -0000 --001a113e4d9cc3803f0530c5f495 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 18, 2016 at 9:05 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > Corrected Text > -------------- > The "ptype" in the ABNF above indicates the general type of property > being described by the value being reported, upon which the reported > result was based. Coupled with the "property", which is more > specific, they indicate from which particular part of the message the > reported "pvalue"s were extracted. > > > > Notes > ----- > The original text can be understood in multiple ways, depending on the > meaning attributed to the term "result". The corrected text I submit is > one of the possible interpretations. Note that if the first appearance of > the term is assumed to be the ABNF "result", then ptype becomes an > attribute of method, thereby setting a limit of one ptype per resinfo, as > coincidentally it actually is. > Though it would be nice if there was some more obvious way to disambiguate other than renaming the tokens into non-words, I note that the quoted strings in both the original and corrected versions refer to ABNF tokens, however "result" is not quoted, and doesn't refer to the ABNF. As for the correction, to be more grammatically correct, I would use: -- BEGIN -- The "ptype" in the ABNF above indicates the general type of property being described by the value being reported, upon which the reported result was based. Coupled with the "property", which is more specific, it indicates from which particular part of the message the "pvalue" was extracted. -- END -- Otherwise, the suggestion seems fine to me, though I disagree with the characterization that there's a limit of one ptype per resinfo. There's nothing precluding the existence of a method that bases its result on two distinct ptype/properties, or chooses to report none, for example. -MSK --001a113e4d9cc3803f0530c5f495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 18, 2016 at 9:05 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
Corrected T= ext
--------------
=C2=A0 =C2=A0The "ptype" in the ABNF above indicates the general = type of property
=C2=A0 =C2=A0being described by the value being reported, upon which the re= ported
=C2=A0 =C2=A0result was based.=C2=A0 Coupled with the "property",= which is more
=C2=A0 =C2=A0specific, they indicate from which particular part of the mess= age the
=C2=A0 =C2=A0reported "pvalue"s were extracted.



Notes
-----
The original text can be understood in multiple ways, depending on the mean= ing attributed to the term "result".=C2=A0 The corrected text I s= ubmit is one of the possible interpretations.=C2=A0 Note that if the first = appearance of the term is assumed to be the ABNF "result", then p= type becomes an attribute of method, thereby setting a limit of one ptype p= er resinfo, as coincidentally it actually is.

Though it would be nice if there was some more obvious way to disamb= iguate other than renaming the tokens into non-words, I note that the quote= d strings in both the original and corrected versions refer to ABNF tokens,= however "result" is not quoted, and doesn't refer to the ABN= F.

As for the correction, to be more grammatically correct, I would = use:

-- BEGIN --
The "ptype" in t= he ABNF above indicates the general type of property being described by the= value being reported, upon which the reported result was based.=C2=A0 Coup= led with the "property", which is more specific, it indicates fro= m which particular part of the message the "pvalue" was extracted= .
-- END --

Otherwise, the suggestion seems= fine to me, though I disagree with the characterization that there's a= limit of one ptype per resinfo.=C2=A0 There's nothing precluding the e= xistence of a method that bases its result on two distinct ptype/properties= , or chooses to report none, for example.

-MSK
<= /div>
--001a113e4d9cc3803f0530c5f495-- From nobody Tue Apr 19 09:50:31 2016 Return-Path: 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 EA27012E1D7 for ; Tue, 19 Apr 2016 09:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it 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 t04YSoSLGLtO for ; Tue, 19 Apr 2016 09:50:28 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C1012E1D2 for ; Tue, 19 Apr 2016 09:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1461084622; bh=Gxq3gNmLMSRtf/cP/8odnwXD+W7AzjWW4LMKH2M0dRs=; l=3067; h=To:References:From:Date:In-Reply-To; b=WCtjQUYsB+LIfK5n5JJ5rklf1kWaBW/aAwmkZk9uWYGXPY98J9okYQn/pbiVlLUpe YuqyJShy7/9I/D8Y5ovFUTS3Nxvgp7iYpEhAHV0iNlV4j0AvdhYUYoiCccP9t6GM3c mpp/AWKFBUHbdiFsW9uTlzI4ru3ba8fXPdIo8ymY= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 19 Apr 2016 18:50:22 +0200 id 00000000005DC033.00000000571661CE.00002B7D To: Scott Kitterman , AppsAWG References: <5714C32C.6000905@tana.it> <1549185.XWxuN1SgMG@kitterma-e6430> From: Alessandro Vesely Message-ID: <571661CE.4000202@tana.it> Date: Tue, 19 Apr 2016 18:50:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <1549185.XWxuN1SgMG@kitterma-e6430> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 16:50:30 -0000 On Mon 18/Apr/2016 18:36:54 +0200 Scott Kitterman wrote: > On Monday, April 18, 2016 01:21:16 PM Alessandro Vesely wrote: > >> My understanding was that RFC7410 allowed to add new ptypes as needed >> without having to update the A-R header field name definition each time. >> Can you envisage what kind of change would be required in order to call A >> DNS zone dns.zone? > > The definition of ptype includes: > > The "ptype" in the ABNF above indicates the general type of property > being described by the result being reported, upon which the reported > result was based. Coupled with the "property", which is more > specific, they indicate from which particular part of the message the > reported data were extracted. > > The exception to ptype + property indicating which particular part of the > message from which the data is extracted is policy. Section 2.4 does not present "policy" as an exception in that sense. It highlights the possibility to alter the result of established protocols, and the local nature. > Iprev falls into policy specifically because (IMO) there is nothing > extracted from the message. All the information is from the IP connection > (i.e. the address) and from DNS (the rdns lookup). It seems the concept of "policy" was stretched a bit in order to accommodate that fact. Both ptype and property sound wrong in "policy.iprev". That undoubtedly constitutes a precedent. I agree it would be smoother to use "policy.zone" on that basis. > This is exactly the same situation as your DNSWL proposal, so I see no reason > to treat it differently. Iprev differs inasmuch as it doesn't require a reputation provider. These three methods, SPF, iprev, and dnswl, all stem from the client IP and deliver results on the basis of DNS queries. However, only dnswl presents a choice of provider, and only SPF is an authentication method. > Furthermore, I think that paragraph would need to be changed (and not via > errata) to broaden the ptype definition to do what you propose, so even if I > thought a dns ptype was appropriate, it couldn't just be added to the > registry. I'm unable to find a passage in RFC7601 that forbids adding "dns". I agree there are several indications, such as references to "part of the message", that may suggest "dns" is not a valid ptype. But then the same is true for "policy", and it is not stated that the introduction of another special ptype requires the specs to be changed. > Iprev is connect IP plus DNS lookup. Perhaps if you could explain why you > think your DNSWL proposal is something else, it would help? A reputation provider is a globally identifiable entity. That trait is usually expressed referring to DNS. By introducing the "dns" ptype, we pave the way for storing reputation results in A-R fields. For example, it can be reused for a prospective "dns.rater" (RFC7071). I think this can be done by consensus; it doesn't seem to require that the field name be changed to, say, Authentication-And-Reputation-Results. Ale From nobody Tue Apr 19 13:42:55 2016 Return-Path: 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 6ECCD12D8B0 for ; Tue, 19 Apr 2016 13:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ddGoN7o5EwTV for ; Tue, 19 Apr 2016 13:42:52 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C450C12D543 for ; Tue, 19 Apr 2016 13:42:51 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id e185so34924727vkb.1 for ; Tue, 19 Apr 2016 13:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rHotYzoLklvbH/ZKoW6gnNjHJSX5EaVOsPCCL4A0u0s=; b=mJCFEGsnMdL6zWOlA/6IJyRbMJqc3eym+5LS6jchEEehR0wOYabo6eNu+CnYylGInB gul6Bb+iz8PXlii7jOmnKjdYTaHdj0ZwqKJM4reqtSCr7t3osf5oxGnd5ickWPxIpbnE A2nS3VtDSxWSos0UoaTj3zJJbFLOkTDnv3scEw0Gx1E7QCfBfEe2BvaYEFfSqeqZF4pq hfQQH5K/PbXH85y1C4DOMmddGAnDnXmIJqfDKgABHWC+CIjMHlgm5pBuhKz46akx7uR3 OcTiJeattn0QmZqfcE/YJ8EYVaJNv2NhHzOKwLzf5LPn+Z8W0YtM3L7UaQvCmNlehORX IKog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rHotYzoLklvbH/ZKoW6gnNjHJSX5EaVOsPCCL4A0u0s=; b=Edq4YOvLAw4bIiUFURwFm41ta4MY7c5Olnh+aAmEbowVzl/3uoYYTfhXxVfNInleHh 5wjnkPS5dqt8VDqib+TrGNOsoTLPwnywmrwrHuJbKQGWQifEvScilL2PlYQH2fesNZlx R0UdxERh+y1vzxNfCmFZ8eQZdlXsV+liLpfhm9mt+EHYTKjJoVx1rrbNga2u5VYSmFG8 E/5NQNTcsfkut9CTvxx8ejp3nH6EZpJcODImGO7iPwyNqr6G9D1IXWr6FdlSP9J1Aogg TH1EqUPnszWe0nFxq7eVLD04ZX35pHxY95EQwU65UkPrCEC4CLzaf50J2NSm7jRuSIBR vd7w== X-Gm-Message-State: AOPr4FWZKpke29k4ABmRRIYH3kQ8ltA63LMZ0u3V7huRjSM9vf4eiIS7Cpj5EeXK9y3l1O0obSchplVlhlUq1w== MIME-Version: 1.0 X-Received: by 10.31.151.11 with SMTP id z11mr2810893vkd.131.1461098570813; Tue, 19 Apr 2016 13:42:50 -0700 (PDT) Received: by 10.103.43.5 with HTTP; Tue, 19 Apr 2016 13:42:50 -0700 (PDT) In-Reply-To: <571661CE.4000202@tana.it> References: <5714C32C.6000905@tana.it> <1549185.XWxuN1SgMG@kitterma-e6430> <571661CE.4000202@tana.it> Date: Tue, 19 Apr 2016 13:42:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a1140f86a4b99360530dc85ea Archived-At: Cc: Scott Kitterman , AppsAWG Subject: Re: [apps-discuss] [IANA #900093] Re: draft-vesely-authmethod-dnswl X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:42:54 -0000 --001a1140f86a4b99360530dc85ea Content-Type: text/plain; charset=UTF-8 On Tue, Apr 19, 2016 at 9:50 AM, Alessandro Vesely wrote: > > The definition of ptype includes: > > > > The "ptype" in the ABNF above indicates the general type of property > > being described by the result being reported, upon which the reported > > result was based. Coupled with the "property", which is more > > specific, they indicate from which particular part of the message the > > reported data were extracted. > > > > The exception to ptype + property indicating which particular part of the > > message from which the data is extracted is policy. > > Section 2.4 does not present "policy" as an exception in that sense. It > highlights the possibility to alter the result of established protocols, > and > the local nature. > The very reason "policy" has its own section of the document is because it is an exception. You're doing something -- reporting a local configuration parameter with no context outside of the receiving ADMD -- that's not specified as part of some other protocol, and identifies something not found in the message. Currently, a DNSWL lookup fits both of those criteria. Even if we register "dnswl" as a method, the latter point remains true. The example given in that section actually shows what I would think of as an ideal use of "dnswl", namely: Authentication-Results: dnswl={pass/fail/whatever} policy.zone={your.dnswl.here} "policy.zone" is augmenting the "dnswl" result by providing additional local data. The zone itself is not part of the message, so it's not a candidate for a dedicated ptype. > > Iprev falls into policy specifically because (IMO) there is nothing > > extracted from the message. All the information is from the IP > connection > > (i.e. the address) and from DNS (the rdns lookup). > > It seems the concept of "policy" was stretched a bit in order to > accommodate > that fact. Both ptype and property sound wrong in "policy.iprev". That > undoubtedly constitutes a precedent. I agree it would be smoother to use > "policy.zone" on that basis. > I disagree. "policy" was used for "iprev" precisely because the IP address isn't part of a message payload. That wasn't a "stretch". You could argue that it should've been "policy.ip" or "policy.client_ip" or some such, but no objection was raised when the document was in development. To continue with the comparison with "iprev", however, note that it makes no attempt to report from which nameserver the answer came. > This is exactly the same situation as your DNSWL proposal, so I see no > reason > > to treat it differently. > > Iprev differs inasmuch as it doesn't require a reputation provider. These > three methods, SPF, iprev, and dnswl, all stem from the client IP and > deliver > results on the basis of DNS queries. However, only dnswl presents a > choice of > provider, and only SPF is an authentication method. > I suggest that SPF is answering a different question: "Was use of in this message authorized?" The actual mechanism does take the IP address as one of its inputs, of course, but it's not the datum in which a consumer of this information is really interested. > > Furthermore, I think that paragraph would need to be changed (and not via > > errata) to broaden the ptype definition to do what you propose, so even > if I > > thought a dns ptype was appropriate, it couldn't just be added to the > > registry. > > I'm unable to find a passage in RFC7601 that forbids adding "dns". Please try again, starting with the first paragraph of Section 2.3 (cited above). It doesn't seem weak or ambiguous to me, especially given the registrations that exist and the numerous examples present in production and in the document. I agree there are several indications, such as references to "part of the > message", > that may suggest "dns" is not a valid ptype. But then the same is true for > "policy", and it is not stated that the introduction of another special > ptype > requires the specs to be changed. > As I said above, and Scott also said, "policy" is defined as an exception ptype. It boils down to "ptypes are for reporting X, except for 'policy', which is for reporting Y". You can introduce as many ptypes as you like into the registry that are for reporting things described as "X" without updating the RFC. To change "X" to accommodate your use case, however, there needs to be an update to RFC7601, and thus a compelling reason to spin up that effort. Speaking for myself, I don't see that here given the absence of demand, the availability of suggested alternatives that do fit within the existing framework, and your concessions above that the suggestions would indeed be smoother. -MSK --001a1140f86a4b99360530dc85ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 19, 2016 at 9:50 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> The definition of ptype includes:
>
>=C2=A0 =C2=A0 The "ptype" in the ABNF above indicates the gen= eral type of property
>=C2=A0 =C2=A0 being described by the result being reported, upon which = the reported
>=C2=A0 =C2=A0 result was based.=C2=A0 Coupled with the "property&q= uot;, which is more
>=C2=A0 =C2=A0 specific, they indicate from which particular part of the= message the
>=C2=A0 =C2=A0 reported data were extracted.
>
> The exception to ptype + property indicating which particular part of = the
> message from which the data is extracted is policy.

Section 2.4 does not present "policy" as an exception in t= hat sense.=C2=A0 It
highlights the possibility to alter the result of established protocols, an= d
the local nature.

The very reason "= ;policy" has its own section of the document is because it is an excep= tion.=C2=A0 You're doing something -- reporting a local configuration p= arameter with no context outside of the receiving ADMD -- that's not sp= ecified as part of some other protocol, and identifies something not found = in the message.=C2=A0 Currently, a DNSWL lookup fits both of those criteria= .=C2=A0 Even if we register "dnswl" as a method, the latter point= remains true.

The example given in that section actually= shows what I would think of as an ideal use of "dnswl", namely:<= br>
Authentication-Results: dnswl=3D{pass/fail/whatever} poli= cy.zone=3D{your.dnswl.here}

"policy.zone" is au= gmenting the "dnswl" result by providing additional local data.= =C2=A0 The zone itself is not part of the message, so it's not a candid= ate for a dedicated ptype.
=C2=A0
> Iprev falls into policy specifically because (IMO) th= ere is nothing
> extracted from the message.=C2=A0 All the information is from the IP c= onnection
> (i.e. the address) and from DNS (the rdns lookup).

It seems the concept of "policy" was stretched a bit in or= der to accommodate
that fact.=C2=A0 Both ptype and property sound wrong in "policy.iprev&= quot;.=C2=A0 That
undoubtedly constitutes a precedent.=C2=A0 I agree it would be smoother to = use
"policy.zone" on that basis.

= I disagree.=C2=A0 "policy" was used for "iprev" precise= ly because the IP address isn't part of a message payload.=C2=A0 That w= asn't a "stretch".=C2=A0 You could argue that it should'v= e been "policy.ip" or "policy.client_ip" or some such, = but no objection was raised when the document was in development.

To continue with the comparison with "iprev", however, n= ote that it makes no attempt to report from which nameserver the answer cam= e.

> This is exactly the same situation as your DNSWL prop= osal, so I see no reason
> to treat it differently.

Iprev differs inasmuch as it doesn't require a reputation provid= er.=C2=A0 These
three methods, SPF, iprev, and dnswl, all stem from the client IP and deliv= er
results on the basis of DNS queries.=C2=A0 However, only dnswl presents a c= hoice of
provider, and only SPF is an authentication method.
I suggest that SPF is answering a different question: "Wa= s use of <domain> in this message authorized?"=C2=A0 The actual = mechanism does take the IP address as one of its inputs, of course, but it&= #39;s not the datum in which a consumer of this information is really inter= ested.
=C2=A0
> Furthermore, I think that paragraph would need to be = changed (and not via
> errata) to broaden the ptype definition to do what you propose, so eve= n if I
> thought a dns ptype was appropriate, it couldn't just be added to = the
> registry.

I'm unable to find a passage in RFC7601 that forbids adding &quo= t;dns".

Please try again, starting wit= h the first paragraph of Section 2.3 (cited above).=C2=A0 It doesn't se= em weak or ambiguous to me, especially given the registrations that exist a= nd the numerous examples present in production and in the document.

=
I agree there are s= everal indications, such as references to "part of the message",<= br> that may suggest "dns" is not a valid ptype.=C2=A0 But then the s= ame is true for
"policy", and it is not stated that the introduction of another s= pecial ptype
requires the specs to be changed.

As I = said above, and Scott also said, "policy" is defined as an except= ion ptype.

It boils down to "ptypes are f= or reporting X, except for 'policy', which is for reporting Y"= .=C2=A0 You can introduce as many ptypes as you like into the registry that= are for reporting things described as "X" without updating the R= FC.=C2=A0 To change "X" to accommodate your use case, however, th= ere needs to be an update to RFC7601, and thus a compelling reason to spin = up that effort.=C2=A0 Speaking for myself, I don't see that here given = the absence of demand, the availability of suggested alternatives that do f= it within the existing framework, and your concessions above that the sugge= stions would indeed be smoother.

-MSK
--001a1140f86a4b99360530dc85ea-- From nobody Tue Apr 19 22:23:46 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8420612DAD2; Tue, 19 Apr 2016 22:23:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 22:23:42 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:23:42 -0000 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 of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-07.txt Pages : 19 Date : 2016-04-19 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 19 22:43:41 2016 Return-Path: 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 D779B12DCB7 for ; Tue, 19 Apr 2016 22:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vfQ0u_kN0GoE for ; Tue, 19 Apr 2016 22:43:37 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE4112DC6F for ; Tue, 19 Apr 2016 22:43:37 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id 2so41954593ioy.1 for ; Tue, 19 Apr 2016 22:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=x0vyI2+D91Mv8p/iQBDSa2riRBuV9qg6kl4NS0cp1OY=; b=hQl8CldjX2OyJyeCbjFQZlupsa3P/ahqbkeAzsy6tOOQcj8pynFnPnk9qWiYtF+Div MsxszAzz+RzHfeGp3B9uQOOmOFUtscW0B+2Av7lhqmpkU9i0J2McpIOTpL9UVnk2sYoi ip0tfFGzSCFTwV+x92Uusn5dQsqWVqQP3ARKiDKnDTdzGGtmjRQlQGJNe88U31o/erUM ikmKcOF3KaPcbJ+lZqvgGVU5/bC01UgeP7ZRvwisOtYL88GShrVDgN85Z8WhD3+o/Cko ogR5850p701JcuvA+FgUrFZGqX/t9Ne76vIYGbCf20Nxngn2E+xtGKRQURKTK7EaZHNH Nj9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=x0vyI2+D91Mv8p/iQBDSa2riRBuV9qg6kl4NS0cp1OY=; b=WyNTKRrMm2ipZECEBSWtaBBUJD78fNOj8MlIoV4YbbtLCJchfUHpYuGuQvU4LCmHpJ JW29BHLhAux/BOHtohnf5TrfccOZOIJJGEXANmlZ1JbKsygaJa4l4x92NyubylDlsmbf KVI7PjLG8XnxBXFpOoImo7tLaJfuE/2t6P/OTkN3kViGAiNyF364ETiLCBqrT4eqNKyE BfU6ZOhvsPGtjSzQHSzayJvo+H6NELcuKEfrakfPhBjA1QzcdcQ6irKKAxW58o5IiLzN bC6uy4mHIQC0kxpkRFGN6J09mtnBABq3RSHMlb/yeghXhSyvVY7WVJtx8xuqA3/c9NEJ ie+Q== X-Gm-Message-State: AOPr4FUFVZwiWuFXMB1AuISfU6awFxAKCEZ6rTEBCWjE7JPsHCjp6Y3+cVBdF9vZVpveVNb5xHLBj+I039Gu7Q== MIME-Version: 1.0 X-Received: by 10.107.6.94 with SMTP id 91mr7771248iog.176.1461131016811; Tue, 19 Apr 2016 22:43:36 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.4.2 with HTTP; Tue, 19 Apr 2016 22:43:36 -0700 (PDT) In-Reply-To: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> References: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 15:43:36 +1000 X-Google-Sender-Auth: 6N035VoRAEFAqRC_dMwmfBCwhGA Message-ID: From: Matthew Kerwin To: IETF Apps Discuss , Murray Kucherawy Content-Type: multipart/alternative; boundary=001a113f8d423a39980530e4132e Archived-At: Cc: Julian Reschke , Mark Nottingham , Graham Klyne , Dave Crocker Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 05:43:40 -0000 --001a113f8d423a39980530e4132e Content-Type: text/plain; charset=UTF-8 Hi everyone, I've pushed out an -07 version of the file URI draft. It's substantially different from 06, mostly in removing a bunch of text from the main body (some of which is now located in appendices). As mentioned, or at least hinted, in my email replies, I've adopted most of the changes recommended by Dave Crocker and Graham Klyne in their reviews. There are still a couple of 'fixmes' though: * I haven't touched Dave's suggestion that I cut back the Encoding section. * The Security Considerations mentions possible issues from case-sensitive aliasing, but still hasn't got anything addressing Julian Reschke's advice to include encoding/Unicode normalization. * There are a couple of places in the text where the normativity of statements isn't clear. These are marked by a "(?)" * I'm not sure how to address Mark Nottingham's questions about fitting in with WWW specs like FETCH, URL, and Origin. Other than that, I personally feel like this is the best version of the draft I've submitted. The main spec body is down to four pages (about 8 pages with headers and references), and it's really clear what is defined (a normative syntax) and what is not (all the optional/non-standard stuff in the appendices.) I think it's definitely a substantial enough change to warrant being put back to WGLC. Further reviews are, as always, appreciated. Assuming no blockers emerge I'll try to keep future changes very small and manageable. Cheers On 20 April 2016 at 15:23, 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 of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-07.txt > Pages : 19 > Date : 2016-04-19 > > Abstract: > This document specifies the "file" Uniform Resource Identifier (URI) > scheme, obsoleting the definition in RFC 1738. > > It defines a common syntax which is intended to interoperate across > the broad spectrum of existing usages. At the same time it notes > some other current practices around the use of file URIs. > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area Working > Group discussion list . > > > 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-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-07 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Matthew Kerwin http://matthew.kerwin.net.au/ --001a113f8d423a39980530e4132e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

I've pushed = out an -07 version of the file URI draft. It's substantially different = from 06, mostly in removing a bunch of text from the main body (some of whi= ch is now located in appendices).

As mentioned, or= at least hinted, in my email replies, I've adopted most of the changes= recommended by Dave Crocker and Graham Klyne in their reviews. There are s= till a couple of 'fixmes' though:

* I haven&= #39;t touched Dave's suggestion that I cut back the Encoding section.

* The Security Considerations mentions possible issue= s from case-sensitive aliasing, but still hasn't got anything addressin= g Julian Reschke's advice to include encoding/Unicode normalization.

* There are a couple of places in the text where the n= ormativity of statements isn't clear. These are marked by a "(?)&q= uot;

* I'm not sure how to address Mark Nottingh= am's questions about fitting in with WWW specs like FETCH, URL, and Ori= gin.

Other than that, I personally feel like this is= the best version of the draft I've submitted. The main spec body is do= wn to four pages (about 8 pages with headers and references), and it's = really clear what is defined (a normative syntax) and what is not (all the = optional/non-standard stuff in the appendices.)

I th= ink it's definitely a substantial enough change to warrant being put ba= ck to WGLC.

Further reviews are, as always, apprecia= ted. Assuming no blockers emerge I'll try to keep future changes very s= mall and manageable.

Cheers

On 20 April 2016 at 15:23, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the ART Area General Applications Working Grou= p of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Matt= hew Kerwin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-file-scheme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-04-19

Abstract:
=C2=A0 =C2=A0This document specifies the "file" Uniform Resource = Identifier (URI)
=C2=A0 =C2=A0scheme, obsoleting the definition in RFC 1738.

=C2=A0 =C2=A0It defines a common syntax which is intended to interoperate a= cross
=C2=A0 =C2=A0the broad spectrum of existing usages.=C2=A0 At the same time = it notes
=C2=A0 =C2=A0some other current practices around the use of file URIs.

Note to Readers (To be removed by the RFC Editor)

=C2=A0 =C2=A0This draft should be discussed on the IETF Applications Area W= orking
=C2=A0 =C2=A0Group discussion list <apps-discuss@ietf.org>.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-= appsawg-file-scheme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-appsawg-file-scheme-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at 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
https://www.ietf.org/mailman/listinfo/apps-discuss=



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--001a113f8d423a39980530e4132e-- From nobody Wed Apr 20 16:18:55 2016 Return-Path: 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 D4D4712D5EA for ; Wed, 20 Apr 2016 16:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 cppK0MOiFdCd for ; Wed, 20 Apr 2016 16:18:51 -0700 (PDT) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B889912D194 for ; Wed, 20 Apr 2016 16:18:51 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay14.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1at1OF-0006F5-lv; Thu, 21 Apr 2016 00:18:35 +0100 Received: from gklyne38.plus.com ([81.174.129.24] helo=sasharissa.local) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1at1OF-0003i9-IM; Thu, 21 Apr 2016 00:18:35 +0100 Message-ID: <57180E49.1090909@ninebynine.org> Date: Thu, 21 Apr 2016 00:18:33 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , IETF Apps Discuss , Murray Kucherawy References: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Julian Reschke , Mark Nottingham , Dave Crocker Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 23:18:54 -0000 Hi Matthew, I think the main body of the document is a lot crisper now. I have a couple of comments from a fairly quick scan. The main substantive comment is that local access can occur when the file URI contains a host name which is the same as that for the host from which access is being attempted. I've not done a detailed read through of the appendices - much of the material there is outside my experience. ... Section 2: [[ Some file systems allow directory objects to be treated as files in some cases. This can be reflected in a file URI by omitting the trailing slash "/" from the path. Be aware that merging a relative URI reference to such a base URI as per Section 5.2 of [RFC3986] could remove the directory name from the resulting target URI. ]] I think the second sentence is wandering into local implementation details. I'd suggest focusing more on the idea that the trailing slash should be included in URIs that refer to directories. ... Section 3: [[ A file URI can be dependably dereferenced or translated to a local file path only if it is local. A file URI is considered "local" if it has no "file-auth", or the "file-auth" is the special string "localhost". ]] There's also the case when the hostname resolves to the local host. #g -- On 20/04/2016 06:43, Matthew Kerwin wrote: > Hi everyone, > > I've pushed out an -07 version of the file URI draft. It's substantially > different from 06, mostly in removing a bunch of text from the main body > (some of which is now located in appendices). > > As mentioned, or at least hinted, in my email replies, I've adopted most of > the changes recommended by Dave Crocker and Graham Klyne in their reviews. > There are still a couple of 'fixmes' though: > > * I haven't touched Dave's suggestion that I cut back the Encoding section. > > * The Security Considerations mentions possible issues from case-sensitive > aliasing, but still hasn't got anything addressing Julian Reschke's advice > to include encoding/Unicode normalization. > > * There are a couple of places in the text where the normativity of > statements isn't clear. These are marked by a "(?)" > > * I'm not sure how to address Mark Nottingham's questions about fitting in > with WWW specs like FETCH, URL, and Origin. > > Other than that, I personally feel like this is the best version of the > draft I've submitted. The main spec body is down to four pages (about 8 > pages with headers and references), and it's really clear what is defined > (a normative syntax) and what is not (all the optional/non-standard stuff > in the appendices.) > > I think it's definitely a substantial enough change to warrant being put > back to WGLC. > > Further reviews are, as always, appreciated. Assuming no blockers emerge > I'll try to keep future changes very small and manageable. > > Cheers > > On 20 April 2016 at 15:23, 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 of the IETF. >> >> Title : The file URI Scheme >> Author : Matthew Kerwin >> Filename : draft-ietf-appsawg-file-scheme-07.txt >> Pages : 19 >> Date : 2016-04-19 >> >> Abstract: >> This document specifies the "file" Uniform Resource Identifier (URI) >> scheme, obsoleting the definition in RFC 1738. >> >> It defines a common syntax which is intended to interoperate across >> the broad spectrum of existing usages. At the same time it notes >> some other current practices around the use of file URIs. >> >> Note to Readers (To be removed by the RFC Editor) >> >> This draft should be discussed on the IETF Applications Area Working >> Group discussion list . >> >> >> 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-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-07 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Apr 20 21:06:59 2016 Return-Path: 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 45D1A12E5F7 for ; Wed, 20 Apr 2016 21:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nNDRjmdOzsnv for ; Wed, 20 Apr 2016 21:06:55 -0700 (PDT) Received: from mail-ig0-x241.google.com (mail-ig0-x241.google.com [IPv6:2607:f8b0:4001:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7510812E599 for ; Wed, 20 Apr 2016 21:06:55 -0700 (PDT) Received: by mail-ig0-x241.google.com with SMTP id qu10so9055955igc.1 for ; Wed, 20 Apr 2016 21:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=V9zDLl7+ZyGsBD3RG5Fn0Ywt1T9AK+G36UU9ri3ZL74=; b=OlxRXGOPeAPWCdksWWnXod79eIP+ooRtRtSXkL+edV9c0xklx1Yf0Q9GxOOeWS7xNv qNNljjTsfXt07KQe1Ov2qxESnyrO2Tjmu4rgWV/gxZL1HXCrTW+vmX091prnaqS0+o4s WFpf5oOKbUdSVT741pcC+gu0/INQ5DE2vmxBim1GH/ewh9NhJz8qM/Jy7gPYotmHR36V DbJD/HA9wjlNiNooceBztUfv5GgkLvbXOZ4MFjmVNgpq103XEOj4CIqVrPP7+e+qXQF/ +WUFETM1DTD4gx9lIBtO+zKhNsUezZVZaA7wvqhyjt3YWYqKCp6ob1excLnThexqa2p2 NuYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=V9zDLl7+ZyGsBD3RG5Fn0Ywt1T9AK+G36UU9ri3ZL74=; b=TIKS82o6jmXsVCus83K/83AME6XsbhbmxYPxkN3UxwpSuV/yg7IaUS/b7QI0Bzn/oP 9Krkg0Qba23xidmElPYabapH0T6tYTZh/YCMFPs5Tzxf15brfkvjX9yChYPUWRqiMVXS raZybzn8cJLSToHYJouPucIpeVlqDyJyVfAs7zAMP33/B/bO1mhzGn/Zldoi5kB3H/sZ pKKgxO1FqmezewJw9nsP4mvzI+eV/B8MzV59pfFKnALZTyp5T8/KiLdGjTbHW315K9hq KpkqCkmwmYeiDLJQ554xf1w4RjF3fff9UOWmFJZmwYz3gSK6e7Dx/OJ7QKB8MnDZKqOd sY2g== X-Gm-Message-State: AOPr4FXCjNsLLDxFPbXx4OCP+z+aDYY1OkwUVbwU9SLks5R2TqgIcduIGLhMnn8pQVPolgbihxwJt9d8M9fHEw== MIME-Version: 1.0 X-Received: by 10.50.27.39 with SMTP id q7mr984383igg.34.1461211614774; Wed, 20 Apr 2016 21:06:54 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.4.2 with HTTP; Wed, 20 Apr 2016 21:06:54 -0700 (PDT) In-Reply-To: <57180E49.1090909@ninebynine.org> References: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> <57180E49.1090909@ninebynine.org> Date: Thu, 21 Apr 2016 14:06:54 +1000 X-Google-Sender-Auth: 8mJGcejpVuOyi5fxMKk3PE3pIOw Message-ID: From: Matthew Kerwin To: Graham Klyne Content-Type: multipart/alternative; boundary=047d7b10ce153d950b0530f6d732 Archived-At: Cc: Julian Reschke , Mark Nottingham , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 04:06:58 -0000 --047d7b10ce153d950b0530f6d732 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Graham, Thanks for the review again. On 21 April 2016 at 09:18, Graham Klyne wrote: > Hi Matthew, > > I think the main body of the document is a lot crisper now. I have a > couple of comments from a fairly quick scan. The main substantive commen= t > is that local access can occur when the file URI contains a host name whi= ch > is the same as that for the host from which access is being attempted. > > You know what, I think you're right, and I've been suffering from confirmation bias. I just tested it again, and both Chromium and Firefox do treat my machine's network name the same as "localhost". Windows and IE do it the way I've documented in the draft, but it seems they're the only ones. (If only I'd had mnot's test suite ...) I'll change all the appropriate parts to say the right thing. I've not done a detailed read through of the appendices - much of the > material there is outside my experience. > > Appendices A and B are the generally useful ones. ... > > Section 2: > > [[ > Some file systems allow directory objects to be treated as files in > some cases. This can be reflected in a file URI by omitting the > trailing slash "/" from the path. Be aware that merging a relative > URI reference to such a base URI as per Section 5.2 of [RFC3986] > could remove the directory name from the resulting target URI. > ]] > > I think the second sentence is wandering into local implementation > details. I'd suggest focusing more on the idea that the trailing slash > should be included in URIs that refer to directories. > > I preferred stating the use-case and the potential problems it causes, rather than making a judgement call. I'm not 100% invested in it, though, and can cut it back if it's too far the wrong way. ... > > > Section 3: > > [[ > A file URI can be dependably dereferenced or translated to a local > file path only if it is local. A file URI is considered "local" if > it has no "file-auth", or the "file-auth" is the special string > "localhost". > ]] > > There's also the case when the hostname resolves to the local host. > > Yep, I will include that when I make the change. =E2=80=8BCheers --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --047d7b10ce153d950b0530f6d732 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Graham,

Thanks for the revie= w again.

On = 21 April 2016 at 09:18, Graham Klyne <gk@ninebynine.org> wro= te:
Hi Matthew,

I think the main body of the document is a lot crisper now.=C2=A0 I have a = couple of comments from a fairly quick scan.=C2=A0 The main substantive com= ment is that local access can occur when the file URI contains a host name = which is the same as that for the host from which access is being attempted= .


You know what, I think you= 9;re right, and I've been suffering from confirmation bias. I just test= ed it again, and both Chromium and Firefox do treat my machine's networ= k name the same as "localhost". Windows and IE do it the way I= 9;ve documented in the draft, but it seems they're the only ones. (If o= nly I'd had mnot's test suite ...)

I'll change all the appropriate parts to say the right thing.

I've not done a detailed read through of the appendices - much of the m= aterial there is outside my experience.


Appendices A and B are the ge= nerally useful ones.


...

Section 2:

[[
=C2=A0 =C2=A0Some file systems allow directory objects to be treated as fil= es in
=C2=A0 =C2=A0some cases.=C2=A0 This can be reflected in a file URI by omitt= ing the
=C2=A0 =C2=A0trailing slash "/" from the path.=C2=A0 Be aware tha= t merging a relative
=C2=A0 =C2=A0URI reference to such a base URI as per Section 5.2 of [RFC398= 6]
=C2=A0 =C2=A0could remove the directory name from the resulting target URI.=
]]

I think the second sentence is wandering into local implementation details.= =C2=A0 I'd suggest focusing more on the idea that the trailing slash sh= ould be included in URIs that refer to directories.


I preferred stating the use-c= ase and the potential problems it causes, rather than making a judgement ca= ll. I'm not 100% invested in it, though, and can cut it back if it'= s too far the wrong way.


...


Section 3:

[[
=C2=A0 =C2=A0A file URI can be dependably dereferenced or translated to a l= ocal
=C2=A0 =C2=A0file path only if it is local.=C2=A0 A file URI is considered = "local" if
=C2=A0 =C2=A0it has no "file-auth", or the "file-auth" = is the special string
=C2=A0 =C2=A0"localhost".
]]

There's also the case when the hostname resolves to the local host.


Yep, I will include that when= I make the change.

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">=E2=80=8BCheers
--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/
--047d7b10ce153d950b0530f6d732-- From nobody Wed Apr 20 23:35:43 2016 Return-Path: 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 96CBF12E274 for ; Wed, 20 Apr 2016 23:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 ASct-nW6re5b for ; Wed, 20 Apr 2016 23:35:40 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id A09E112E13C for ; Wed, 20 Apr 2016 23:35:38 -0700 (PDT) Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-3) with ESMTPS id u3L6ZRCO009468 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Apr 2016 08:35:27 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id u3L6ZQ2j009456; Thu, 21 Apr 2016 08:35:26 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 21 Apr 2016 08:35:26 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Matthew Kerwin In-Reply-To: Message-ID: References: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> <57180E49.1090909@ninebynine.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: Julian Reschke , Mark Nottingham , Graham Klyne , Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:35:41 -0000 On Thu, 21 Apr 2016, Matthew Kerwin wrote: > You know what, I think you're right, and I've been suffering from > confirmation bias. I just tested it again, and both Chromium and Firefox do > treat my machine's network name the same as "localhost". They treat _any_ name as localhost as far as my tests show (on Linux). And so does curl. Figuring out your own name and making sure the name in the file:// URI is one of those is really tricky (and slow) business. -- / daniel.haxx.se From nobody Wed Apr 20 23:47:56 2016 Return-Path: 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 D981412E327 for ; Wed, 20 Apr 2016 23:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JJFpoBheKZqa for ; Wed, 20 Apr 2016 23:47:53 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F0712D58A for ; Wed, 20 Apr 2016 23:47:53 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id f1so149199646igr.1 for ; Wed, 20 Apr 2016 23:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=npU3p0KCBRmwxP66NdwLU8TxDk9sEZfax38UckbINFg=; b=JkUZVoZHj/DdctbU0nzxesQ6dAX2JPYIBlVOv2dyB/xlZj1iLLPDOWe69ocvkFK10b rMJhi4DSBQPxzS+A7OZDG3l9L3e4AWuvFo65vNSWU6CspF4VAJW9B3AMlZYz9iNE90ru uarIin+7hsDWHFgDLQ2TUIF31Tc0Ux84oeQTjvYmXcJt9vhLtpBMoPAg68GYcoXqazPR Jmz5ueBwsl2NL8/DOFGeIxB/aQDujLVPPKtINjVRhNdwgGhHGh9PYpWDspDZzxmcjnA2 5HLqjLVMzpaOAhUv5Wzb2eSJSaso78CKEyeMXHgklZkeWeEyMfQ14WWeDDC6YTJVBm4+ nUcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=npU3p0KCBRmwxP66NdwLU8TxDk9sEZfax38UckbINFg=; b=G9wZ1j7wbshoZTpkOyx/7Z7aotfpxvmxa9uVCz3sUQzq/VVfT09flYCfzS9WarFHPN uj1wAB5diGoQolX8X8gAJRe6UtQ/sBIbZO0GEfNGQOy+dn7WH9Y7pYKzME+xUAWzfiff jABoJM3WsRM8uyww/0iv60m64QDhOstC2cEJISRuEOqwGwa/S3RU18yZb7U+7tRP5XaW 6YK7Yj9I1Q6L+r/zbSNaUAhhsMogVb5wX+bN9iM1l/x1gMDdeW2oXtMWnj2774821AWX NrwdhaN6uZuHRIIKckS7WLWkauNoZrnDoRIr/Eq/l7MpmT5JZ6ncjBQn6+2L08II3A10 Dztg== X-Gm-Message-State: AOPr4FWnm8JiYUQJbDZSGuqJFHHdnlSEdWIVDPbH3JTkHFUYU+FOMB6R9eavDI65JoijQnhP1vVLQYzjHs5GYg== MIME-Version: 1.0 X-Received: by 10.50.120.198 with SMTP id le6mr1540115igb.25.1461221272958; Wed, 20 Apr 2016 23:47:52 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.4.2 with HTTP; Wed, 20 Apr 2016 23:47:52 -0700 (PDT) Received: by 10.107.4.2 with HTTP; Wed, 20 Apr 2016 23:47:52 -0700 (PDT) In-Reply-To: References: <20160420052342.31621.37367.idtracker@ietfa.amsl.com> <57180E49.1090909@ninebynine.org> Date: Thu, 21 Apr 2016 16:47:52 +1000 X-Google-Sender-Auth: JFG7bJkGRCuko6ftULGIDG1Qch4 Message-ID: From: Matthew Kerwin To: Daniel Stenberg Content-Type: multipart/alternative; boundary=001a11c1b8c0e9c7b70530f916c5 Archived-At: Cc: Graham Klyne , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-07.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 06:47:55 -0000 --001a11c1b8c0e9c7b70530f916c5 Content-Type: text/plain; charset=UTF-8 On 21/04/2016 4:36 PM, "Daniel Stenberg" wrote: > > On Thu, 21 Apr 2016, Matthew Kerwin wrote: > >> You know what, I think you're right, and I've been suffering from >> confirmation bias. I just tested it again, and both Chromium and Firefox do >> treat my machine's network name the same as "localhost". > > > They treat _any_ name as localhost as far as my tests show (on Linux). And so does curl. > > Figuring out your own name and making sure the name in the file:// URI is one of those is really tricky (and slow) business. > Urgh. Last time I checked (some number of months ago) Chrome used the hostname to access a samba share. I think that was in Windows. Perhaps it's best to just keep the semantics of RFC 1738, as Graham's been saying all along. --001a11c1b8c0e9c7b70530f916c5 Content-Type: text/html; charset=UTF-8


On 21/04/2016 4:36 PM, "Daniel Stenberg" <daniel@haxx.se> wrote:
>
> On Thu, 21 Apr 2016, Matthew Kerwin wrote:
>
>> You know what, I think you're right, and I've been suffering from
>> confirmation bias. I just tested it again, and both Chromium and Firefox do
>> treat my machine's network name the same as "localhost".
>
>
> They treat _any_ name as localhost as far as my tests show (on Linux). And so does curl.
>
> Figuring out your own name and making sure the name in the file:// URI is one of those is really tricky (and slow) business.
>

Urgh. Last time I checked (some number of months ago) Chrome used the hostname to access a samba share. I think that was in Windows.

Perhaps it's best to just keep the semantics of RFC 1738, as Graham's been saying all along.

--001a11c1b8c0e9c7b70530f916c5-- From nobody Fri Apr 22 00:22:04 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C8112DD11; Fri, 22 Apr 2016 00:22:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422072202.7666.57137.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 00:22:02 -0700 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 07:22:02 -0000 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 of the IETF. Title : The file URI Scheme Author : Matthew Kerwin Filename : draft-ietf-appsawg-file-scheme-08.txt Pages : 19 Date : 2016-04-22 Abstract: This document specifies the "file" Uniform Resource Identifier (URI) scheme, obsoleting the definition in RFC 1738. It defines a common syntax which is intended to interoperate across the broad spectrum of existing usages. At the same time it notes some other current practices around the use of file URIs. Note to Readers (To be removed by the RFC Editor) This draft should be discussed on the IETF Applications Area Working Group discussion list . 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-08 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 22 00:42:32 2016 Return-Path: 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 57BCA12E46D for ; Fri, 22 Apr 2016 00:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vR-jjmH-YTwn for ; Fri, 22 Apr 2016 00:42:28 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121F912DE70 for ; Fri, 22 Apr 2016 00:35:07 -0700 (PDT) Received: by mail-ig0-x22d.google.com with SMTP id a10so2300390igx.1 for ; Fri, 22 Apr 2016 00:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ld4l/IvleuI+5uawvNw4vn+bYIDND7mVnjlgS2uWIu4=; b=l6aJySl3K+ybMmonsxHgq1FXLEQCa9t4x5gJ2VejWrqt/6EZsOK32KykZkJgRq23GM zwxPPp459zttKTy8mvPRd8cvmZ8b0/Hd0qIQr+VCpGKKs7uCXLVveWWHRyKHkqKwVIW5 oxY6muVdptCeDKkLx6Q/VahPALOVkYx9YJXRrLf2dkyNQ2QBsi/fwapJZi+IodOE3J+y jKSJPnMP8xf3Ho4rHNvk8HSm+9TUcuswpkuM3swTt7Lt03hTKQXKzq7sHVkz39txnFzJ GwkMG3LrAnA0bLnlXpcPR4bwP2pSEGYX5qinuzZGcJgSYdh0iLQbN8IvW3TM0mI606FK oRDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ld4l/IvleuI+5uawvNw4vn+bYIDND7mVnjlgS2uWIu4=; b=kDglR531lWeVYWZjgX8nx77sE7OY76kAVY55+lSGYNasx0vUDD3gp9yIQBhE4CvBH6 QfKJt3waoFBtQ4atdIlhYGWZyX42t0ZWvjlBMR6axTl/wKFpGbdo6kGe5azKnFkCDtSt eiW5MiHtKp/7w5mVjwb9da1APZ1Kssf10ndVX1RKU5mhdMBQg7/q27rl+rbbghOZVQVO cWmOPhyMGkW1qu60rDBS5mf3XhjmBK76SXUhv+wHgsQkDLt2wu6Uq2n1sByuaYqG0Wct 3jXu3rW2gcxEQDuKMmldTJ/3Tau/wsBht/WgLZYYA94EhCK+VozlTMp/CG9xfYaefkfO MpXQ== X-Gm-Message-State: AOPr4FV4aHlN1Cc9os5LX31jJysxChlCDCYBbNPYBBNrD7cKwY4TOi13yNqLcHWSLEOMZ+r7BgKMrUPWeKCJ2Q== MIME-Version: 1.0 X-Received: by 10.50.41.35 with SMTP id c3mr2544516igl.50.1461310506257; Fri, 22 Apr 2016 00:35:06 -0700 (PDT) Sender: phluid61@gmail.com Received: by 10.107.4.2 with HTTP; Fri, 22 Apr 2016 00:35:06 -0700 (PDT) In-Reply-To: <20160422072202.7666.57137.idtracker@ietfa.amsl.com> References: <20160422072202.7666.57137.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 17:35:06 +1000 X-Google-Sender-Auth: 3bZrCzgQRemYgM5rIkkLzyrbEF8 Message-ID: From: Matthew Kerwin To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e011842e4a1d47705310ddd89 Archived-At: Cc: Graham Klyne Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 07:42:30 -0000 --089e011842e4a1d47705310ddd89 Content-Type: text/plain; charset=UTF-8 Here's another revision, this time with a much smaller diff. It changes around the meaning of the 'host' as per Graham's advice to mean what it did in RFC 1738 and 1630. I've kept the 'host' syntax rule even though it's explicitly a FQDN (better served by the 'reg-name' rule), because it's always been 'host'. Hopefully that's not controversial. The other TODOs still remain, and I'll try to work on them over the weekend or early next week. Cheers On 22 April 2016 at 17:22, 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 of the IETF. > > Title : The file URI Scheme > Author : Matthew Kerwin > Filename : draft-ietf-appsawg-file-scheme-08.txt > Pages : 19 > Date : 2016-04-22 > > Abstract: > This document specifies the "file" Uniform Resource Identifier (URI) > scheme, obsoleting the definition in RFC 1738. > > It defines a common syntax which is intended to interoperate across > the broad spectrum of existing usages. At the same time it notes > some other current practices around the use of file URIs. > > Note to Readers (To be removed by the RFC Editor) > > This draft should be discussed on the IETF Applications Area Working > Group discussion list . > > > 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-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-08 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Matthew Kerwin http://matthew.kerwin.net.au/ --089e011842e4a1d47705310ddd89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's another revision, this time with a much sma= ller diff. It changes around the meaning of the 'host' as per Graha= m's advice to mean what it did in RFC 1738 and 1630.

I'= ;ve kept the 'host' syntax rule even though it's explicitly a F= QDN (better served by the 'reg-name' rule), because it's always= been 'host'. Hopefully that's not controversial.

=
The other TODOs still remain, and I'll try to work on them ov= er the weekend or early next week.

Cheers

On 22 April 2016 at 17:22, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the ART Area General Applications Working Grou= p of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= The file URI Scheme
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Matt= hew Kerwin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-appsawg-file-scheme-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-04-22

Abstract:
=C2=A0 =C2=A0This document specifies the "file" Uniform Resource = Identifier (URI)
=C2=A0 =C2=A0scheme, obsoleting the definition in RFC 1738.

=C2=A0 =C2=A0It defines a common syntax which is intended to interoperate a= cross
=C2=A0 =C2=A0the broad spectrum of existing usages.=C2=A0 At the same time = it notes
=C2=A0 =C2=A0some other current practices around the use of file URIs.

Note to Readers (To be removed by the RFC Editor)

=C2=A0 =C2=A0This draft should be discussed on the IETF Applications Area W= orking
=C2=A0 =C2=A0Group discussion list <apps-discuss@ietf.org>.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-= appsawg-file-scheme-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-appsawg-file-scheme-08


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at 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
https://www.ietf.org/mailman/listinfo/apps-discuss=



--
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi= n.net.au/
--089e011842e4a1d47705310ddd89-- From nobody Fri Apr 22 01:47:38 2016 Return-Path: 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 EFF9D12D8A1 for ; Fri, 22 Apr 2016 01:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 2IP3jva_mNOW for ; Fri, 22 Apr 2016 01:47:35 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6204112EA70 for ; Fri, 22 Apr 2016 01:47:30 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1atWkG-0007tO-i2; Fri, 22 Apr 2016 09:47:24 +0100 Received: from oerc-dynamic-195.oerc.ox.ac.uk ([129.67.194.195]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1atWkG-0000Q2-ES; Fri, 22 Apr 2016 09:47:24 +0100 Message-ID: <5719E51E.1030809@ninebynine.org> Date: Fri, 22 Apr 2016 09:47:26 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Matthew Kerwin , IETF Apps Discuss References: <20160422072202.7666.57137.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 08:47:37 -0000 Checking: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-08 The new text in section 3 looks good to me. #g -- On 22/04/2016 08:35, Matthew Kerwin wrote: > Here's another revision, this time with a much smaller diff. It changes > around the meaning of the 'host' as per Graham's advice to mean what it did > in RFC 1738 and 1630. > > I've kept the 'host' syntax rule even though it's explicitly a FQDN (better > served by the 'reg-name' rule), because it's always been 'host'. Hopefully > that's not controversial. > > The other TODOs still remain, and I'll try to work on them over the weekend > or early next week. > > Cheers > > On 22 April 2016 at 17:22, 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 of the IETF. >> >> Title : The file URI Scheme >> Author : Matthew Kerwin >> Filename : draft-ietf-appsawg-file-scheme-08.txt >> Pages : 19 >> Date : 2016-04-22 >> >> Abstract: >> This document specifies the "file" Uniform Resource Identifier (URI) >> scheme, obsoleting the definition in RFC 1738. >> >> It defines a common syntax which is intended to interoperate across >> the broad spectrum of existing usages. At the same time it notes >> some other current practices around the use of file URIs. >> >> Note to Readers (To be removed by the RFC Editor) >> >> This draft should be discussed on the IETF Applications Area Working >> Group discussion list . >> >> >> 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-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-08 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > From nobody Tue Apr 26 10:25:31 2016 Return-Path: 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 6D4FB12B02A for ; Tue, 26 Apr 2016 10:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 mIQrtpxf6dEh for ; Tue, 26 Apr 2016 10:25:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BC612D549 for ; Tue, 26 Apr 2016 10:25:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9A73D180005; Tue, 26 Apr 2016 10:25:18 -0700 (PDT) To: masinter@adobe.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160426172518.9A73D180005@rfc-editor.org> Date: Tue, 26 Apr 2016 10:25:18 -0700 (PDT) Archived-At: Cc: egon.eckert@heaven-industries.com, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Technical Errata Reported] RFC7578 (4676) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:25:30 -0000 The following errata report has been submitted for RFC7578, "Returning Values from Forms: multipart/form-data". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7578&eid=4676 -------------------------------------- Type: Technical Reported by: Egon Eckert Section: 4.6. Original Text ------------- --AaB03x content-disposition: form-data; name="_charset_" iso-8859-1 --AaB03x-- content-disposition: form-data; name="field1" ...text encoded in iso-8859-1 ... AaB03x-- Corrected Text -------------- --AaB03x content-disposition: form-data; name="_charset_" iso-8859-1 --AaB03x content-disposition: form-data; name="field1" ...text encoded in iso-8859-1 ... --AaB03x-- Notes ----- Boundary hyphens were misplaced, I think. The second boundary delimiter should not have them on the end of the line, and the last boundary delimiter should have them on the beginning of the line too. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7578 (draft-ietf-appsawg-multipart-form-data-11) -------------------------------------- Title : Returning Values from Forms: multipart/form-data Publication Date : July 2015 Author(s) : L. Masinter Category : PROPOSED STANDARD Source : ART Area General Application Working Group Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Tue Apr 26 10:34:30 2016 Return-Path: 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 8149C12D542; Tue, 26 Apr 2016 10:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ro58wsC6tIrm; Tue, 26 Apr 2016 10:34:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7515012D52E; Tue, 26 Apr 2016 10:34:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 869F0180005; Tue, 26 Apr 2016 10:34:18 -0700 (PDT) To: egon.eckert@heaven-industries.com, masinter@adobe.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160426173418.869F0180005@rfc-editor.org> Date: Tue, 26 Apr 2016 10:34:18 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, apps-discuss@ietf.org, aamelnikov@fastmail.fm Subject: [apps-discuss] [Errata Verified] RFC7578 (4676) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:34:29 -0000 The following errata report has been verified for RFC7578, "Returning Values from Forms: multipart/form-data". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7578&eid=4676 -------------------------------------- Status: Verified Type: Technical Reported by: Egon Eckert Date Reported: 2016-04-26 Verified by: Alexey Melnikov (IESG) Section: 4.6. Original Text ------------- --AaB03x content-disposition: form-data; name="_charset_" iso-8859-1 --AaB03x-- content-disposition: form-data; name="field1" ...text encoded in iso-8859-1 ... AaB03x-- Corrected Text -------------- --AaB03x content-disposition: form-data; name="_charset_" iso-8859-1 --AaB03x content-disposition: form-data; name="field1" ...text encoded in iso-8859-1 ... --AaB03x-- Notes ----- Boundary hyphens were misplaced, I think. The second boundary delimiter should not have them on the end of the line, and the last boundary delimiter should have them on the beginning of the line too. -------------------------------------- RFC7578 (draft-ietf-appsawg-multipart-form-data-11) -------------------------------------- Title : Returning Values from Forms: multipart/form-data Publication Date : July 2015 Author(s) : L. Masinter Category : PROPOSED STANDARD Source : ART Area General Application Working Group Area : Applications and Real-Time Stream : IETF Verifying Party : IESG