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

[Graham Klyne <[e-mail]>]

Fredrik,

[I'm cc'ing [e-mail] on this response, as I feel there may be 
application protocol issues that list-members there may be able to comment upon 
with regard to specification, interoperability and security considerations issues.]

On 20/02/2013 20:26, Fredrik Ullner wrote:
> Hi,
>
> This is a request for registration of an URI scheme, dchub. The scheme can
> be viewed at <http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>.
>
> The URI scheme should meet the necessary requirements for a Permanent URI
> scheme, as indicating in RFC 4395. The scheme specifies encoding,
> interoperability and security aspects (and more). If the scheme should not
> provide enough information for a Permanent scheme, please specify what is
> lacking or at least consider a Provisional request instead.

NOTE: I am IANA's designated reviewer for URI scheme registrations, but this is 
a personal response, and does not represent any formal position at this time.

You'll need to send your request to IANA (cf. RFC 4395, section 5.2, item 5) for 
it to be considered for registration.  Requesting review here is the appropriate 
first step - the Right Thing to do :)

I would allow that the scheme is appropriate for provisional registration.

But the lack of a public specification (according to 
http://en.wikipedia.org/wiki/Direct_Connect_(file_sharing), which is cited by 
your registration template) causes me to question whether it's appropriate for 
permanent registration at this time.  On the other hand, the diversity of 
implementations suggests permanent registration may be appropriate.

I see that there is a specification at 
http://nmdc.sourceforge.net/Versions/NMDC-1.1.html, linked via the other 
reference in your registration template.  The question, then, is the extent to 
which this can be regarded as definitive for the protocol.

Of the criteria for permanent registration given in RFC4395:
      2.1.  Demonstratable, New, Long-Lived Utility  . . . . . . . . .  4
      2.2.  Syntactic Compatibility  . . . . . . . . . . . . . . . . .  5
      2.3.  Well-Defined . . . . . . . . . . . . . . . . . . . . . . .  5
      2.4.  Definition of Operations . . . . . . . . . . . . . . . . .  6
      2.5.  Context of Use . . . . . . . . . . . . . . . . . . . . . .  6
      2.6.  Internationalization and Character Encoding  . . . . . . .  7
      2.7.  Clear Security Considerations  . . . . . . . . . . . . . .  7
      2.8.  Scheme Name Considerations . . . . . . . . . . . . . . . .  7

I would judge that requirements 2.1, 2.2 (not checked in detail), 2.5, 2.6 and 
2.8 are satisfied.  My comments noted above are concerns with respect to 2.3 and 
2.4.  I would also be concerned that 2.7 security concerns have not been given 
sufficient consideration and review for permanent registration.

To recommend permanent registration, I would like to see:

(a) some clear indication that there is good consensus in the relevant developer 
community about what constitutes a suitable specification of the protocol 
(preferably with indications that implementations conforming to aid 
specification are interoperable, but I wouldn't see that as a must-have 
requirement here).

(b) some review within the IETF, or a community with corresponding security 
expertise, of the security considerations.  As they stand, they look very thin 
to me.

I hope this helps.

#g
--