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

[Graham Klyne <[e-mail]>]

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



On 19/01/2018 15:30, Stian Soiland-Reyes 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'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 [e-mail]
>
> Change controller: Stian Soiland-Reyes
>
> 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)
>
> On 18 January 2018 at 05:43, Carsten Bormann <[e-mail]> wrote:
>> On Jan 18, 2018, at 03:27, Stian Soiland-Reyes <[e-mail]> wrote:
>>>
>>> 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"?
>>
>> 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
>>
>
>
>