Re: [Uri-review] Review request for gittorrent: URI scheme

[Graham Klyne <[e-mail]>]

Hi Chris,

Thanks for your response.  I would like to clarify that none of my comments are 
blockers for a provisional registration, rather suggestions on the assumption 
that this work might progress to something more widespread.

With reference to 'verbiage noting the de-facto and fluid nature of the 
"specification"', that could help but it's difficult for me to offer a definite 
view without seeing it.  I could point out that a URI scheme registration is 
not, of itself, an implementers guide.

My comments have their roots in the idea that URIs are not _just_ protocol 
elements, but also part of a wider information infrastructure (the Web), and as 
such might be used in ways that are not anticipated by a particular protocol 
implementation.  The prescriptive elements I was pushing back against are, I 
think, more properly part of the actual "gittorrent" protocol specification than 
of the associated URI scheme.  My normal expectation is that a URI scheme 
registration will provide references to protocol descriptions and/or 
implementations that contribute to the meaning of the URI, but would not of 
itself attempt to be a protocol specification.

RFC3986 starts with this: "A Uniform Resource Identifier (URI) provides a simple 
and extensible means for identifying a resource."  Later 
(https://tools.ietf.org/html/rfc3986#section-1.1) it goes on to discuss 
identification in a little more detail; e.g.

"Nor should it be assumed that a system sing URIs will access the resource 
identified: in many cases, URIs are used to denote resources without any 
intention that they be accessed."

and

"URIs have a global scope and are interpreted consistently regardless of 
context, though the result of that interpretation may be in relation to the 
end-user's context."

etc.

None of this is to comment on the "gittorrent" protocol itself, or its 
applications, but simply to try and suggest a clearer separation between the 
identifying function of the URI and the protocol through which that 
identification might be realized.

To try and make this more concrete, consider the following (entirely 
speculative) example.  A developers' "intranet" might host a number of git 
repositories that are accessed and updated using gittorrent protocols from 
across the Internet.  The gittorrrent URIs could be the primary identifiers for 
these repositories, but local access could be via git HTTP protocol via a local 
HTTP caching proxy (similar to the way that HTTP proxying can be used locally to 
access FTP-served resources).  In this scenario, the gittorrent URI identifies 
the repository, and gains its meaning (i.e. what it references) via the 
gittorrent protocol, but is not necessarily invoked in local retrieval of 
repository data.

I don't think my comments need to be acted on immediately, and the provisional 
registration should probably go ahead pretty much as-is, but, looking ahead, in 
formulating specifications for wider interoperable public use they might be 
something to consider.

#g
--


On 06/04/2016 05:36, Chris Rebert wrote:
> On Mon, Apr 4, 2016, at 12:51 AM, Graham Klyne wrote:
>> I have two comments:
>>
>> 1. It is not the place of a URI scheme registration to prohibit the use
>> of
>> fragments.  I suggest dropping the sentence "The "fragment" URI component
>> is
>> never permitted" under section "semantics".  (The protocol may not allow
>> fragments, but that's no different from HTTP - once a URI is
>> dereferenced, it is
>> the format of the resulting representation that determines how if and how
>> fragments may be applied.)
>
> Okay, dropped that sentence.
>
>> 2 The registration says "gittorrent URIs represent Git repositories".
>> Looking
>> at the descriptions, it seems that the URI denotes one of three different
>> things, depending on the form used:
>>
>> Type 0: appears to denote the hash of the latest commit in the
>> repository.
>>
>> Type 1: appears to denote the repository itself, as accessed via a
>> bittorrent stream
>>
>> Type 2: appears to denote a bitcoin transaction element containing a
>> reference
>> to the repository per type 1.
>>
>> I observe that there appears to be a tight coupling between the URIs and
>> the
>> resource representations associated with dereferencing of the URIs.  If
>> this is
>> seen as being part of Web architecture (else why use URIs?), then I'd be
>> inclined to be less prescritive about representation details. These may
>> be a
>> feature of current implementations, but who knows how future
>> implementations may
>> evolve?
>
> Not giving any details on interpreting the URIs seems unhelpfully vague
> for implementors of other clients (there's currently only a reference
> implementation). However, I've now added verbiage noting the de-facto
> and fluid nature of the "specification". Hopefully that helps address
> this concern?
>
> Regards,
> Chris
>