8116 2009-10-28 14:17:07 +0000 URNs are URIs but not URLs 2010-10-04 14:47:42 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#global-identifiers-for-items TrackerIssue P3 normal LC 1 contributor ian ian julian.reschke lmm mike mjs public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 29172 0 contributor 2009-10-28 14:17:07 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#global-identifiers-for-items Comment: URNs are URIs but not URLs Posted from: 91.61.41.178 29173 1 julian.reschke 2009-10-28 14:35:30 +0000 Depends on whether you read "URL" as "URL as defined by RFC3986", or as "URL as defined by HTML5". (should we count the confused readers?) 30015 2 ian 2009-12-08 16:47:48 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The term "URL" is hyperlinked to a definition that includes urn: URLs. Anyway, some people are suggesting that urn: can be used for resources that can be located (e.g. in the File API), so it's clear that that scheme _can_ be locatable. So I don't think it's even wrong per the latest changes to the meaning of URI/URN/IRI. We (the standards community) really need to give up on this naming nonsense and just go back to URL, which is what everyone else calls them. 33698 3 lmm 2010-03-18 17:29:36 +0000 Note that change proposal http://lists.w3.org/Archives/Public/public-html/2010Feb/0882.html for ISSUE-56 (http://www.w3.org/html/wg/tracker/issues/56) at least explains that this specification uses "URL" in ways different than the rest of the web community (and also, by using URL for relative forms) in ways that are not even common in the public literature. Note also that the IETF document draft-ietf-iri-3987bis (http://tools.ietf.org/wg/iri/draft-ietf-iri-3987bis/) contains advice about using "URL" in formal documents, and there is a bug report http://trac.tools.ietf.org/wg/iri/trac/ticket/9 which discusses that issue. Since the response to this bug was "We (the standards community) really need to give up on this naming nonsense and just go back to URL, which is what everyone else calls them.", it would seem appropriate get the standards community to follow that advice. See also http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html for some history. 34263 4 ian 2010-03-31 20:17:41 +0000 Returning to WONTFIX since no new information has been added since comment 2. 35752 5 lmm 2010-05-19 00:22:08 +0000 Comment #4, which says that comment #3 contains "no new information", is specious. This is an editorial bug, not a specification bug, and comment #3 contains new information not present before about the editorial status. This bug could be linked to ISSUE-56, but it is actually a separate issue, the use of the term "URL" in the HTML specification, vs ISSUE-56 which covers the relationship between the HTML specification and the IRI specification The first change proposal for ISSUE-56, http://lists.w3.org/Archives/Public/public-html/2010Feb/0882.html also addresses this bug. The second change proposal: http://lists.w3.org/Archives/Public/public-html/2010Apr/0147.html does not. So if the second change proposal for ISSUE-56 is accepted, then this (editorial) bug needs to be escalated to another issue. 35757 6 mjs 2010-05-19 07:28:05 +0000 I believe this is ISSUE-78: http://www.w3.org/html/wg/tracker/issues/78 35914 7 lmm 2010-06-02 21:29:06 +0000 ISSUE-78 is (was) already marked as CLOSED. (ISSUE-78 did have an offer to write a change proposal, although not on a schedule to the satisfaction of the chairs.) ISSUE-78 is different, in that it explicitly calls for changing URL in the HTML document. The 'bug' here is that even if the terminology isn't changed, the terminology differences should be explained. In any case, TrackerRequest was not added according to the decision policy because: (a) I do have access to the tracker, and *could* open my own issue (b) TrackerRequest bugs should suggest a title. I'm not going to open an issue at this point, but wanted to note the anomaly that something could transition from TrackerRequest to TrackerIssue without the bug actually being mentioned in the body of the issue, as is required. (Presumably doing so would be 'new information' which would cause the issue to re-open.)