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

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 17 Jan 2018 14:46:47 +0000

Scheme name: app

   Status: provisional

   Applications/protocols that use this protocol: 
     Hypermedia-consuming application that handle archives.

   Contact: Stian Soiland-Reyes [email-masked] [1]

   Change controller: Stian Soiland-Reyes

   References:
   
   https://rawgit.com/stain/I-D/master/app/app.html
   https://github.com/stain/I-D/tree/master/app

I am intending to submit the above as an invididual Internet-Draft and then
update References accordingly; I am not sure if I should do the provisional
registration first or do them together?

BTW; to which IANA body should I submit the Internet-Draft for review?

-- 
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Jan 2018 15:42:42 +0000

Hi Stian,

> registration first or do them together?
You can do provisional registration with or without a draft. However 
having a draft would be better long term.
> BTW; to which IANA body should I submit the Internet-Draft for review?
You should send it to IETF Area Directors <[email-masked]>. One of the 
3 Area Directors will guide you through the rest of the process.

Best Regards,
Alexey

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Jan 2018 17:15:32 +0100

On 2018-01-17 15:46, Stian Soiland-Reyes wrote:
> ...

...FWIW, the name "app" IMHO is very very misleading. Maybe you could 
consider something that more reflects what's being identified by the URIs?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jan 2018 17:38:36 +0100

> ...FWIW, the name "app" IMHO is very very misleading. Maybe you could consider something that more reflects what's being identified by the URIs?

… which raises the question what “app” stands for.
The draft talks about archives and packages, which explains “a” and the first “p”, but I don’t understand the second “p” (pointer?).

Yes, I read about the desire to stay compatible with https://www.w3.org/TR/2015/NOTE-app-uri-20150723/, but it probably would help to have a more accurate retronym if that is necessary.

(I’m interested in this as it is sometimes useful to have URIs for references from a CBOR data item to other data items within a bigger, compound data item.  We could define this based on this scheme or in a different way, possibly based on the way the compound data item is formed.)

Grüße, Carsten

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 17 Jan 2018 16:42:24 +0000

> consider something that more reflects what's being identified by the URIs?

Yes, ideally a name like "archive" would be more general and appropriate.

I addressed that in
https://rawgit.com/stain/I-D/master/app/app.html#rfc.appendix.B as I
preferred to keep it backwards compatible with the previous W3C
attempt of app URI scheme.

Here's how we used "app" in 2014 - perhaps prematurely we could say now:
https://w3id.org/bundle/#absolute-uris

I consulted with the original author who agrees the W3C Note is
abandoned - but he suggested not to register "app" as Historical to
leave the door open for others.
https://github.com/sysapps/app-uri/issues/44

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 17 Jan 2018 16:46:44 +0000

> Yes, I read about the desire to stay compatible with https://www.w3.org/TR/2015/NOTE-app-uri-20150723/, but it probably would help to have a more accurate retronym if that is necessary.

+1 to make a good bacronym :) "Archive and Packaging Protocol"?

But.. I deliberately left out a protocol unless
https://rawgit.com/stain/I-D/master/app/app.html#rfc.section.3.1
counts?

> (I’m interested in this as it is sometimes useful to have URIs for references from a CBOR data item to other data items within a bigger, compound data item.  We could define this based on this sche…

Interested in your requirements here, specially if you need more
flexibility in the authority or path field. I guess this will fit into
the comments on the Internet-Draft -- but feel free to do Pull
Requests before that ! :)

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Wed, 17 Jan 2018 17:23:38 +0000

>    Change controller: Stian Soiland-Reyes

https://www.ietf.org/id/draft-soilandreyes-app-00.txt

(the HTML formats are not yet through the pipeline)

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jan 2018 18:42:10 +0100

On Jan 17, 2018, at 17:46, Stian Soiland-Reyes <[email-masked]> wrote:
> +1 to make a good bacronym :) "Archive and Packaging Protocol”?

