Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub

From: Fredrik Ullner <[email-masked]>
Date: Sat, 9 Mar 2013 19:20:19 +0100

Hi,

A new version of the NMDC document is now available at <
http://nmdc.sourceforge.net/Versions/NMDC-1.3.html>. Note that the
versioning is the document's version, not the protocol, of which hasn't
changed in quite some time. There is also a new version of the URI scheme
available at <http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>.

The new URI scheme document;
* All sections are updated to be more explicit and each section should be
more focused compared to before.
* The security concerns are addressed. Note that the NMDC document
addresses some security items that are general for the protocol, hence the
reference.
* The document should use more references to other RFCs (notably 3986) and
use phrasing such as "SHOULD" and "MUST" to follow the 'RFC text standard'.
* The document should address many items that have been noted (see e.g.
Eric's mail).
* References to what some implementations support.
* Added a 'nmdcs' part to the document; I don't know if this is appropriate
for the document, though. (nmdcs is the TLS equivalent of the dchub URI.)
There's relatively low implementation support for it, but it can easily be
removed if it's deemed not widespread enough.

I am sure you all can understand that we want to push for a permanent URI
scheme. :)  If anything, it improves our own documentation and forces us to
consider things that may be obvious for the active development community
but not for an 'outsider'.

On Fri, Feb 22, 2013 at 4:13 PM, Graham Klyne <[email-masked]> wrote:

> I took a quick look.  It appears to be a vibrant developer community
> there, but I got a bit lost looking, e.g., for possible clues about
> interoperability of different implementations.
>
I can understand the concern for interoperability (see the new URI for
some). I don't currently have information on "x implementation support y
command" etc, but I'm sure we could compile such a list. I am unsure where
this information should be stored, but that's probably more of a concern
for me than you.

On Fri, Feb 22, 2013 at 4:13 PM, Graham Klyne <[email-masked]> wrote:
>
> The adcs: reference wasn't useful to me, as my browser doesn't know what
> to do with it - this is a perennial problem with new URI schemes, and is
> one reason why there is some reluctance to allow new permanent schemes -
> it's extremely difficult and expensive to get new schemes widely deployed.
>
Ah, yeah, that's why I hinted at downloading the most widely used clients.
(The client is Windows only, but there's e.g. Jucy <http://jucy.eu/> that
is Java so it should work if you're on a different OS.) I should note that
there's not necessarily more implementation support for dchub than for
adcs, there's just more links for the former. It's also why I asked about a
potential IRC channel, since I know it's may be more widely known.

Note that our estimates show that there's many thousands of users daily on
DC, all of which has a client capable of. See <
http://dcpp.wordpress.com/2012/07/11/statistics-for-dc/> for some
rudimentary stats for the client DC++ (note the post's comment).

(By the way, I apologize for not responding sooner. We've had discussions
and I didn't want to post anything until we had something more substantial.)

-- 
Fredrik Ullner

---

From: Graham Klyne <[email-masked]>
Date: Sun, 10 Mar 2013 15:57:54 +0000

I took a quick scan through the URI registration, and two points occurred to me.

On 09/03/2013 18:20, Fredrik Ullner wrote:
> available at<http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>.

1. (nit):  nmdcs is not immediately recognizable as something like "secure 
dchub".  Is there any reason to use this name rather than, say, 'dchubs'. 
(Deployed systems would be a good reason.)

2. "Userinfo, queries, fragments (and more), as specified by RFC 3986, is 
discouraged and SHOULD NOT be used."

With regard to fragment identifiers, I think it's not for the URI spec to 
require non-use.  When a URI used by a client (e.g. dereferenced), the fragment 
is stripped off and not sent to the server.  The client may then interpret the 
fragment in light of what media type is returned from the server.  SO, if the 
dchub protocol is used to retrieve an HTML document, the fragment identifier may 
be used to control the disposition opf thgat document in the same way that it 
would be used for a HTML document retrieved using HTTP.

Here, I think non-use of userinfo and queries is covered by the syntax given, so 
this statement could be dropped.  If you choose to keep this sentence, I think 
the bit that says that fragments SHOULD NOT be used should be removed.

...

Also, an observation.  There's a lot of normative language in this template, 
some of which is really about the protocol, which is not common to see in URI 
scheme registrations (for example, under scheme semantics and interoperability 
considerations).  While it's not formally incorrect, I'd be inclined to put some 
of this discussion in the protocol spec, or other specification document, and 
refer to it from the registration template.  The usual role of a URI 
registration template is to provide an overview and key information about a URI 
scheme, supported by references to separate documentation.  Your approach makes 
this an unusually long and complicated URI registration form.

I'm not saying here that it necessarily needs to be changed, but trying to give 
you a sense of how many specifications approach URI registrations.

#g
--

---

From: Eric Johnson <[email-masked]>
Date: Mon, 11 Mar 2013 11:48:21 -0700

On 3/10/13 8:57 AM, Graham Klyne wrote:
>
> Also, an observation.  There's a lot of normative language in this 
> template, some of which is really about the protocol, which is not 
> common to see in URI scheme registrations (for example, under scheme 
> semantics and interoperability considerations).  While it's not 
> formally incorrect, I'd be inclined to put some of this discussion in 
> the protocol spec, or other specification document, and refer to it 
> from the registration template.  The usual role of a URI registration 
> template is to provide an overview and key information about a URI 
> scheme, supported by references to separate documentation.  Your 
> approach makes this an unusually long and complicated URI registration 
> form.
Realizing that a number of these items you probably added to respond to 
my comment, I think Graham makes a critical point.

My question was about defining how one maps the URI to the protocol, not 
about repeating the definition of the protocol.

For example, this line:

" The client SHOULD request a TCP connection to the specified user via 
the commands $CTM (ConnectToMe) or $RCM (ReverseConnectToMe) (or an 
equivalent command)."

... I would write differently. The normative statements in this document 
ought to be about the URI and its use, rather than being normative 
statements about the protocol. There are lots of ways to use URIs that 
have nothing to do with the actual protocol (path computations, display 
on web pages, entries in a caching table). So the above statement, if it 
appears anywhere, should be in the protocol document. For the URI 
document, you could write something like this instead:

"With this form of URI, the client wishing to retrieve a file ought to 
request a TCP connection to the specified user via the commands $CTM 
(ConnectToMe) or $RCM (ReverseConnectToMe)."

I appreciate that you added the text, because it clarifies the use. It 
is just the normative part that triggers concern, because URIs have many 
uses....

One other thought. For a permanent registration, I interpret the need 
for a permanent URL to the document implying more permanence than the 
URL for this draft shows. For example, rather than updating the document 
in place, each new revision should have a new URL.

Eric.