- From: Roy T. Fielding <roy.fielding@gmail.com>
- Date: Fri, 05 Dec 2014 18:28:09 +0000
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Mark Nottingham <mnot@mnot.net>, public-ietf-w3c@w3.org, Philippe Le Hegaret <plh@w3.org>, Wendy Seltzer <wseltzer@w3.org>
On Dec 5, 2014, at 8:52 AM, Sam Ruby wrote: > Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review. > > PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject. In order for the IETF to take a position on the subject, it would require an Internet draft stating the position and an appropriate public review. Even so, at best what you would get is a bunch of opinions on what might be a reasonable way forward. IMO, a solution would be to just remove the bits of the URL spec that say it redefines RFC3986 (because it doesn't), name the spec to something reasonable (like "URL Object and Processing References in HTML"), and then complete the work you have started on making the parsing algorithm for references more closely reflect deployed implementations. I don't think the IETF protocols that depend on RFC3986 would have any problem with such a document, and it would satisfy the needs of HTML. However, it is still ridiculous to claim that URI != URL in Web parlance. URL is and always has been the subset of URI that can be used as a locator, which most people understand to be equivalent to the set of all URI once they figure out how HTTP works. Changing the existing term URL to fit the definition of a reference is just plain confusing, even within the HTML specifications. I know because I tried to do that myself in the early drafts of RFC1808. If the goal is to produce quality specifications, we should expect the terms to be used correctly. .....Roy
Received on Friday, 5 December 2014 21:37:11 UTC