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

Stian Soiland-Reyes <stain@apache.org> Mon, 22 January 2018 01:34 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 B04A21270A7 for <uri-review@ietfa.amsl.com>; Sun, 21 Jan 2018 17:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.931
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co-NiXX_uMxL for <uri-review@ietfa.amsl.com>; Sun, 21 Jan 2018 17:34:10 -0800 (PST)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 28FF2126C25 for <uri-review@ietf.org>; 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 mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Jan 2018 01:34:09 +0000
Received: from localhost (fb065306-1ecd-4974-a503-9c7871092168.net [84.92.48.26]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) 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 <stain@apache.org>
To: Graham Klyne <gk@ninebynine.org>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, uri-review@ietf.org
In-Reply-To: <5A647445.5050200@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> <65DA395C-3DD5-4E46-BB44-4660578F681E@gbiv.com> <5A647445.5050200@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/7h946xC2Zpg7GoZ6FdxgeZO3Vjg>
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: Mon, 22 Jan 2018 01:34:13 -0000

On Sun, 21 Jan 2018 11:06:45 +0000, Graham Klyne <gk@ninebynine.org>; wrote:
> On 19/01/2018 17:05, Roy T. Fielding wrote:
> >> On Jan 19, 2018, at 7:30 AM, Stian Soiland-Reyes <stain@apache.org>; wrote:
> >>
> >> OK, so after a bit back and forth, newtitle is:
> >>
> >> The Archive and Packaging Pointer (app) URI scheme
> >> https://tools.ietf.org/id/draft-soilandreyes-app-03.html
> >
> > 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
https://www.w3.org/TR/app-uri/ and https://www.w3.org/TR/widgets-uri/ 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://
https://docs.microsoft.com/en-us/windows/uwp/app-resources/uri-schemes#ms-appx-and-ms-appx-web 

..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:
https://lists.w3.org/Archives/Public/uri/2013Nov/0000.html
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:
https://gist.github.com/stain/45e5fea9701114082392a665f91e9183

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 
https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW10
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 https://tools.ietf.org/html/bcp35#section-6
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?  https://en.wikipedia.org/wiki/Mobile_deep_linking
:-(


> As and when this comes to me for IANA review, I'd like to see in this discussion 
> list (uri-review@ietf.org) 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:

https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/Security/Security_model#Packaged_Apps



-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/0000-0001-9842-9718