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

Stian Soiland-Reyes <> Tue, 23 January 2018 09:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 136C0124F57 for <>; Tue, 23 Jan 2018 01:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.93
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bBsrm33sVTgd for <>; Tue, 23 Jan 2018 01:58:49 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id D2FE91200B9 for <>; 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 (HELO ( by (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2018 09:58:45 +0000
Received: from localhost ( []) by (ASF Mail Server at 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 <>
To: Graham Klyne <>
In-Reply-To: <>
References: <20180117144647.GC5245@biggie> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Uri-review] Review Provisional registration for app URI scheme
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

On Sun, 21 Jan 2018 12:27:02 +0000, Graham Klyne <>; 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. 

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


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?) []
> 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 [] 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