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

[Graham Klyne <[e-mail]>]

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


On 09/03/2013 18:20, Fredrik Ullner wrote:
> 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>.

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