Maybe better: "Archive or Package internal Pointer"?

> https://rawgit.com/stain/I-D/master/app/app.html#rfc.section.3.1

Right, protocol is probably misleading.

> Requests before that ! :)

I haven’t put much thought into the general problem yet, but this sounds like a neat piece of research to engage in.
(But probably not on this list.  We have T2TRG for that...)

Grüße, Carsten

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Thu, 18 Jan 2018 02:27:17 +0000

> Maybe better: "Archive or Package internal Pointer"?

Now title of Internet-Draft is "The Archive and Packaging Pointer system"
https://tools.ietf.org/html/draft-soilandreyes-app-01

-- or should it still be "the app URI scheme"?

Marcos Caceres, the editor of both original W3C Notes, agreed to join
as co-author, which should hopefully show continuity for the "app"
name.

I sent it to art-ads@ietf for review.

Thanks for your rapid help, URI folks!
Anything else that needs addressing for a provisional registration..?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 18 Jan 2018 06:43:54 +0100

> -- or should it still be "the app URI scheme"?

It is nice to expand the retronym, but I think you also need the actual name of the URI scheme in the title.

Grüße, Carsten

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Fri, 19 Jan 2018 15:30:23 +0000

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've also fixed and clarified some other minor things here and there,
thanks everyone for feedback.

Suggested new registration:

Scheme name: app

Status: provisional

Applications/protocols that use this protocol: Hypermedia-consuming
application that handle archives or packages.

Contact: Stian Soiland-Reyes [email-masked]

Reference: https://tools.ietf.org/id/draft-soilandreyes-app-03.html

BTW, people have been reporting 404 Not Found from server 4.31.198.61
on the https://tools.ietf.org/html URIs - I've reported this to
webmaster@ietf)

---

From: S Moonesamy <[email-masked]>
Date: Fri, 19 Jan 2018 08:48:44 -0800

Hi Stian,
>The Archive and Packaging Pointer (app) URI scheme

I'll comment quickly.  In Section 2.1 of draft-soilandreyes-app-03, 
there is the following: "Below are some recommendations".  Some of 
the RFC 2119 key words below are not used for recommendations.  The 
quick fix I can think of is to remove that sentence.

Regards,
S. Moonesamy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 19 Jan 2018 09:05:08 -0800

> On Jan 19, 2018, at 7:30 AM, Stian Soiland-Reyes <[email-masked]> wrote:
> 

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.

....Roy

---

From: Graham Klyne <[email-masked]>
Date: Sun, 21 Jan 2018 11:06:45 +0000

> "arcp" would make more sense and not mislead 99% of the people who see it.

+1 (wearing personal hat)

As and when this comes to me for IANA review, I'd like to see in this discussion 
list ([email-masked]) 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.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Sun, 21 Jan 2018 12:27:02 +0000

Hi Stian,

I finally get round to reading the scheme spec...  I think this will be a useful 
piece of work, though at points I found myself wondering about its intended 
scope of purpose, particularly the level of interoperability that is intended to 
be provided by the URI scheme in general vs particular implementations.  I offer 
a few comments (wearing personal hat):

...

## Section 2

[[
The semantics of the query component is undefined by this Internet-Draft. 
Implementations SHOULD NOT generate a query component for app URIs.

The “fragment” component MAY be used by implementations according to [RFC3986] 
and the implied media type [RFC2046] of the resource at the path. This 
Internet-Draft does not specify how to determine the media type.
]]

I could imagine using this scheme in conjunction with an web application I'm 
working on pretty much for the reasons indicated in the intro.  But my 
application does use query URIs, so, while I'm OK with the semantics being 
undefined by this specification, the SHOULD NOT exhortation seems a bit strong 
to me.

But this does make me wonder what kinds of interoperability are intended to be 
enabled by this specification... what software is expected to understand 
specific semantics that aren't provided by some existing scheme (e.g. for my 
application, I currently use an HTTP base URI associated with the web service, 
but I could imagine other URIs being workable.

