Re: [Uri-review] Review Provisional registration for app URI scheme
Stian Soiland-Reyes <stain@apache.org> Tue, 23 January 2018 14:48 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 1D13E126BF0 for <uri-review@ietfa.amsl.com>; Tue, 23 Jan 2018 06:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.93
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-ht85Sd6w7o for <uri-review@ietfa.amsl.com>; Tue, 23 Jan 2018 06:48:02 -0800 (PST)
Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id EA4011205D3 for <uri-review@ietf.org>; Tue, 23 Jan 2018 06:48:01 -0800 (PST)
Received: (qmail 24149 invoked by uid 99); 23 Jan 2018 14:48:00 -0000
Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2018 14:48:00 +0000
Received: from localhost (cspool35.cs.man.ac.uk [130.88.195.135]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id C9F051A0068; Tue, 23 Jan 2018 14:47:59 +0000 (UTC)
Date: Tue, 23 Jan 2018 14:47:56 +0000
Message-ID: <20180123144756.GB6275@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: <5A6711D9.6010403@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> <20180122013403.GC855@biggie> <5A6711D9.6010403@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/xSw8asizVZGs2DCbn97ekj1RjKU>
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: Tue, 23 Jan 2018 14:48:05 -0000
OK, fair enough, I'm not going to fight for consensus over a tricky name! While I like "arcid" it might be a future trademark violation against https://www.crossmatch.com/biometric-identity-solutions/products/software/arcid/ (although they have not registered such a trademark) Presumably I in URI already means identifier. Is "archive" too long or too generic? I think I will go with Roy's "arcp" (which don't show any trademarks) and let P stand for Package, not Pointer. :) On Tue, 23 Jan 2018 10:43:37 +0000, Graham Klyne <gk@ninebynine.org> wrote: > 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." > [https://tools.ietf.org/html/rfc7595, 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: > > > > > https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/Security/Security_model#Packaged_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. > > <aside> > 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 > Internet. > > A file URL takes the form: > > file://<host>/<path> > > where <host> is the fully qualified domain name of the system on > which the <path> is accessible... > > -- https://tools.ietf.org/html/rfc1738, sect 3.10 > > </aside> > > #g > -- > > > On 22/01/2018 01:34, Stian Soiland-Reyes wrote: > > 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 > > > > > >
- [Uri-review] Review Provisional registration for … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Alexey Melnikov
- Re: [Uri-review] Review Provisional registration … Julian Reschke
- Re: [Uri-review] Review Provisional registration … Carsten Bormann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Carsten Bormann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Carsten Bormann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … S Moonesamy
- Re: [Uri-review] Review Provisional registration … Roy T. Fielding
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Frank Ellermann
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes
- Re: [Uri-review] Review Provisional registration … Graham Klyne
- Re: [Uri-review] Review Provisional registration … Stian Soiland-Reyes