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 2C3AE128E19; Sun, 14 Aug 2016 03:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 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.001, 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 UPbVfeDetxRm; Sun, 14 Aug 2016 03:17:01 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 2E8C512D6AA; Sun, 14 Aug 2016 03:17:01 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id c13so8365433ith.1; Sun, 14 Aug 2016 03:17: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:from:date:message-id :subject:to:cc; bh=nCka1fAfk9dHuGVt1xf73KXvxFe76MiOK9RGp3r07jM=; b=xTG10K+FKMZJNnB3+yOar01w1DxicNsK2UteDHU0jmDRfxa0wtqbZ9ow7LB9d1h3I3 aaZ7KwpnWTdpnElI4tKJXZ9o68NFpBdx/y+Es5KghZkoBDv2nSIvJ7ZMa3cKFhlXty7V 4Z1cVf6wcNUbjk+AeyP4262iQlZpIa7nT7EHagjhXa0gF5FTv24mLtF6PNCN7HcQnTBd /6m/ee8EsgS0i8JekncV/MWQK6UabhAa9lBzihLCxkXKmdgv1f/oPfmrtWluUicPBntr kP5qiGhTgjuGhMrjlIt0EBXDF1ZDJ4n3PKo7WyUdJ8OX5j1Vxc0q3Fz0UHc+O6NM7gQj I/VQ== 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:from :date:message-id:subject:to:cc; bh=nCka1fAfk9dHuGVt1xf73KXvxFe76MiOK9RGp3r07jM=; b=ckeQbIu+g/mlRUbJaabWUxKXrNr3Px8GT08677SNFpUBEVmq+CpcQASMn57+vhowcB 0+mNeQ9HTFwjfupCaaZb/E06xMwJsehwICwUOln8De4sWOgW8kYHtQNvDUPhF9RJPYu8 efS+jeJRxr/Qh8x1ELecMnxDkJvwEubUyMecU6Unr8U5YDFkj5Zw/fosoF9lDQMBh13p WkOEySnviynDwUuHYxzET/CoLe+L4/Mpm7cxN5aJQHnN2iwzzIfK+cIFy/m9qyh+uVD7 wb80sd8KH726n4Gt1uds6xB+XnDCteOqpxTzaefLHsYLtnK54O7YoDxC85OVbS5P9hf1 x+yg== X-Gm-Message-State: AEkooutLyCI5eMwtkcXylP+V9NVJOv9QkDryxqiMMCwGhEkJOBqgxRIGGDLFT0n1y7iu+ebo49KqRiS19tZQgA== X-Received: by 10.36.94.16 with SMTP id h16mr8067258itb.45.1471169820372; Sun, 14 Aug 2016 03:17:00 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.158.207 with HTTP; Sun, 14 Aug 2016 03:16:59 -0700 (PDT) In-Reply-To: <80ffb57e-8af1-e3a0-c35c-80666a5143e7@dcrocker.net> References: <80ffb57e-8af1-e3a0-c35c-80666a5143e7@dcrocker.net> From: Matthew Kerwin Date: Sun, 14 Aug 2016 20:16:59 +1000 X-Google-Sender-Auth: uJQrOAwUiilNaoEGTSlObbnbSkM Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11424ada8c352f053a056a45 Archived-At: Cc: Mark Nottingham , art-ads@ietf.org, IETF Apps Discuss , draft-ietf-appsawg-file-scheme@ietf.org Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-file-scheme-11 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: Sun, 14 Aug 2016 10:17:05 -0000 --001a11424ada8c352f053a056a45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 14 August 2016 at 10:05, Dave Crocker wrote: > > Review: The file URI Scheme > ID: draft-ietf-appsawg-file-scheme-11 > Review Date: 13 Aug 2016 > Reviewer: D. Crocker > > > Summary > ------- > > This is a followup to my Document Shepherd review of the -05 version on 1= 2 > April 2016. > > The document changes are effective. I found only a few places to make a > few suggestions, mostly minor.[*] > > There is one significant concern, in Section 3, which continues from the > previous review and I've suggested replacement text and this is the > presence of normative language. > > After resolution of this one concern, the document will be ready for > publication. > > Nice job! > > d/ > > > > > 1.1. 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 file" is used to describe >> files that can be accessed through the local file system API using >> only the information included in the file path, not relying on other >> information such as network addresses. 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. >> >> The term "local file URI" is used to describe file URIs which have no >> authority component, or where the authority is the special string >> > > probably should be: "authority" component, given the surrounding > conventions used in this paragraph. > > =E2=80=8BNo worries, will change that.=E2=80=8B > > "localhost" or a fully qualified domain name that resolves to the >> machine from which the URI is being interpreted (Section 2). >> >> 2. Syntax >> > ... > >> 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 >> > > Hmmm. I wondered how file-auth and path-absolute were separated, but see > from Section 3.3 of RFC 3986 that path-absolute beings with a "/". > > I think this means that if there is no file-auth, the beginning will be > "file:///" etc. Is that intended? > > =E2=80=8BYes; RFC1738 file URIs look like "file:///foo/bar" (meaning file "= bar" in directory "/foo"). > >> local-path =3D path-absolute >> >> file-auth =3D "localhost" >> / host >> >> The "host" is the fully qualified domain name of the system on which >> the file is accessible. This allows a client on another system to >> know that it cannot access the file system, or perhaps to use some >> > > perhaps to use -> or perhaps that they need to use > > =E2=80=8BACK=E2=80=8B > > other local mecahnism to access the file. >> > ... > =E2=80=8BHeh, "mecahnism" is a typo too.=E2=80=8B > >> Some file systems have case-sensitive file naming and some do not. >> As such the file URI 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 >> > > soley -> solely > > =E2=80=8BACK=E2=80=8B > > implementation processing the file URI on behalf of the referenced >> file system. >> >> 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 >> > > oh? I would have thought it would have required retaining a trailing "/" > if the URI is for a folder, and dropping it if it refers to a file... > > =E2=80=8BUnless you're intentionally treating the directory as a file. In t= he UNIX path "/foo/bar", 'bar' might be a directory, even without a trailing "/"; and if you used that path to create a file URI like "file:///foo/bar" you need to be careful with relative references. I think I will just delete the paragraph; it doesn't add much (except for confusion.) It's certainly not worth a couple of round-trips to refine.=E2= =80=8B > > URI reference to such a base URI as per Section 5.2 of [RFC3986] >> could remove the directory name from the resulting target URI. >> > ... > > 3. Operations Involving file URIs >> > > I am going to again raise a concern about this. The document isn't > providing enough detail about the processing of URIs to be meaningful, > nevermind normative. (I can even argue that the normative directive here > is wrong in various write-only cases. One might respond that that's why > it's a SHOULD rather than MUST, but my view of SHOULDs is that violating > them needs to be exceptional, and activities like write-only sensor > networks don't strike me as that special. > > In other words, I encourage remove all normative language here. I believ= e > the easiest and most reasonable action is to remove the first two > sentences, below, and start with "See the". > > =E2=80=8BThat works for me.=E2=80=8B > > ... > > 4. File System Name Encoding >> >> File systems use various encoding schemes to store file and directory >> names. Many modern file systems store file and directory names as >> arbitrary sequences of octets, in which case the representation as an >> encoded string often depends on the user's localization settings, or >> defaults to UTF-8 [STD63]. >> >> When a file URI is produced, characters not allowed by the syntax in >> Section 2 SHOULD be percent-encoded as characters using UTF-8 >> encoding, as per [RFC3986], Section 2.5. >> >> However, encoding information for file and/or directory names might >> not be available. In these cases, implementations MAY use heuristics >> to determine the encoding. If that fails, they SHOULD percent-encode >> the raw bytes of the label directly. >> > > An IETF protocol that has normative language allowing heuristics is askin= g > for all sorts of problems. And here I believe it isn't necessary, though= I > think I understand the difficulty you are trying to deal with. > > Consider this as a replacement for the above paragraph: > > A decision not to use percent-encoding is outside the scope of this > specification. It will typically require use of heuristics or explicit > knowledge about the way the string will be processed. > > =E2=80=8BI'm happy with that, but I'll say "...not to use percent-encoded UTF-8...".=E2=80=8B > > > d/ > > [*] I'll mention that I've just come off of reviewing 3 other documents > that I found highly problematic and was probably in an unusually > cantankerous mood when reviewing the file scheme revision here. So I > actually put some effort into looking for clarity and correctness problem= s, > especially in the core part of the document, Section 2. It was really > quite pleasant to /fail/ in that effort. Thanks! > > =E2=80=8BI appreciate the effort, and the outcome. Thank you too. I'll sub= mit this version (-12) right now.=E2=80=8B > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > =E2=80=8BCheers=E2=80=8B --=20 Matthew Kerwin http://matthew.kerwin.net.au/ --001a11424ada8c352f053a056a45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 August 2016 at 10:05, Dave Crocker <dhc2@dcrocker= .net> wrote:

