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

[Stian Soiland-Reyes <[e-mail]>]

On Sun, 21 Jan 2018 11:06:45 +0000, Graham Klyne <[e-mail]> wrote:
> On 19/01/2018 17:05, Roy T. Fielding wrote:
> >> On Jan 19, 2018, at 7:30 AM, Stian Soiland-Reyes <[e-mail]> 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 ([e-mail]) 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