To: uri@bunyip.com
Subject: Proposed change to URN Requirements document
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Sep23.143411pdt.2763@golden.parc.xerox.com>
Date: Fri, 23 Sep 1994 14:34:10 PDT
This message is in response to an objection raised to the URN
Requirements document during the 'last call' review. In it, there is a
proposal to change the URN requirements document to clarify the
relationship of "legacy support" with other requirements. Your opinion
about the technical merits of this change is requested.
There have been a number of messages discussing the non-technical
issues around those objections (who said what to whom, how much do the
documents cost, etc. etc.); personally, I'd rather ignore them for now
and just focus on the technical ones.
As far as we (Karen Sollins and I) can tell, there are two primary
technical objections to the document as it is written.
The first centers around a sentence in the introductory paragraph:
> The requirements for uniform resource names (URNs) fit within the
> overall architecture of Uniform Resource Identification.
Apparently, there is some confusion that this might mean that the
syntax for URNs must match the syntax for URIs as expressed in
RFC1630, even though no explicit reference is made here to RFC1630. I
don't believe "architecture" means the same thing as "format for
laying out names", or that it is the common usage. However, if there's
a serious risk that this confusion will carry forward to other
individuals, we will be willing to clarify this point.
The second objection centers around an understanding of the
relationship between the requirement for legacy support:
> o Legacy support: The scheme must permit the support of existing
> legacy naming systems. For example, ISBN numbers, ISO public
> identifiers, UPC product codes and the like are naming schemes
> which should be allowed to be embedded within the URN system.
and other requirements. In particular, some legacy naming systems do
not have global scope, persistence, use case-sensitive names; this
requirement might be inconsistent with the other requirements in the
document. It would be possible to clarify this point, e.g., by
rewording that requirement to read:
> o Legacy support: The scheme must permit the support of existing
> legacy naming systems, insofar as they satisfy the other
> requirements described here. For example, ISBN numbers, ISO
> public identifiers, and UPC product codes seem to satisfy the
> functional requirements, and allow an embedding that satisfies
> the syntactic requirements described here.
As a way to resolve this issue, I would like to propose that we adopt
this wording change. It makes it clear that legacy support is of lower
priority than the other requirements. This will remove a seeming
contradiction from the requirements document, and, along the way,
reduce the causes of concern over potential incompatibilities with the
forthcoming XFN work.
A particular sub-issue to "legacy support" is the issue of
case-sensitivity. The URI working group discussed the issue of case
sensitivity at length, and came to consensus (with little or no
objection) that URNs should be case insensitive. That there are legacy
naming systems that use case sensitive names should not deter us from
that resolve, even if it means that we will have some difficulty
embedding those legacy systems within the overall URN framework.