Subject: [Uri-review] Review request for reload URI scheme

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Oct 2010 13:13:08 -0700

Please let me know if people see problems with the scheme defined in section 13.14 of draft-ietf-p2psip-base-10

http://tools.ietf.org/html/draft-ietf-p2psip-base-10#section-13.14

Thanks

---

From: Graham Klyne <[email-masked]>
Date: Sat, 09 Oct 2010 10:19:14 +0100

I've taken a quick look at the URI scheme definition (only), and it seems to me 
that its use of '//' and '/' in the URI is inconsistent with the intent of RFC3986.

Specifically, http://tools.ietf.org/html/rfc3986#section-1.2.3 discusses the 
hierarchical nature of URIs, and the role of '/' characters when URIs are 
handled by generic URI parsers.

In this case, as far as I can tell, there is no hierarchical structure to the 
reload: URIs, and the intended structure is more akin to (say) the mailto: URI 
(http://tools.ietf.org/html/rfc6068), which, lacking a hierarchical structure, 
does not use '//' to introduce an authority component.

Thus, I think the URI:

   reload://[email-masked]/

might more appropriately be rendered as:

   reload:[email-masked]

An example of where this might make a concrete difference is if a generic URI 
processor is presented with:

   [email-masked]

to be resolved against a base URI of:

   reload://[email-masked]/

then the correct result per RFC3986 would be:

   reload://[email-masked]/[email-masked]

but resolved against abase URI of

   reload:[email-masked]

the result would be

   reload:[email-masked]

The latter seems more likely to be the intended result.

...

Nit: I couldn't find any example of a reload URI in the draft - one might help.

#g
--

Cullen Jennings wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>