The later discussion about implementation via URI mapping (section 3.1) suggests 
that queries might be appropriate, e.g. if resolution is handled by an embedded 
web application.

nit: "undefined by this Internet-Draft" might be better expressed as "undefined 
by this specification" (I-Ds are supposed to be transient, and if this idea 
progresses I would suggest requesting an informational RFC publication - 
possibly independent stream).

## Section 2.1

[[
.. extensions of this Internet-Draft are permitted to do so, if using a DNS 
domain name under their control. For instance, a vendor owning example.com may 
specify that {OID} in {OID}.oid.example.com has special semantics.
]]

I'm a bit uneasy with this: it's not clear to me that there isn't some confusion 
here between I'd call "extension specifications" and "implementations" of this 
specification.  If "implementations", then I'm not convinced there's any 
conflict with RFC7320.  If "extension specifications", then to what extent would 
it be appropriate for these to be tied to a specific domain?   (Noting, en 
passant, that control of domain names tends to be transient.)

My suggestion would be to say nothing about this here, and leave it up to any 
specification that does want to impose a structure or semantics for URI 
authorities to justify why it does so in contravention of RFC7320 .

(Also, see again above nit about "Internet-Draft".  There are several more 
instances later in the document - I shalln't repeat this point.)

...

## Section 2.1

I'm not sure what useful purpose is served here by the discussion of choice of 
authority scheme.

Suggest: for the syntax, just stick with RFC3986 "authority" production, and add 
some informative recommendations about using UUID and/or RFC6920, noting that 
they are syntactically subsumed.

If, on the other hand, it is important to distinguish these authority forms for 
some reason, then I think it might be better (i.e. less prone to implementation 
error) by incorporating some clear syntactic marker into the format (that still 
confirms to RFC3986 syntax of course).

...

## Section 2.2

[[
In an app URI, each intermediate segment (or segment-nz) represent a directory 
name, while the last segment represent either a directory or file name.
]]

It seems a little odd to me that a scheme that is intended for use where file: 
URIs are inappropriate is so dependent on the language of file systems.  (e.g. 
how obvious is the interpretation of this scheme is used for referencing an LDP 
container?) [http://www.w3.org/TR/ldp/]

Suggest: drop this (and the following para).  (Why is it needed?)

...

## Section 3

[[
This Internet-Draft does not constrain what particular format might constitute 
an archive, and neither does it require that the archive is retrievable as a 
single bytestream or file. Examples of archive media types include 
application/zip, application/vnd.android.package-archive, application/x-tar, 
application/x-gtar and application/x-7z-compressed.
]]

I note all your examples *are* "retrievable as a single bytestream".  May I 
suggest including an LDP container [http://www.w3.org/TR/ldp/] as a possible 
example?  (This isn't entirely hypothetical - a colleague of mine has done work 
on an "object" scheme that uses LDP containers in ways that might constitute an 
"archive".

The next paragraph says:

[[
The authority component identifies the archive file.
]]

Which appears to contradict the first quoted paragraph.

I suspect the spec could benefit from an introductory section that describes 
what is meant by an "archive", then proceeds to use that term.

...

## Section 3/.1, bullet 7

[[
Return the archive file if the path component is missing/empty.
]]

Appears to contradict section 3 (see comments above).

I see you address this later.  In view of that, I feel that the use of normative 
language ("SHOULD") is inappropriate - given the range of implementation 
options, it's not clear that this is really an interoperability concern.

...

## Section 5

[[
5. An implementation describe an archive using the alg-val production, but a 
second implementation concurrently modifies the archive’s content. The first 
implementation may need to detect changes to the archive file stamp or 
re-calculate the checksum at the end of its operations.
]]

This seems muddled to me.  In this case, if the archive content is modified then 
it is no longer identifiable using the same "ni:" URI.  I think this shouldn't 
be a concern for this spec.

[[
6. Two implementations might have different views of the content of the same 
archive if the format permits multiple entries with the same path. Care should 
be taken to follow the convention and specification of the particular archive 
format.
]]

I think this point, if it arises, indicates a violation of the URI spec.  I 
would suggest that if an archive can have multiple entries with the same path, 
then this spec should define some way of allocating unique paths to each 
occurrence.  But that would probably be a pain for implementers.

OR, simply say that if an internal path/identifier is duplicated within an 
archive, then the effect of dereferencing the archive URI s undefined.  (Kind-of 
saying "don't do that"!)

...

## Section 6

(Some good points here :) )

[[
In particular for IRIs, an archive might contain multiple paths with 
similar-looking characters or with different Unicode combine sequences, which 
could be facilitated to mislead users.
]]

nit: "facilitated"?  Suggest maybe "intended" or "deployed"

[[
An URI hyperlink might use or guess an app URI authority to attempt to climb 
into a different archive for malicious purposes. Applications SHOULD employ Same 
Orgin policy [RFC6454] checks.
]]

I note that the use of an explicit reference to a different archive could be 
legitimate ... this comment might be read as suggesting that any such reference 
should be disallowed.  (I have a potential use-case for valid cross-archive 
references.)

...

## Section 7

[[
This Internet-Draft contains the Provisional IANA registration of the app URI 
scheme according to [RFC7595].
]]

(Nit) Suggest this makes explicit equest to register the scheme; e.g.

[[
This specification requests that IANA register the following URI scheme 
according to the provisions of [RFC7595]:
]]

...

regards,

#g
--

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Mon, 22 Jan 2018 01:34:03 +0000

> +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
:-(

> 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

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Mon, 22 Jan 2018 18:59:14 +0000

> the application aspect, and perhaps also covered non-file resources such

Thank you all for the feedback!

https://tools.ietf.org/id/draft-soilandreyes-app-04.html

"Application and Packaging Pointer (app) URI scheme"

Addresses:
* More emphasis on "apps" again
* (I think) all of Graham's comments
* Added mobile app example
  https://tools.ietf.org/id/draft-soilandreyes-app-04.html#rfc.appendix.A.1
* Added authority prefixes "uuid" "ni" and "name" and simplified
  https://tools.ietf.org/id/draft-soilandreyes-app-04.html#rfc.section.3.1
* Semantics of schemes explained at
  https://tools.ietf.org/id/draft-soilandreyes-app-04.html#rfc.section.4.1
* Removed references to retrieve the archive file
* ?query permitted again (but undefined semantics)

The downside is you may consider URIs look slightly uglier with 
prefixes:

app://name,gallery.example.org/photos/?New
app://uuid,32a423d6-52ab-47e3-a9cd-54f418a48571/
app://ni,sha-256;F-34D4TUeOfG0selz7REKRDo4XePkewPeQYtjL3vQs0/file.txt

Still.. not too long!  (And in fact we could avoid "name," because DNS
names can't have ",")

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Tue, 23 Jan 2018 09:58:40 +0000

Thanks for your thorough review! My apologies for the trouble as this
is my first Internet-Draft.

I integrated changes below into
https://tools.ietf.org/id/draft-soilandreyes-app-04.html

> undefined by this specification, the SHOULD NOT exhortation seems a bit strong 

Yes, I was thinking from the point of identifiers, .../file.txt?query would mean
another URI seemingly not be identical to .../file.txt 

But I'll rather leave the meaning of query undefined as you propose -
that's more like an implicit MAY -- you can do it, but you better figure
out yourself what that means.

> possibly independent stream).

Done - I was not sure if I could call it "specification" at this
point. :)

> passant, that control of domain names tends to be transient.)

I've added authority prefixes like "uuid,".  The prefix "name," means a 
DNS-like namespace that is unique within an installation, e.g. 
app.example.com 

> authorities to justify why it does so in contravention of RFC7320 .

I think the uniqueness semantics here are important for anyone consuming
the app URIs as identifiers. So I've clarified this with a new
"authority semantics" session. The "authority syntax" now only
introduce the prefixes and production rules.

> I'm not sure what useful purpose is served here by the discussion of choice of 

It's an attempt to build common ground. If everyone does their own game,
say app://2018-01-22/ there is bound to be someone mixing it up, and
then there was little purpose of this URI scheme over say the file:///
scheme with a fake host name.

I've added an authority semantics section.

> confirms to RFC3986 syntax of course).

I suggest later in the examples why the distinction might be important,
e.g.  recognizing an UUID from declared "External-Identifier" metadata,
or using the ni hash to resolve from a .well-known/ni/ endpoint.

But perhaps then there should be a clearer separation as you suggest,
using defined prefixes. Other prefixes would then be
undefined, but available for extensions.

app://uuid,1559aebe-c273-4be3-9333-3073c67bd9a1/ 
app://ni,sha-256;F-34D4TUeOfG0selz7REKRDo4XePkewPeQYtjL3vQs0/
app://name,example.com/  

I've added such, with generic "authority" as fallback as before to
permit any extensions.

This should make a clearer split between implementation-specific
authorities (which can use "name," with their domain name) and
extensions (which can make "somethingnew,")

> Suggest: drop this (and the following para).  (Why is it needed?)

Agreed  - I've removed large parts of path semantics, limiting it to
recommending / as separator.

> on an "object" scheme that uses LDP containers in ways that might constitute an 

That's a nice use case - added as an example.

> what is meant by an "archive", then proceeds to use that term.

Added, including examples of non-file "archives".

> options, it's not clear that this is really an interoperability concern.

I think this is a good argument to remove the consideration for an empty
path at all.

> 6. Two implementations might have different views of the content of the same 

I've removed both interoperability considerations and added a clause to
Path Semantics.

> nit: "facilitated"?  Suggest maybe "intended" or "deployed"

Changed to "used"

> should be disallowed.  (I have a potential use-case for valid cross-archive 

Added "if resolving cross-references is not desired"

> according to the provisions of [RFC7595]:

I used that exact wording.

Thanks, Graham!

---

From: Graham Klyne <[email-masked]>
Date: Tue, 23 Jan 2018 10:43:37 +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." 
[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.

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
--

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Tue, 23 Jan 2018 14:47:56 +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. :)

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Tue, 23 Jan 2018 14:58:59 +0000

> revised scheme might be options to consider here.

Yes, perhaps such an historical registration can also point forward to
the arcp registration.  

I'll keep (but modify) the "History" section in the arcp Internet-Draft.

> but I'm sure others would have different perspectives.

Yes, this is why early specifications of widget URI scheme strongly
recommended UUID authorities, so that such URIs would be safe to leak
(although non-functioning outside the local system).  For whatever
reason this recommendation was lifted in later app-uri specs which
increased risk of collisions.

I am ambivalent if my proposed "name," prefix should be kept in "arcp"
or if we should only recommend UUID or hash.

(but at least with DNS names you will mainly collide with yourself :)

---

From: Graham Klyne <[email-masked]>
Date: Fri, 26 Jan 2018 11:47:15 +0000

On 23/01/2018 14:47, Stian Soiland-Reyes wrote:
> not Pointer.:)

Works for me :)

(FWIW, I don't think "archive" is too long, and I think its genericity matches 
the spec, so i don't see a problem there.)

#g
--

---

From: Stian Soiland-Reyes <[email-masked]>
Date: Fri, 26 Jan 2018 13:28:32 +0000

> the spec, so i don't see a problem there.)

Good to know :) But "arcp uri" is a bit more googleable, so I settled
for that.

Anything else needed for provisional registration of arcp ?
https://tools.ietf.org/id/draft-soilandreyes-arcp-02.html#rfc.section.8

(also sent as separate email to this list)