This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8116 - URNs are URIs but not URLs
Summary: URNs are URIs but not URLs
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Keywords: TrackerIssue
Depends on:
Reported: 2009-10-28 14:17 UTC by contributor
Modified: 2010-10-04 14:47 UTC (History)
7 users (show)

See Also:


Description contributor 2009-10-28 14:17:07 UTC

URNs are URIs but not URLs

Posted from:
Comment 1 Julian Reschke 2009-10-28 14:35:30 UTC
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?)
Comment 2 Ian 'Hixie' Hickson 2009-12-08 16:47:48 UTC
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:

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.
Comment 3 Larry Masinter 2010-03-18 17:29:36 UTC
Note that change proposal for ISSUE-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 ( contains advice about using "URL" in formal documents, and there is a bug report 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 for some history.
Comment 4 Ian 'Hixie' Hickson 2010-03-31 20:17:41 UTC
Returning to WONTFIX since no new information has been added since comment 2.
Comment 5 Larry Masinter 2010-05-19 00:22:08 UTC
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, 
also addresses this bug.

The second change proposal:

does not.

So if the second change proposal for ISSUE-56 is accepted, then this (editorial) bug needs to be escalated to another issue.
Comment 6 Maciej Stachowiak 2010-05-19 07:28:05 UTC
I believe this is ISSUE-78:
Comment 7 Larry Masinter 2010-06-02 21:29:06 UTC
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.)