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

Matthew Kerwin <matthew@kerwin.net.au> Sun, 14 August 2016 10:17 UTC

Return-Path: <phluid61@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 <matthew@kerwin.net.au>
Date: Sun, 14 Aug 2016 20:16:59 +1000
X-Google-Sender-Auth: uJQrOAwUiilNaoEGTSlObbnbSkM
Message-ID: <CACweHNCO82D40KEUoNSTFTeYisWVgcpEgNOnguiBzu5kZ2CXag@mail.gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary=001a11424ada8c352f053a056a45
Archived-At: <https://mailarchive.ietf.org/arch/msg/apps-discuss/sEdzPkJW9vFkGq79KH6km0DexMg>
Cc: Mark Nottingham <mnot@mnot.net>, art-ads@ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>, 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Aug 2016 10:17:05 -0000

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

>
> Review:   The file URI Scheme
> ID:       draft-ietf-appsawg-file-scheme-11
> Review Date:  13 Aug 2016
> Reviewer:     D. 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.  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.
>
>
​No worries, will change that.​



>
>    "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       = file-scheme ":" file-hier-part
>>       file-scheme    = "file"
>>
>>       file-hier-part = ( "//" auth-path )
>>                      / local-path
>>
>>       auth-path      = [ 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?
>
>
​Yes; RFC1738 file URIs look like "file:///foo/bar" (meaning file "bar" in
directory "/foo").



>
>>       local-path     = path-absolute
>>
>>       file-auth      = "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
>
>
​ACK​



>
>    other local mecahnism to access the file.
>>
> ...
>

​Heh, "mecahnism" is a typo too.​



>
>>    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
>
>
​ACK​



>
>    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...
>
>
​Unless you're intentionally treating the directory as a file. In the 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.​



>
>    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 believe
> the easiest and most reasonable action is to remove the first two
> sentences, below, and start with "See the".
>
>
​That works for me.​



>
> ...
>
> 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 asking
> 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.
>
>
​I'm happy with that, but I'll say "...not to use percent-encoded
UTF-8...".​



>
>
> 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 problems,
> especially in the core part of the document, Section 2.  It was really
> quite pleasant to /fail/ in that effort.  Thanks!
>
>
​I appreciate the effort, and the outcome. Thank you too.  I'll submit this
version (-12) right now.​



>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>
>
​Cheers​
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/