Review:=C2=A0 =C2=A0The file URI Scheme
ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-appsawg-file-scheme-11
Review Date:=C2=A0 13 Aug 2016
Reviewer:=C2=A0 =C2=A0 =C2=A0D. Crocker <dcrocker@bbiw.net>


Summary
-------

This is a followup to my Document Shepherd review of the -05 version on 12 = April 2016.

The document changes are effective.=C2=A0 I found only a few places to make= a few suggestions, mostly minor.[*]

There is one significant concern, in Section 3, which continues from the pr= evious review and I've suggested replacement text and this is the prese= nce of normative language.

After resolution of this one concern, the document will be ready for public= ation.

Nice job!

d/




1.1.=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 file" is us= ed to describe
=C2=A0 =C2=A0files that can be accessed through the local file system API u= sing
=C2=A0 =C2=A0only the information included in the file path, not relying on= other
=C2=A0 =C2=A0information such as network addresses.=C2=A0 It is important t= o note that
=C2=A0 =C2=A0a local file may not be physically located on the local machin= e, for
=C2=A0 =C2=A0example if a networked file system is transparently mounted in= to the
=C2=A0 =C2=A0local file system.

=C2=A0 =C2=A0The term "local file URI" is used to describe file U= RIs which have no
=C2=A0 =C2=A0authority component, or where the authority is the special str= ing

probably should be: "authority" component, given the surrounding = conventions used in this paragraph.


=E2=80=8BNo worries, will cha= nge that.=E2=80=8B

=C2=A0

=C2=A0 =C2=A0"localhost" or a fully qualified domain name that re= solves to the
=C2=A0 =C2=A0machine from which the URI is being interpreted (Section 2).
2.=C2=A0 Syntax
...
=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

Hmmm.=C2=A0 I wondered how file-auth and path-absolute were separated, but = see from Section 3.3 of RFC 3986 that path-absolute beings with a "/&q= uot;.

I think this means that if there is no file-auth, the beginning will be &qu= ot;file:///" etc.=C2=A0 Is that intended?


=E2=80=8BYes;= RFC1738 file URIs look like "file:///foo/bar" (mean= ing file "bar" in directory "/foo").

=C2=A0

=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 "localhost"= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0/ host

=C2=A0 =C2=A0The "host" is the fully qualified domain name of the= system on which
=C2=A0 =C2=A0the file is accessible.=C2=A0 This allows a client on another = system to
=C2=A0 =C2=A0know that it cannot access the file system, or perhaps to use = some

=C2=A0 perhaps to use -> or perhaps that they need to use


=E2=80=8BACK=E2=80=8B
=C2=A0

=C2=A0 =C2=A0other local mecahnism to access the file.
...

=E2=80=8BHeh, "mecah= nism" is a typo too.=E2=80=8B

=C2=A0

=C2=A0 =C2=A0Some file systems have case-sensitive file naming and some do = not.
=C2=A0 =C2=A0As such the file URI scheme supports case sensitivity, in orde= r to
=C2=A0 =C2=A0retain the case as given.=C2=A0 Any transport-related handling= of the file
=C2=A0 =C2=A0URI scheme MUST retain the case as given.=C2=A0 Any mapping to= or from a
=C2=A0 =C2=A0case-insensitive form is soley the responsibility of the

=C2=A0soley -> solely


=E2=80=8BACK=E2=80=8B
=C2=A0

=C2=A0 =C2=A0implementation processing the file URI on behalf of the refere= nced
=C2=A0 =C2=A0file system.

