I remain of the view that the URN/URL distinction is unhelpful because it is meaningless. There are no sharp boundaries between categories of identifier as the distinction supposes.
Before making this argument in more detail, I will make a plea for respect. I find that the biggest obstacle to getting clarity on naming is that when faced with an analysis that contradicts deeply held beliefs, the usual response is to tell people to 'do some research' or 'understand the issues'.
The URN/URI distinction does not in fact represent an essential distinction between types identifiers as claimed. It describes a difference in source of authority at best, not an essential property.
1) DNS names are names.
This is easy to see, it is what the N stands for. The signifier bears no direct relation to the signified. It is a purely conventional relationship.
2) IP addresses are also names
Again, the signifier bears no direct relation to the signified. It is a purely conventional relationship.
3) File names are names
Again, the signifier bears no direct relation to the signified. It is a purely conventional relationship.
4) HTTP local paths are names
See above.
So a HTTP URL consists of
<method part> :// <IANA name part> // <local name part>
So a URL is obviously a form of name. The location semantics are not intrinsic to the name itself, they are intrinsic to its mode of use.
If you look at practically every UR'N' scheme it has precisely the same form albeit with different syntax. There is a method part and some hierarchical delegation of naming. But (with rare exceptions) it is naming all the way down.
The reason URL/URL discussions are so notoriously unproductive is people are attempting to make an intrinsic distinction between classes of name where there is none.
The only forms of network identifier that are not pure names are data URIs and the ones that are indexical such as the ni: scheme described in RFC6920.
But even that distinction can be bent. The strong Internet Names I propose here:
https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html define a subset of DNS labels that are indexical rather than names. And those have some important and useful properties. They allow the result of a trust decision to be encapsulated as an atomic name.
On Tue, Jan 7, 2020 at 1:58 AM John C Klensin <john-ietf@xxxxxxx> wrote:
Hi.
My apologies for the extreme lateness of this note. I have
tried to pass URN work on to others since RFCs 8141 and 8254 and
had assumed that someone else would check through this document
to be sure that it appropriately covered both locator-type and
name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3).
I had assumed that reviews within the ART area and/or a specific
ART Area Review would address that topic but, AFAICT, they may
not have done so.
I've had occasion to look through the document and I'm actually
not sure about the name-locator distinction as it may apply to
it. This note will be short and is rather more about asking the
IESG to be sure that any possible issues are addressed than to
try to do a detailed review of the issues.
AFAICT, the focus of the I-D is to be sure that applications and
elaborations of any URI scheme be firmly under the control and
management of the owner of that scheme and that possible
deviations from that principle are well-controlled.
http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1,
cited in the draft as [webarch] is clear that the ownership of a
URN is delegated to the owners of URN Namespaces rather than
being bound to the "urn" URI scheme itself. I believe it is
possible to read this document in a way that has no impact on
URNs and URN namespaces. However, it appears to me that, if
read without appropriate care, some of the restrictions imposed
on queries and fragments may be inconsistent with mechanisms and
syntax for use in particular URN Namespaces or URNs generally
that were contemplated and extensively discussed during the
development of RFC 8141. Those ideas were deferred by the WG
for future work but the mechanisms may well be in use in
important URN namespaces. Because the last paragraph of Section
1.1 of this I-D essentially declares any existing specification,
even a standards-track one or one adopted by other bodies, that
does not comply with the recommendations of the I-D to be
incorrect and in need of correction, the effects of a reading
that retroactively restricts URN Namespace practices that are
under the control of the Namespace owners could be quite serious.
My preference would be that someone who has been more active
with URN work and Namespace registrations in the last couple of
years do a careful review of the document to determine whether
my concerns justify some tuning of the text. However, given how
late it is in the review process (again, my apologies for not
catching the issue until now), a reasonable alternative would be
to simply insert a sentence early in the I-D that says that it
applies primarily to locator-type URIs although name-type ones
may find it useful as general guidance _or_ to explicitly call
out the difference in ownership between URNs and other URI
schemes.
thanks,
john
p.s. It would be, IMO, helpful if the IESG and the community
would think about the implications of BCP (or IETF-stream
Informational) documents that effectively obsolete or deprecate
existing standards without identifying them or explicitly
updating them and whose responsibility it is to find the
discrepancies.
_______________________________________________
art mailing list
art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/art
