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

Stian Soiland-Reyes <> Mon, 22 January 2018 01:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B04A21270A7 for <>; Sun, 21 Jan 2018 17:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.931
X-Spam-Status: No, score=-14.931 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id co-NiXX_uMxL for <>; Sun, 21 Jan 2018 17:34:10 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 28FF2126C25 for <>; Sun, 21 Jan 2018 17:34:10 -0800 (PST)
Received: (qmail 45200 invoked by uid 99); 22 Jan 2018 01:34:09 -0000
Received: from (HELO ( by (qpsmtpd/0.29) with ESMTP; Mon, 22 Jan 2018 01:34:09 +0000
Received: from localhost ( []) by (ASF Mail Server at with ESMTPSA id D495C1A00A5; Mon, 22 Jan 2018 01:34:07 +0000 (UTC)
Date: Mon, 22 Jan 2018 01:34:03 +0000
Message-ID: <20180122013403.GC855@biggie>
From: Stian Soiland-Reyes <>
To: Graham Klyne <>
Cc: "Roy T. Fielding" <>,
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: Mon, 22 Jan 2018 01:34:13 -0000

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

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

> 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

Here is how app:// was used in Firefox OS (now B2G OS) in Open Web Apps:

Stian Soiland-Reyes
The University of Manchester