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

Graham Klyne <> Tue, 23 January 2018 11:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17F4D124205 for <>; Tue, 23 Jan 2018 03:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PCaLlbQ5oaky for <>; Tue, 23 Jan 2018 03:58:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 008C51205D3 for <>; Tue, 23 Jan 2018 03:58:41 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.89) (envelope-from <>) id 1edw3N-000822-Aw for; Tue, 23 Jan 2018 10:43:45 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1edw3F-0004CP-fo; Tue, 23 Jan 2018 10:43:38 +0000
Received: from ([]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1edw3F-000Al6-LO; Tue, 23 Jan 2018 10:43:37 +0000
Message-ID: <>
Date: Tue, 23 Jan 2018 10:43:37 +0000
From: Graham Klyne <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Stian Soiland-Reyes <>
CC: "Roy T. Fielding" <>,
References: <20180117144647.GC5245@biggie> <> <> <> <> <> <> <> <> <> <20180122013403.GC855@biggie>
In-Reply-To: <20180122013403.GC855@biggie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
X-Oxmail-Spam-Status: score=0.0 tests=none
X-Oxmail-Spam-Level: /
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 11:58:45 -0000

Hi Stian,

(Personal hat)

Notwithstanding the roots of this proposal, I think you've exposed that the 
scheme has uses for more than just packaged applications.  So, lacking a 
compelling practical reason, I'm still uneasy about 'app' as scheme name because 
of existing associations and expectations.

(From RFC7595: "Since scheme names share a single, global namespace, it is 
desirable to avoid contention over use of short, mnemonic scheme names." 
[, section 3.1].)

Having recently actually read the spec, I think something like 'arcid' or 
'pkgid' might be more appropriate than Roy's 'arcp', as the URI identifies 
rather than points to an archive or package - as I read it, that's part of the 
point: to provide a base label that transcends any particular location.

Anyway, I don't intend to argue the point ad nauseum if there's a consensus to 
go with any specific name.

On 22/01/2018 01:34, Stian Soiland-Reyes wrote:
 > In that case I don't know if it would then make sense to register "app"
 > as a historical scheme so the link to the previous W3C proposals are
 > recorded?  How much prior usage/publication is needed for historical
 > schemes?
 > Here is how app:// was used in Firefox OS (now B2G OS) in Open Web Apps:

The historical use could IMO constitute a "compelling practical reason", 
depending on the scope and nature of its deployment.  A registration of 'app' as 
historical, or a note about it's origins in the registration template for the 
revised scheme might be options to consider here.

I think local-use URI schemes (like app was?) create a kind of messy corner 
case: the local-use may be fine until (a) someone wants to use the same name for 
something else on the global network, or (b) the scheme leaks from its local 
use.  I sometimes think of these as "URI-like strings" rather than full-on URIs, 
but I'm sure others would have different perspectives.

There have been some similar discussions about the file:// URI scheme.  In it's 
original form, it was not really intended for use as a globally resolvable 
location.  In my own work, I've used it as a local base for resolving relative 
references, not transmitted to other systems.  The authority component there was 
intended as a flag to an application about whether it could consider the URL 
resolvable at all.  This aspect got somewhat lost in subsequent revisions - I 
wasn't aware of this aspect until relatively recently:

    The file URL scheme is used to designate files accessible on a
    particular host computer. This scheme, unlike most other URL schemes,
    does not designate a resource that is universally accessible over the

    A file URL takes the form:


    where <host> is the fully qualified domain name of the system on
    which the <path> is accessible...

--, sect 3.10



On 22/01/2018 01:34, Stian Soiland-Reyes wrote:
> On Sun, 21 Jan 2018 11:06:45 +0000, Graham Klyne <>; wrote:
>> On 19/01/2018 17:05, Roy T. Fielding wrote:
>>>> On Jan 19, 2018, at 7:30 AM, Stian Soiland-Reyes <>; wrote:
>>>> OK, so after a bit back and forth, newtitle is:
>>>> The Archive and Packaging Pointer (app) URI scheme
>>> I don't think it is reasonable to reserve the name "app" for that purpose.
>>> "arcp" would make more sense and not mislead 99% of the people who see it.
>> +1 (wearing personal hat)
> Thanks for your feedback!
> I think you both make good points on the scheme name.
> In my desire to generalize the former proposals
> and I
> accidentally removed most of the "application" aspect - throwing the baby out
> with the bathwater you could say.
> Microsoft has ms-appx: and ms-appx-web:// which work almost as I propose
> for app://
> ..with the extra bonus of the empty authority in ms-appx:/// meaning "the
> running app" similar to the implied "localhost" in file:/// -- good
> idea!
> Previous feedback here (well, it was uri@w3c then) on the app scheme:
> This got hung up with the mapping to HTTP, which is why I
> generalized how to resolve resources.
> Do you think "app" would be acceptable again if we brought back in focus
> the application aspect, and perhaps also covered non-file resources such
> as UI states?
> That should hint to remove/shrink the Resolution Protocol section, as
> paths could be for any application "resource", some of which might not
> be retrievable as a representation.
> (Then of course ?query would also be generally allowed)
> Title could be "Application and Package Pointer (app) URI Scheme".
> Hypothetical application state example - sorry, a bit too long:
> This shows how a photo gallery app send an app URIs to a messaging app,
> filling in an app URI Template to navigate to its Sharing widget, with a
> redirect back to its next gallery state as another app URI.  The
> imagined app framework ensures that only the two apps can talk to
> each-other and that only the selected photos are exposed.
> I must admit I am not an expert in current Android/iOS app practices,
> and above is hypothetical pipe dream and full of security traps - not
> the best start for an RFC!
> Do you think my Internet-Draft could be adopted to cover cases such as
> this at the same time as it covers more "naive" archive mappings?  I
> would probably have to strip down the Internet-Draft (and example) to
> make it abstract enough.
> BTW; current practices in iOS and Android world seems to be that each
> app invent their own URI scheme like in "myGallery://photos/137" and
> registers it for Actions/Intents.
> These are typically never registered with IANA, in fact
> says:
>> Note: If more than one third-party app registers to handle the same URL
>> scheme, there is currently no process for determining which app will be
>> given that scheme.
> This seems to me like abusing the scheme name when it's really acting
> like an Authority in a common application framework. Also I think we
> agree that we should not ask every app to register with IANA.
> Some good citizens use full reverse domain names as a private URI scheme
> according to
> e.g. "com.example.myGallery://photos/137" -- however leaking these
> between applications is still not really "private"..!
> ..but perhaps that fight is already lost for IANA and URI schemes are
> now free for all?
> :-(
>> As and when this comes to me for IANA review, I'd like to see in this discussion
>> list ( some stronger indication of consensus on the choice
>> of scheme name.  This doesn't formally affect requirements for provisional
>> registration (though I'd me minded to request addition of a reference to this
>> discussion), but it would have an effect on any subsequent request to progress
>> to a permanent registration.
> No, but I agree "overly general" names are not permitted by BCP35, even
> for provisional schemes. So if "app" is seen as that, and it becomes
> hard to reconcile my draft with non-archive examples, then I would go
> for "archive" or so and forget about the "application" aspect.
> In that case I don't know if it would then make sense to register "app"
> as a historical scheme so the link to the previous W3C proposals are
> recorded?  How much prior usage/publication is needed for historical
> schemes?
> Here is how app:// was used in Firefox OS (now B2G OS) in Open Web Apps: