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
- [Uri-review] Review Provisional registration for … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Alexey Melnikov
- Re: [Uri-review] Review Provisional registration … Julian Reschke
- Re: [Uri-review] Review Provisional registration … Carsten Bormann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Carsten Bormann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Carsten Bormann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … S Moonesamy
- Re: [Uri-review] Review Provisional registration … Roy T. Fielding
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Frank Ellermann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes