Re: [urn] [art] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

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@jck.com> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>