Re: [Uri-review] Review Provisional registration for app URI scheme

Stian Soiland-Reyes <stain@apache.org> Tue, 23 January 2018 09:58 UTC

Return-Path: <stain@apache.org>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C0124F57 for <uri-review@ietfa.amsl.com>; Tue, 23 Jan 2018 01:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.93
X-Spam-Level:
X-Spam-Status: No, score=-14.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] 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 bBsrm33sVTgd for <uri-review@ietfa.amsl.com>; Tue, 23 Jan 2018 01:58:49 -0800 (PST)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id D2FE91200B9 for <uri-review@ietf.org>; Tue, 23 Jan 2018 01:58:45 -0800 (PST)
Received: (qmail 4363 invoked by uid 99); 23 Jan 2018 09:58:45 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2018 09:58:45 +0000
Received: from localhost (cspool35.cs.man.ac.uk [130.88.195.135]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id CD95C1A0068; Tue, 23 Jan 2018 09:58:43 +0000 (UTC)
Date: Tue, 23 Jan 2018 09:58:40 +0000
Message-ID: <20180123095840.GC31707@biggie>
From: Stian Soiland-Reyes <stain@apache.org>
To: Graham Klyne <gk@ninebynine.org>
Cc: uri-review@ietf.org
In-Reply-To: <5A648716.9030500@ninebynine.org>
References: <20180117144647.GC5245@biggie> <4d910f73-9ca4-c661-0ff1-f508b8ccbed2@gmx.de> <FCE36985-BDC4-419E-97AB-CC061B43A9C7@tzi.org> <CAMBJEmU2s8B8Rvz-GW=3n4Dt0c_qCQHzm1M52GpAXn+qQmHzvw@mail.gmail.com> <AFAEFB6C-CD3E-4BD1-B1B5-35E9749D45FC@tzi.org> <CAMBJEmWgTasuKMPhTXUBLgSuDKBXo+M1Eq98t-8=Ya+kKqgYXQ@mail.gmail.com> <BB6CCAEA-7604-4056-AFD4-A5FE87559973@tzi.org> <CAMBJEmUDEGz=vLQN-XGpkS7cF+TFAyc98RsYJSKDRkw5bJn7ww@mail.gmail.com> <5A648716.9030500@ninebynine.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/jW78kxMIix17wl_XFYN0bMvccNw>
Subject: Re: [Uri-review] Review Provisional registration for app URI scheme
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2018 09:58:52 -0000

Thanks for your thorough review! My apologies for the trouble as this
is my first Internet-Draft.

I integrated changes below into
https://tools.ietf.org/id/draft-soilandreyes-app-04.html

On Sun, 21 Jan 2018 12:27:02 +0000, Graham Klyne <gk@ninebynine.org> wrote:
> [[
> The semantics of the query component is undefined by this Internet-Draft. 
> Implementations SHOULD NOT generate a query component for app URIs.
> 
> I could imagine using this scheme in conjunction with an web application I'm 
> working on pretty much for the reasons indicated in the intro.  But my 
> application does use query URIs, so, while I'm OK with the semantics being 
> undefined by this specification, the SHOULD NOT exhortation seems a bit strong 
> to me.

Yes, I was thinking from the point of identifiers, .../file.txt?query would mean
another URI seemingly not be identical to .../file.txt 

But I'll rather leave the meaning of query undefined as you propose -
that's more like an implicit MAY -- you can do it, but you better figure
out yourself what that means.

 
> nit: "undefined by this Internet-Draft" might be better expressed as "undefined 
> by this specification" (I-Ds are supposed to be transient, and if this idea 
> progresses I would suggest requesting an informational RFC publication - 
> possibly independent stream).

Done - I was not sure if I could call it "specification" at this
point. :)


> I'm a bit uneasy with this: it's not clear to me that there isn't some confusion 
> here between I'd call "extension specifications" and "implementations" of this 
> specification.  If "implementations", then I'm not convinced there's any 
> conflict with RFC7320.  If "extension specifications", then to what extent would 
> it be appropriate for these to be tied to a specific domain?   (Noting, en 
> passant, that control of domain names tends to be transient.)

I've added authority prefixes like "uuid,".  The prefix "name," means a 
DNS-like namespace that is unique within an installation, e.g. 
app.example.com 

> My suggestion would be to say nothing about this here, and leave it up to any 
> specification that does want to impose a structure or semantics for URI 
> authorities to justify why it does so in contravention of RFC7320 .

I think the uniqueness semantics here are important for anyone consuming
the app URIs as identifiers. So I've clarified this with a new
"authority semantics" session. The "authority syntax" now only
introduce the prefixes and production rules.

> ## Section 2.1
> 
> I'm not sure what useful purpose is served here by the discussion of choice of 
> authority scheme.

It's an attempt to build common ground. If everyone does their own game,
say app://2018-01-22/ there is bound to be someone mixing it up, and
then there was little purpose of this URI scheme over say the file:///
scheme with a fake host name.

I've added an authority semantics section.

 
> If, on the other hand, it is important to distinguish these authority forms for 
> some reason, then I think it might be better (i.e. less prone to implementation 
> error) by incorporating some clear syntactic marker into the format (that still 
> confirms to RFC3986 syntax of course).

I suggest later in the examples why the distinction might be important,
e.g.  recognizing an UUID from declared "External-Identifier" metadata,
or using the ni hash to resolve from a .well-known/ni/ endpoint.

But perhaps then there should be a clearer separation as you suggest,
using defined prefixes. Other prefixes would then be
undefined, but available for extensions.

app://uuid,1559aebe-c273-4be3-9333-3073c67bd9a1/ 
app://ni,sha-256;F-34D4TUeOfG0selz7REKRDo4XePkewPeQYtjL3vQs0/
app://name,example.com/  

I've added such, with generic "authority" as fallback as before to
permit any extensions.

This should make a clearer split between implementation-specific
authorities (which can use "name," with their domain name) and
extensions (which can make "somethingnew,")


> 
> ...
> It seems a little odd to me that a scheme that is intended for use where file: 
> URIs are inappropriate is so dependent on the language of file systems.  (e.g. 
> how obvious is the interpretation of this scheme is used for referencing an LDP 
> container?) [http://www.w3.org/TR/ldp/]
> 
> Suggest: drop this (and the following para).  (Why is it needed?)

Agreed  - I've removed large parts of path semantics, limiting it to
recommending / as separator.


> I note all your examples *are* "retrievable as a single bytestream".  May I 
> suggest including an LDP container [http://www.w3.org/TR/ldp/] as a possible 
> example?  (This isn't entirely hypothetical - a colleague of mine has done work 
> on an "object" scheme that uses LDP containers in ways that might constitute an 
> "archive".

That's a nice use case - added as an example.

> 
> Which appears to contradict the first quoted paragraph.
> 
> I suspect the spec could benefit from an introductory section that describes 
> what is meant by an "archive", then proceeds to use that term.

Added, including examples of non-file "archives".


> Return the archive file if the path component is missing/empty.

> I see you address this later.  In view of that, I feel that the use of normative 
> language ("SHOULD") is inappropriate - given the range of implementation 
> options, it's not clear that this is really an interoperability concern.

I think this is a good argument to remove the consideration for an empty
path at all.

> 5. An implementation describe an archive using the alg-val production, but a 
> 6. Two implementations might have different views of the content of the same 

I've removed both interoperability considerations and added a clause to
Path Semantics.

> nit: "facilitated"?  Suggest maybe "intended" or "deployed"

Changed to "used"


> I note that the use of an explicit reference to a different archive could be 
> legitimate ... this comment might be read as suggesting that any such reference 
> should be disallowed.  (I have a potential use-case for valid cross-archive 
> references.)

Added "if resolving cross-references is not desired"

> ## Section 7
> This specification requests that IANA register the following URI scheme 
> according to the provisions of [RFC7595]:

I used that exact wording.


Thanks, Graham!

-- 
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718