=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

oh?=C2=A0 I would have thought it would have required retaining a trailing = "/" if the URI is for a folder, and dropping it if it refers to a= file...


=E2=80=8BUnle= ss you're intentionally treating the directory as a file. In the UNIX p= ath "/foo/bar", 'bar' might be a= directory, even without a trailing "/"; and if you used that pat= h to create a file URI like "file:///foo/bar" you ne= ed to be careful with relative references.

<= div class=3D"gmail_default" style=3D"font-family:georgia,serif;color:rgb(7,= 55,99)">I think I will just delete the paragraph; it doesn't add much (= except for confusion.) It's certainly not worth a couple of round-trips= to refine.=E2=80=8B

=C2=A0

=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.=
...

3.=C2=A0 Operations Involving file URIs

I am going to again raise a concern about this.=C2=A0 The document isn'= t providing enough detail about the processing of URIs to be meaningful, ne= vermind normative.=C2=A0 (I can even argue that the normative directive her= e is wrong in various write-only cases.=C2=A0 One might respond that that&#= 39;s why it's a SHOULD rather than MUST, but my view of SHOULDs is that= violating them needs to be exceptional, and activities like write-only sen= sor networks don't strike me as that special.

In other words, I encourage remove all normative language here.=C2=A0 I bel= ieve the easiest and most reasonable action is to remove the first two sent= ences, below, and start with "See the".


=E2=80=8BThat works for me.= =E2=80=8B

=C2=A0

...

4.=C2=A0 File System Name Encoding

=C2=A0 =C2=A0File systems use various encoding schemes to store file and di= rectory
=C2=A0 =C2=A0names.=C2=A0 Many modern file systems store file and directory= names as
=C2=A0 =C2=A0arbitrary sequences of octets, in which case the representatio= n as an
=C2=A0 =C2=A0encoded string often depends on the user's localization se= ttings, or
=C2=A0 =C2=A0defaults to UTF-8 [STD63].

=C2=A0 =C2=A0When a file URI is produced, characters not allowed by the syn= tax in
=C2=A0 =C2=A0Section 2 SHOULD be percent-encoded as characters using UTF-8<= br> =C2=A0 =C2=A0encoding, as per [RFC3986], Section 2.5.

=C2=A0 =C2=A0However, encoding information for file and/or directory names = might
=C2=A0 =C2=A0not be available.=C2=A0 In these cases, implementations MAY us= e heuristics
=C2=A0 =C2=A0to determine the encoding.=C2=A0 If that fails, they SHOULD pe= rcent-encode
=C2=A0 =C2=A0the raw bytes of the label directly.

An IETF protocol that has normative language allowing heuristics is asking = for all sorts of problems.=C2=A0 And here I believe it isn't necessary,= though I think I understand the difficulty you are trying to deal with.
Consider this as a replacement for the above paragraph:

=C2=A0 =C2=A0 =C2=A0A decision not to use percent-encoding is outside the s= cope of this specification.=C2=A0 It will typically require use of heuristi= cs or explicit knowledge about the way the string will be processed.


=E2=80=8BI'm happy with t= hat, but I'll say "...not to use percent-encoded UTF-8...".= =E2=80=8B

=C2=A0


d/

[*] I'll mention that I've just come off of reviewing 3 other docum= ents that I found highly problematic and was probably in an unusually canta= nkerous mood when reviewing the file scheme revision here.=C2=A0 So I actua= lly put some effort into looking for clarity and correctness problems, espe= cially in the core part of the document, Section 2.=C2=A0 It was really qui= te pleasant to /fail/ in that effort.=C2=A0 Thanks!


=E2=80=8BI appr= eciate the effort, and the outcome. Thank you too.=C2=A0 I'll submit th= is version (-12) right now.=E2=80=8B

=C2=A0

=C2=A0 Dave Crocker
=C2=A0 Brandenburg InternetWorking
=C2=A0 bbi= w.net


=E2=80=8BCheers=E2=80=8B
--
=C2=A0 Matthew Kerwin
= =C2=A0 http://m= atthew.kerwin.net.au/
--001a11424ada8c352f053a056a45--