From nobody Mon Jan 6 22:59:49 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C455F1200BA; Mon, 6 Jan 2020 22:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avWJNij_kYRR; Mon, 6 Jan 2020 22:57:42 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01A2120096; Mon, 6 Jan 2020 22:57:42 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ioio6-0005qR-CL; Tue, 07 Jan 2020 01:57:38 -0500 Date: Tue, 07 Jan 2020 01:57:32 -0500 From: John C Klensin To: iesg@ietf.org cc: art@ietf.org, mnot@mnot.net, ietf@ietf.org, urn@ietf.org Message-ID: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 06:57:49 -0000 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. From nobody Tue Jan 7 05:51:31 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF899120116; Tue, 7 Jan 2020 05:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9elndMSc72sa; Tue, 7 Jan 2020 05:51:13 -0800 (PST) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29FC1200E9; Tue, 7 Jan 2020 05:51:12 -0800 (PST) Received: by mail-ot1-f51.google.com with SMTP id r9so3138572otp.13; Tue, 07 Jan 2020 05:51:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eghn3hP3jtmuNjohEJYEDOQUrurtsHvXeadmEi9ViJk=; b=kDhYFbIrRTEL+r8iZ355Yyys/peGACUpVYr/gc5ukiCzV92hu8MdYzSV8Mj6Rs/8iW QK/VkkXoxE+4UoPTQZB7iTHHkVNVpp+ukc8u/QNFq9nxEOzXGzQmEDldIAcERpQRFt27 jS23ZL68xppbnn8WscAq7nCl3PutMUA34nwMQIR5Tv2X+GvN3Vr5yOHeES6b6K8AxPMn 2VVnFTPs5aZVPO4PhWT+c/6By6txn+2QJmsZ/8W1QmVSr4QcX2XkOza0joEcYa8k8ODh 0Jz/mUlyUVrza2brukgVbDchTyIvUuac9kzyriNJu3H3GHbYFbMlsTLRb4qyI13N2/40 sHzw== X-Gm-Message-State: APjAAAXKHEeythAjWkaM+ADxWUgoq/bllPce8HlCjyYp0TDFGviGnasA EKallDh1sQZ2+J72BSiQyyWszIapDbUjBeh3LUw= X-Google-Smtp-Source: APXvYqyl2MRtMbSQuAsXASaJwKEuBFtvuaxU0+2sUD7CKJe7T1Kd5/9xT3dKYXvJZb9t3JhNSVWshpd+vE+pOH1ojRk= X-Received: by 2002:a9d:7305:: with SMTP id e5mr116440368otk.64.1578405072086; Tue, 07 Jan 2020 05:51:12 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 08:51:00 -0500 Message-ID: To: John C Klensin Cc: The IESG , "General Area Review Team (gen-art@ietf.org)" , Mark Nottingham , urn@ietf.org, IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000a22c17059b8d11e6" Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 13:51:16 -0000 --000000000000a22c17059b8d11e6 Content-Type: text/plain; charset="UTF-8" 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 :// // 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 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 > --000000000000a22c17059b8d11e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I remain of the view that the URN/URL distinction is unhelpfu= l because it is meaningless. There are no sharp boundaries=C2=A0between cat= egories of identifier as the distinction supposes.

Before making this argument in more detail, I wil= l make a plea for respect. I find that the biggest obstacle to getting clar= ity on naming is that when faced with an analysis that contradicts deeply h= eld beliefs, the usual response is to tell people to 'do some research&= #39; or 'understand the issues'.

The URN/URI distinction does not in fact represent an essen= tial distinction between types identifiers as claimed. It describes a diffe= rence 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 i= s a purely conventional relationship.

2) IP addresses are also names

Again, the=C2=A0signifier bears no direct relation to = the signified. It is a purely conventional relationship.

3) File names are names

Again, the=C2=A0signifier bears no direct re= lation 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 intr= insic to the name itself, they are intrinsic to its mode of use.=C2=A0


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 (wi= th 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 bet= ween classes of name where there is none.


The only forms of network identifier that are not pure names are dat= a URIs and the ones that are indexical such as the ni: scheme described in = RFC6920.

But even that di= stinction can be bent. The strong Internet Names I propose here:
https://www.ietf.org/id/draft= -hallambaker-mesh-udf-08.html=C2=A0define a subset of DNS labels that a= re indexical rather than names. And those have some important and useful pr= operties. They allow the result of a trust decision to be encapsulated as a= n 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.=C2=A0 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.=C2=A0 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, Se= ction 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.=C2=A0 I believe it is=
possible to read this document in a way that has no impact on
URNs and URN namespaces.=C2=A0 =C2=A0However, 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.=C2=A0 Those ideas were deferred by the WG
for future work but the mechanisms may well be in use in
important URN namespaces.=C2=A0 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.=C2=A0 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.

=C2=A0thanks,
=C2=A0 =C2=A0john

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
--000000000000a22c17059b8d11e6-- From nobody Tue Jan 7 08:17:09 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5712011B; Tue, 7 Jan 2020 08:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awvczxoQv_1e; Tue, 7 Jan 2020 08:16:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E27512025D; Tue, 7 Jan 2020 08:15:43 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B32B3897A; Tue, 7 Jan 2020 11:15:22 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9864060A; Tue, 7 Jan 2020 11:15:42 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker cc: John C Klensin , "General Area Review Team \(gen-art\@ietf.org\)" , urn@ietf.org, The IESG , IETF Discussion Mailing List In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:16:42 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > 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. I agree with you. I think that we might have found new ways in which they are meaningfully distinct had to a uquitious way to resolve the more abstract URNs. That didn't happen, and I don't imagine that it is coming in the way envisioned. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4Urq4ACgkQgItw+93Q 3WWONgf8DeSN6pqvnrPmk6JBkccxZSOJo0qaGFxfwTLm37ssBZi2B0/wJTlqsLam DHobBseXAa9QIczNhhIraUBZ3o/cxlLj75MkyRiutga8olIFSdavmK8VOC7AcXY5 Q9j2DesWlYGW4rWABOmm3jyGFo9jGjmM4Q6cvrtveXCDcUGtg3WFaLJqjeHHBWVY nIwqBZSCgfy0Rg/XB/WpzDWB8QIm1g88HKCGvt8eSw6bQHLD/8vp1DImWe61ZrEt rjNRm8GpJ2xJt2552IUAz4GJyKkJ3FVUaG1cNGmyRCYGzpdnHmKPSkIi+FiQx2Jo +khrc3dQLwSYBsZ5Z0NDjIEb5NO7+g== =2Q2o -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 7 08:35:38 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96375120855; Tue, 7 Jan 2020 08:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d05P0sxs3B5X; Tue, 7 Jan 2020 08:35:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DFD120851; Tue, 7 Jan 2020 08:35:18 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 007GZEEY063997 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 7 Jan 2020 10:35:16 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578414917; bh=kh6+P4K8azbFqbi6ACYIBh3BOFCHbZc1rccEKnmGM0A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=TDf+0KU4w5wgOd6b0WPrKO0xIbU/DD0d7eEr+PG1cQXNYXNtUdCcFNV0jDgAL4De3 6KkWoZf38deb3FsVYydMxXdm3v4P/L1sUvue8E/836iG8eWgUW5TomcufbkQbPwzf0 2wHAQJpFo5KSt5gVTnAnXSOk5rPdChZKWXxRHE9I= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: John C Klensin , iesg@ietf.org Cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> From: Adam Roach Message-ID: Date: Tue, 7 Jan 2020 10:35:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [urn] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:35:28 -0000 To help with framing this conversation, the changes from RFC 7320 are highlighted here: https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03 I have some rather extensive thoughts on the process of creating bis documents [1]. While I'm not going to reiterate all of them here, I want to highlight a specific passage that seems to bear on John's comments: >    One major concern that drives these incremental document updates is >    that an attempt to republish an RFC as originally described in RFC >    2026 can result in such an effort being bogged down by issues that >    exist in text unrelated to the desired changes.  Such issues can >    arise from a change in the consensus of the IETF around best current >    practices, such as in the areas of security, privacy, or >    architectural design of an underlying protocol.  This complication >    arises from the fact that processing of an updated full version of an >    RFC is procedurally identical to processing of a green-field >    definition of a new protocol: review by the IETF at large, and review >    by the IESG, are performed on the entire document, leaving legacy >    text open to comments that will delay - and occasionally block - >    publication of such documents. /a ____ [1] https://tools.ietf.org/html/draft-roach-bis-documents-00 On 1/7/20 12:57 AM, John C Klensin 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. > From nobody Tue Jan 7 09:48:32 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A14A1200E9; Tue, 7 Jan 2020 09:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj02Aq8RDiIK; Tue, 7 Jan 2020 09:48:14 -0800 (PST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48E31200CC; Tue, 7 Jan 2020 09:48:14 -0800 (PST) Received: by mail-io1-f47.google.com with SMTP id h8so243535iob.2; Tue, 07 Jan 2020 09:48:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IuOpvnuUwP/KQ++zdKH6O9Dn1kirFI26FmD411J8kFo=; b=Mfw4ZjImsvORLT7oJY47TinaeoBE4xmWTTXxw9Ynel8EI0ijKfg2ZxlLgUC/HxaDW6 5FyPFryWTmLfQKP2szTM1OsSnaRv6csegUGgVzxg/tg0j6OySZndVf7DZG6xQrSecxjH ZeNDkNMAvSRlTbGZBjRpNdzfRzZpxJ8dOIetbxoO4NB0m7xw62+lArmJD5Q62YRUO+B8 F7rcmFmhDjE49xG7DzEPKwpQps++qVIuT0dvfzMTapLVpmABUnYDGEwftm/InEJZRGmt DkFDlZ2JSXlVVG5bwEkjenKYRI12UW/1voi5PLOy/bDDq9trr8CxE9EjE9nU2bVfuNoO bFTQ== X-Gm-Message-State: APjAAAXKyZ6zs5BAfpV/zXgWalNcry127VVhsoSq1Fa0Ep/kEbe/RYrJ c4wFvbGSnpqAchvsaTJysA3Y2M8QHzahKIjePaMEuA== X-Google-Smtp-Source: APXvYqz+iMHKRZ6cE/ZPkUmY/G7J7oTUieATdjzbRNz0GeAS2qd7qpmAN1yC/IUyviKzZwXXAF4nw+lZLuprGt/73V8= X-Received: by 2002:a5e:8417:: with SMTP id h23mr84197ioj.17.1578419293573; Tue, 07 Jan 2020 09:48:13 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> From: Barry Leiba Date: Tue, 7 Jan 2020 12:48:02 -0500 Message-ID: To: John C Klensin Cc: IESG , art@ietf.org, Mark Nottingham , urn@ietf.org, IETF discussion list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [urn] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 17:48:16 -0000 I think we need to tease apart two things in John's note: the URN scheme, and the concept of URNs as opposed to URLs, the two together forming what we call URIs. It's clear to me that BCP 190 has no actual effect on "urn:", because the things it talks about simply don't apply there, or are taken care of by the fact that URN namespaces are completely controlled by the owners of the namespaces. There is no internal hierarchy within URN namespaces unless the specification of the namespace creates one and defines how that hierarchy works and is managed. For the other part of the issue, I'm not fully in agreement with Phillip and Michael, in that I do think there's a useful distinction between a URI that names something without specifying how to locate it... and one that is a locator. There is, for example, a fundamental difference between, say, "http:" and "ni:" (see RFC 6920). That said, I also think that existing URI schemes that define *names* lack hierarchies, and are similarly not really affected by BCP 190. As I read through 7320bis and placed my "Yes" ballot, I didn't see anything, neither in the original text nor in the changed text, that made me question this, and as I look back through it now I still don't. So I don't have any concerns here. If anyone has something specific to raise, please raise it now, while the document is still in IESG Evaluation and we can more easily discuss it and make changes. Barry On Tue, Jan 7, 2020 at 1:58 AM John C Klensin 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. > From nobody Tue Jan 7 11:12:10 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40C61200FB; Tue, 7 Jan 2020 11:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z84cV2DVfgNG; Tue, 7 Jan 2020 11:11:52 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADFF1200FD; Tue, 7 Jan 2020 11:11:52 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1iouGZ-0008r3-9f; Tue, 07 Jan 2020 14:11:47 -0500 Date: Tue, 07 Jan 2020 14:11:40 -0500 From: John C Klensin To: Adam Roach , iesg@ietf.org cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org Message-ID: <444B2465A9B73F3D0DE59FFF@PSB> In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:11:55 -0000 --On Tuesday, January 7, 2020 10:35 -0600 Adam Roach wrote: > To help with framing this conversation, the changes from RFC > 7320 are highlighted here: >=20 > = https://www.ietf.org/rfcdiff?url1=3Drfc7320&url2=3Ddraft-nottingh= a > m-rfc7320bis-03 >=20 > I have some rather extensive thoughts on the process of > creating bis documents [1]. While I'm not going to reiterate > all of them here, I want to highlight a specific passage that > seems to bear on John's comments: >=20 >> =C2=A0=C2=A0 One major concern that drives these incremental = document >> updates is =C2=A0=C2=A0 that an attempt to republish an RFC = as >> originally described in RFC =C2=A0=C2=A0 2026 can result in = such an >> effort being bogged down by issues that =C2=A0=C2=A0 exist in = text >> unrelated to the desired changes.=C2=A0 Such issues can = =C2=A0=C2=A0 >> arise from a change in the consensus of the IETF around best >... Adam, I studied those comments when you first posted them. I believe that I sent comments at that time, but to summarize and highlight them in a shorter note, I see a key problem (and several others that may be less important and that were addressed in my earlier comments) with an replacement document that does not address all open issues in its predecessor: It leaves the reader with the understanding that the new document represents the IETF's best understanding of the topic covered (not merely a view of the most urgent problems to be fixed). Put differently, it implies that any issues not address are unimportant. That can be mitigated somewhat by including a section identifying known outstanding issues, but draft-nottingham-rfc7320bis-03 does not appear to contain such a section.=20 In addition, as your quoted comment above implies, an incremental document that nonetheless replaces an earlier one is a change to what 2026 specifies. I do not believe it is appropriate to change the procedures of 2026 by ignoring it, nor do I believe that examples of its being ignored in the past constitute justification for ignoring it in the future. Just as we tried to do with NEWTRK and ISDs (arguably a different approach to at least part of the problem you are trying to address), a change to how we handle replacement documents that ignores (if nothing else) 2026's "no known defects" rule requires an update or other change to 2026 before the desired approach is appealed to in order to justify a particular document. That, and my p.s., aside, I had hoped my note would rather carefully avoid dragging us back into either this issue or the ones raised by Phillip and Barry (like Barry, I don't fully agree with the former). It seems to me that both that comment and part of Barry's raise fundamental questions about how RFC3986 is defined and what it specifies. Those issues are probably best addressed at another time. =20 Instead, I was trying to raise a far more narrow question: Given that RFC 3986 separates names and locators and that we have already had confusion about what is appropriate in URNs based on the language there, does this document make things worse? I think it may. Even a statement fragment (from the first paragraph of Section 3 and inherited from 7320) like "...as links that are exchanged as part of the protocol, rather than statically specified syntax" are inconsistent with the use of keyword values in some URN namespaces as static indicators. If you want to ask the slightly different question of whether, if RFC 7320 made things worse, does this I-D make things even worse than that, I don't have an easy answer except to note at least one example: The last paragraph of Section 2.3, which appears to be new, says > Extensions MUST NOT define a structure within individual URI > components (e.g., a prefix or suffix), again to avoid > collisions and erroneous client assumptions. But, as I understand that rule, it is precisely what some rules, and provisions for namespace-specific rules, in RFC 8141, do. Again, the solution at this point appears to be either to be much more careful about binding the statements in the I-D to the concept of ownership or to indication that this specification does not apply to URNs (or, if preferred, to what 3986 describes as "name" URIs) at all. best, john From nobody Tue Jan 7 11:53:57 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA81200FD; Tue, 7 Jan 2020 11:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxQRab6X6ZKR; Tue, 7 Jan 2020 11:53:53 -0800 (PST) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E27D1200B3; Tue, 7 Jan 2020 11:53:53 -0800 (PST) Received: by mail-oi1-f179.google.com with SMTP id p67so498786oib.13; Tue, 07 Jan 2020 11:53:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ibvo7OmV9+zNwjb1AHdIT1vKqOZQ/LoeRVExlz19n8A=; b=m1eKD0DimMFXqj4PPYNigVO2KLLhsOBcW3N5+HschzBt+d9XjpTKCZ/Pinkv2KhwI6 /729Vyj9Ypp8nKx39lxkkD7U/6zh2JzQMBRHfbhi1lQotksNohLdUoc7K88OuYM1pfV0 i/PcO0X9FqdyPGze2jdPj9SbTRie5igCxN5dikPihXBTVFxhXQXdkgTY9SW7cUZQeqs6 5VLE2ipuU/9W/b3KGvHBNje5cb4P27TSO7e0iXGJ32U8HsMcv73sgPPcgc+vGKgVclc6 lPDRz9EhRrdsL+2vGi21eDGUIlye82PLhiQi45GD/+YzRhhz2IUb5Vw8yWrGrD5nvXAg qz7Q== X-Gm-Message-State: APjAAAVLkUtD/oWlIfGNatz89g9iIJD+2cQYUSWADx6ep60Oae18a7w9 1phCnNwm4cpfsmYDFX9ioIKNriKUYWtF/vQFNKzbQ38td/U= X-Google-Smtp-Source: APXvYqxvdqhMzuAeUM4BwZOAH1pf43T/A6RUak2okFVC3rLZ+5z6tKjB5FKIzUkgspI3SuwGkc7UO64MnMwpg2rrT1s= X-Received: by 2002:a54:4f04:: with SMTP id e4mr48512oiy.111.1578426832209; Tue, 07 Jan 2020 11:53:52 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> <29803.1578413742@localhost> In-Reply-To: <29803.1578413742@localhost> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 14:53:43 -0500 Message-ID: To: Michael Richardson Cc: John C Klensin , "General Area Review Team (gen-art@ietf.org)" , urn@ietf.org, The IESG , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000a3494a059b922212" Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:53:55 -0000 --000000000000a3494a059b922212 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 12:48 PM Barry Leiba wrote: > For the other part of the issue, I'm not fully in agreement with > Phillip and Michael, in that I do think there's a useful distinction > between a URI that names something without specifying how to locate > it... and one that is a locator. There is, for example, a fundamental > difference between, say, "http:" and "ni:" (see RFC 6920). That is precisely what I was talking about when I said that ni: is indexical. But that is no longer an essential distinction either. We can distinguish names that are under IANA authority (DNS, IP) from those that are not. But that is the limit of it. Given that it was announced today that SHA-1 was broken, lets take another look at a SIN: alice@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com That is a valid email address. It can be routed on the Internet (not the best privacy choice but possible). But it is a name that can be bound to a security policy. So if mb2gk-6duf5-ygyyl-jny5e-rwshz is the UDF (SHA-2-512) of Alice's OpenPGP encryption key. We have an implicit semantic here: Encrypt all mail sent to this address with the key that has fingerprint mb2gk-6duf5-ygyyl-jny5e-rwshz The reason that I have hammered on the fact that the name/locator distinction being bogus is precisely because the obsession with defining a distinction where there is NO difference has caused the neglect of a situation where there is a very real and important one. https://www.ietf.org/id/draft-hallambaker-mesh-udf-08.html#name-secure-internet-names A Strong Internet Name allows ANY URI with a DNS component to be turned On Tue, Jan 7, 2020 at 11:15 AM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > 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. > > I agree with you. > > I think that we might have found new ways in which they are meaningfully > distinct had to a uquitious way to resolve the more abstract URNs. > That didn't happen, and I don't imagine that it is coming in the way > envisioned. > HTTPs are names but they are a name that embodies a (fairly) unambiguous means of location. Having had the misfortune to engage in discussion with acolytes of a prominent opponent of post-modernism, I have been writing a defense of postmodernism today. One of the chief arguments made by the postmodernists is that perfect knowledge is an illusion. And I think that is a profound observation that is essential to understanding why the original concept of URNs and for that matter most registration schemes are doomed to fail. The Web succeeded because of 404 Not Found. The links are scruffy. And that is fine if you are OK with the idea that knowledge can be scruffy, that it will never be perfect. And that is why the Web came out of CERN because (good) scientists understand that there is no absolute knowledge and that what we are arriving at is a better approximation to the truth, not the truth itself. There have been plenty of people making that type of argument since ancient times. But until the mid 80s, most scientists had a very rigid epistemology that was essentially Victorian in its outlook. Scientists were serious people who were finding out profound and universal truths and we had all be very very careful not to make mistakes because that 'would be bad'. I would encourage people to take a look at what research scientists in their 20s and 30s are saying about their approach to science. They are utterly rejecting that view. What politicians now call 'Western values' and demand other countries observe is a modern construct that is fifty years (racial tolerance) old at most. In some areas, what is now the fixed consensus is less than a decade old (evolve already). The reason we have the nonsense of .com, .org, .net etc is because DNS was designed by people who had an essentially Victorian view of epistemology in which taxonomy represents essential qualities. (Whether the same is true of the extension TLDs I will leave aside) The reason I and others received (and continue to receive from some) the patronizing responses we do (do some research you ignorant baboon! you don't understand) is that we have profoundly different and fundamentally incompatible epistemologies and some people regard mine as heresy. Both are capable of self examination. But mine is capable of examining theirs, they can only reject mine. So its like me trying to explain complex numbers to someone who insists that you can't take the square root of a negative number and can't get past that. The route out of formal methods to PoMo is that to solve the problems we faced in the 1980s in formal methods, it was necessary to apply meta-mathematics and understand the limitations of logic. And once you do that you are in Post Modernism. So the URN notion that we must carefully decide how to resolve before we defined schemes was wrong. It was and is much more important to have a catalog that is as *complete *as possible than for the entries to be *correct*. Resolution of many types of name is inherently ambiguous because the context varies. We cannot resolve a barcode on a physical object like a can of beans. But we can ask for information on the can of beans and we can order an instance of the can of beans for delivery. And both forms of 'location' are going to be subjective and depend on the context in which they are attempted. --000000000000a3494a059b922212 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 7, 2020 at 12:48 PM Barry Leiba= <barryleiba@computer.org= > wrote:=C2=A0=C2=A0
For the other part of th= e issue, I'm not fully in agreement with
Phillip and Michael, in tha= t I do think there's a useful distinction
between a URI that names s= omething without specifying how to locate
it... and one that is a locato= r.=C2=A0 There is, for example, a fundamental
difference between, say, "http:" and "ni:" (see RFC 692= 0).=C2=A0=C2=A0

Tha= t is precisely what I was talking about when I said that ni: is indexical. = But that is no longer an essential distinction either.

We can distinguish nam= es that are under IANA authority (DNS, IP) from those that are not. But tha= t is the limit of it.


Given that it wa= s announced today that SHA-1 was broken, lets take another look at a SIN:

That is a valid email address. It = can be routed on the Internet (not the best privacy choice but possible). B= ut it is a name that can be bound to a security policy.

So if=C2=A0 mb2gk-6duf5-ygyyl-jny5e-rwshz is the UDF (SHA-2-512) of Alice's OpenPGP= encryption key. We have an implicit semantic here: Encrypt all mail sent t= o this address with the key that has fingerprint mb2gk-6duf5-ygyyl-jny5e-rw= shz

The reason that I have hammered on the fact that the name/locator distinct= ion being bogus is precisely because the obsession with defining a distinct= ion where there is NO difference has caused the neglect of a situation wher= e there is a very real and important one.


A Strong Internet Name allows ANY URI with a DNS component = to be turned



=
On Tue, Jan 7, 2020 at 11:15 AM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Phillip Hallam-Baker <ietf@hallambaker.com> wrote:
=C2=A0 =C2=A0 > I remain of the view that the URN/URL distinction is unh= elpful because it is
=C2=A0 =C2=A0 > meaningless. There are no sharp boundaries between categ= ories of identifier
=C2=A0 =C2=A0 > as the distinction supposes.

=C2=A0 =C2=A0 > Before making this argument in more detail, I will make = a plea for respect. I
=C2=A0 =C2=A0 > find that the biggest obstacle to getting clarity on nam= ing is that when
=C2=A0 =C2=A0 > faced with an analysis that contradicts deeply held beli= efs, the usual
=C2=A0 =C2=A0 > response is to tell people to 'do some research'= or 'understand the issues'.

=C2=A0 =C2=A0 > The URN/URI distinction does not in fact represent an es= sential distinction
=C2=A0 =C2=A0 > between types identifiers as claimed. It describes a dif= ference in source of
=C2=A0 =C2=A0 > authority at best, not an essential property.

I agree with you.

I think that we might have found new ways in which they are meaningfully distinct had to a uquitious way to resolve the more abstract URNs.
That didn't happen, and I don't imagine that it is coming in the wa= y envisioned.

HTTPs are names but they are a name that embo= dies a (fairly) unambiguous means of location.

Having had the misfortune to engage in discussion wit= h acolytes of a prominent opponent of post-modernism, I have been writing a= defense of postmodernism today. One of the chief arguments made by the pos= tmodernists is that perfect knowledge is an illusion. And I think that is a= profound observation that is essential to understanding why the original c= oncept of URNs and for that matter most registration schemes are doomed to = fail.

The Web succeeded b= ecause of 404 Not Found. The links are scruffy. And that is fine if you are= OK with the idea that knowledge can be scruffy, that it will never be perf= ect. And that is why the Web came out of CERN because (good) scientists und= erstand that there is no absolute knowledge and that what we are arriving a= t is a better approximation to the truth, not the truth itself.=C2=A0
=

There have been plenty of peop= le making that type of argument since ancient times. But until the mid 80s,= most scientists had a very rigid epistemology that was essentially Victori= an in its outlook. Scientists were serious people who were finding out prof= ound and universal truths and we had all be very very careful not to make m= istakes because that 'would be bad'.

I would encourage people to take a look at what resear= ch scientists in their 20s and 30s are saying about their approach to scien= ce. They are utterly rejecting that view.

What politicians now call 'Western values' and= demand other countries observe is a modern construct that is fifty years (= racial tolerance) old at most. In some areas, what is now the fixed consens= us is less than a decade old (evolve already). The reason we have the nonse= nse of .com, .org, .net etc is because DNS was designed by people who had a= n essentially Victorian view of epistemology in which taxonomy represents e= ssential qualities. (Whether the same is true of the extension TLDs I will = leave aside)
The reason I= and others received (and continue to receive from some) the patronizing re= sponses we do (do some research you ignorant baboon! you don't understa= nd) is that we have profoundly different and fundamentally incompatible epi= stemologies and some people regard mine as heresy. Both are capable of self= examination. But mine is capable of examining theirs, they can only reject= mine. So its like me trying to explain complex numbers to someone who insi= sts that you can't take the square root of a negative number and can= 9;t get past that.

The ro= ute out of formal methods to PoMo is that to solve the problems we faced in= the 1980s in formal methods, it was necessary to apply meta-mathematics an= d understand the limitations of logic. And once you do that you are in Post= Modernism.


So the URN notion that we must carefully decide how to resolve befo= re we defined schemes was wrong. It was and is much more important to have = a catalog that is as complete as possible than for the entries to be= correct.

Resoluti= on of many types of name is inherently ambiguous because the context varies= . We cannot resolve a barcode on a physical object like a can of beans. But= we can ask for information on the can of beans and we can order an instanc= e of the can of beans for delivery. And both forms of 'location' ar= e going to be subjective and depend on the context in which they are attemp= ted.
--000000000000a3494a059b922212-- From nobody Tue Jan 7 14:49:55 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAC512085F; Tue, 7 Jan 2020 14:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=firsthand.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc9Y9WfyBA1W; Tue, 7 Jan 2020 14:49:34 -0800 (PST) Received: from tranquility.default.cdelarrinaga.uk0.bigv.io (tranquility.default.cdelarrinaga.uk0.bigv.io [IPv6:2001:41c8:51:8b8::184]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A66120843; Tue, 7 Jan 2020 14:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=firsthand.net; s=tranquility; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=l3BqeZDh4QF5H1jBkVTSzGJNkwQgCM6w9+2U9m8feTo=; b=S0/Ei+GGCl87tWLGc61z8D2CKw/PSFmcPDm2dKkUND1gfQVpSq+zjDZwVO/1dZ6dDvKZ407YoMeUV21tKIaS+gIgJqPOu5tTn/39h6cvVVqIDv2MzgfH9rn6KbDvfEKQjN7MItMPCXz81ohxFZRoSe+p4jpvRm0hZGm/s1V3X00=; Received: from 188.29.164.240.threembb.co.uk ([188.29.164.240] helo=[192.168.43.165]) by tranquility.default.cdelarrinaga.uk0.bigv.io with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ioxfH-0007Uo-B5; Tue, 07 Jan 2020 22:49:31 +0000 To: Phillip Hallam-Baker Cc: "General Area Review Team (gen-art@ietf.org)" , urn@ietf.org, The IESG , IETF Discussion Mailing List References: <87E116C31DAF1434C3C3937F@PSB> <29803.1578413742@localhost> From: Christian Message-ID: <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net> Date: Tue, 7 Jan 2020 22:49:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------279B353DDDBD3A4C1F8B6BB7" Content-Language: en-US Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 22:49:39 -0000 This is a multi-part message in MIME format. --------------279B353DDDBD3A4C1F8B6BB7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit picking up as a post modern fag end... On 07/01/2020 19:53, Phillip Hallam-Baker wrote: > Resolution of many types of name is inherently ambiguous because the > context varies.. We cannot resolve a barcode on a physical object like > a can of beans. But we can ask for information on the can of beans and > we can order an instance of the can of beans for delivery. And both > forms of 'location' are going to be subjective and depend on the > context in which they are attempted. I suppose the question is can a schema capture both identifier and locator contexts (my plural) unambiguously in all cases? Should I take your post modernist interpretation as saying the answer is no - we have to live with ambiguity, even to the extent of the failure to resolve one or other or possibly both and do so without breaking wind? But given this interpretation what language is needed if URI and URN linguistically don't meet the need? Or is the other interpretation to offer a list of contexts that work and exclude application for the others? In which case which is the more useful approach for building real world apps and their networks? It rather kills the idea of hard coded registries for all eventualities I think. That I like. As I really like the import of post modernist sensibility. This argument is worth something. best Christian --------------279B353DDDBD3A4C1F8B6BB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

picking up as a post modern fag end...

On 07/01/2020 19:53, Phillip Hallam-Baker wrote:
Resolution of many types of name is inherently ambiguous because the context varies.. We cannot resolve a barcode on a physical object like a can of beans. But we can ask for information on the can of beans and we can order an instance of the can of beans for delivery. And both forms of 'location' are going to be subjective and depend on the context in which they are attempted.

I suppose the question is can a schema capture both identifier and locator contexts (my plural) unambiguously in all cases?

Should I take your post modernist interpretation as saying the answer is no - we have to live with ambiguity, even to the extent of the failure to resolve one or other or possibly both and do so without breaking wind?

But given this interpretation what language is needed if URI and URN linguistically don't meet the need? 

Or is the other interpretation to offer a list of contexts that work and exclude application for the others?

In which case which is the more useful approach for building real world apps and their networks? 

It rather kills the idea of hard coded registries for all eventualities I think. That I like. As I really like the import of post modernist sensibility. This argument is worth something.

best Christian

--------------279B353DDDBD3A4C1F8B6BB7-- From nobody Tue Jan 7 15:50:50 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F530120220; Tue, 7 Jan 2020 15:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-p5R1erC1Db; Tue, 7 Jan 2020 15:50:46 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DDF12013C; Tue, 7 Jan 2020 15:50:46 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id n59so264243pjb.1; Tue, 07 Jan 2020 15:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=DiIo7NMrRDey82VslgS7RqWDOXU/ANdYEskZ4LE+xj0=; b=WgdE6q9IrMy8uh5DxP9/FsDDSoq/T72KU4is7umg1DViJ31ObwQPtpRVPskknNEF7Y NZcaXMRty5Tc8T1Ot5G8ze6il1LJtW68qvCY3c8Md38yME+iuw/TZ8XSQcJabHAcG8Xy MgHeB3axrUwdfvTu7QauiJ/+S3sdlmka/wi1cRpiXFYsQ29541XhGSY29kYZbEOTKyLF d6mhywywHHhPc9muIAbOGuDbxP0SFjvQtH62+7H005uephMYlWm9ySk3QjDWh2ST8Pg2 odzMWZto7nWDRxPILzhIZ+rUlq5uLg1ZDVBISGrNE21YFPGyKDO643BijwRs6ldLrilX zH5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=DiIo7NMrRDey82VslgS7RqWDOXU/ANdYEskZ4LE+xj0=; b=Updw1r5zGrR87yCXikt6KL9LAr68IQttyM1BxfHCblrbgIj5Rmc3MB3B/xOnAmvNVs IvdZ9V0bApTkrv6dRL9F77I4rx3HAHU6LSDcDPB1nkXJXvijpzW7BcBrXOEPMFxh5CXd GOz1lFwFZze5J4VuKHFSQgsa7rq8EsUdI/QsP+2ZgYlsZf9gTERl9U8v+xHc/SHVfqQU 6gRFSKf+3WA1cSqmlMjxT4sh7PEvke0ZvGET1ROh61AarN1XpFoCi+em9jrEHTk7N50z mj6OdVLYJmb7a+Kvd7C2+QspFOYVLqZsmwSvbObrW1bBxaQFzMGykCsk0ScM2kogoC9Y treQ== X-Gm-Message-State: APjAAAV30FDSf/EXqJ0c8UFCnT1RfbKkJM/hE55ErjB8nq687E6xT0hr uqMdKx1wRlLKqRCo/7SjN/DnDt1HOUc= X-Google-Smtp-Source: APXvYqwrP37wxzxYz1LLUlfLGi4QxfZPqL6XKJy/rpg9P9VJKkljSnwBKAxlfws0HiZpqMe89qMBgQ== X-Received: by 2002:a17:902:b691:: with SMTP id c17mr2370243pls.254.1578441046082; Tue, 07 Jan 2020 15:50:46 -0800 (PST) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id n2sm832253pgn.71.2020.01.07.15.50.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 15:50:45 -0800 (PST) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'John C Klensin'" , "'Adam Roach'" , Cc: , , , References: <87E116C31DAF1434C3C3937F@PSB> <444B2465A9B73F3D0DE59FFF@PSB> In-Reply-To: <444B2465A9B73F3D0DE59FFF@PSB> Date: Tue, 7 Jan 2020 15:50:43 -0800 Message-ID: <002b01d5c5b5$47227290$d56757b0$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHlIqFVvsYjY3mX8ZSjZXIfuJ5VFQIu5gyCAc3WKQanoPwSoA== Content-Language: en-us Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 23:50:48 -0000 FWIW, while I agree with the "spirit of making this BCP guidance, rather than rules", I don't see how changing "MAY" to "can" or a "SHOULD NOT... but instead" to "are encouraged to" is helpful (substituting terms that are well-defined with words that seem to be similar in meaning but less well-defined. The keywords MAY, SHOULD, SHOULD NOT seem to me to be sufficient "guidance" in a BCP-status document. Perhaps it would be helpful to add a kind of applicability statement at the beginning that these guidelines are intended to apply to "http:" and "https:" URIs and those with similar patterns and SHOULD be considered for others, although they don't seem to be relevant for URI-schemes that don't use the generic syntax with hierarchical paths (such as "urn:" or "data:" or "mailto") There is no need to consider the philosophic difference between a name and a locator. It's a matter of choosing a syntax for serialization of a data structure and the implication of ownership and origin that comes with some syntactic arrangements for some implementations. Larry -- https://LarryMasinter.net From nobody Tue Jan 7 16:19:00 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018CF120020; Tue, 7 Jan 2020 16:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eprzhI2QcRT4; Tue, 7 Jan 2020 16:18:43 -0800 (PST) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D21120018; Tue, 7 Jan 2020 16:18:43 -0800 (PST) Received: by mail-ot1-f45.google.com with SMTP id w21so1872110otj.7; Tue, 07 Jan 2020 16:18:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KsVsYPYLQE+I76X+hyia3u6/V4SaimYB4tgvgMkBFIg=; b=s+TzLfuLp7ERgKo6bxXmImLC7XCUPicw5hMjoYj8QqSj3WtSmruBY0PuyFd5aPFG3x tB7agE5NCN9yIWMcjYOcRbcq01khCR24F0ugOun+qsJmbbTgOKb2Qe6mPUHqFVI/2vkt RH+rivCqR3v78mTyE+lUWqXPxLhyk3b8i681vXQgxqxFMATGBcbaOyTyFUBlaDmbUNGM w+BjKyhzzogLCuyfkjVnTbsgbomqD9HM3x8Bt7qzagRna8F+7EbOTBaS/ArWXN4TbKTX zhlL7TyAUzdRNq6lO4faGFk8GCizKbGf5WTuLqpZRBXleSIj+PPMM5RjNOzPPLn4JYvv kamw== X-Gm-Message-State: APjAAAWozV0ABXK6gVh5QPJOv806qUiYx66ZqvSnLLh/oh4470TRVloF hSeaCxjnntP4n9dQ5vOqzPwJdTMQ95MlL1jL256H/D+K X-Google-Smtp-Source: APXvYqzK9pkdVgjhJ5NhspvQeo4oZHQcUrAy9DpjYmbl15A2HT0wXtwWMS5yCwjuu/1SBh5Cw0i07RRxjOsm67x+oNc= X-Received: by 2002:a05:6830:1481:: with SMTP id s1mr2229466otq.66.1578442722735; Tue, 07 Jan 2020 16:18:42 -0800 (PST) MIME-Version: 1.0 References: <87E116C31DAF1434C3C3937F@PSB> <29803.1578413742@localhost> <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net> In-Reply-To: <86e1f21b-b594-b390-fe67-c5f495cffa64@firsthand.net> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 19:18:31 -0500 Message-ID: To: Christian Cc: "General Area Review Team (gen-art@ietf.org)" , urn@ietf.org, The IESG , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000c97be0059b95d5ad" Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:18:45 -0000 --000000000000c97be0059b95d5ad Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 5:49 PM Christian wrote: > picking up as a post modern fag end... > On 07/01/2020 19:53, Phillip Hallam-Baker wrote: > > Resolution of many types of name is inherently ambiguous because the > context varies.. We cannot resolve a barcode on a physical object like a > can of beans. But we can ask for information on the can of beans and we can > order an instance of the can of beans for delivery. And both forms of > 'location' are going to be subjective and depend on the context in which > they are attempted. > > I suppose the question is can a schema capture both identifier and locator > contexts (my plural) unambiguously in all cases? > Definitely not because the identifier interpretation can change over time. Additional contexts can be added. The identifier may be grandfathered into a new scheme. It may be abandoned. > Should I take your post modernist interpretation as saying the answer is > no - we have to live with ambiguity, even to the extent of the failure to > resolve one or other or possibly both and do so without breaking wind? > We can deny that the ambiguity exists. We can say the earth is flat as well. But it won't change anything. > But given this interpretation what language is needed if URI and URN > linguistically don't meet the need? > > Or is the other interpretation to offer a list of contexts that work and > exclude application for the others? > > In which case which is the more useful approach for building real world > apps and their networks? > I believe that the Internet was founded on the principle of allowing every user to experiment and to extend. It is thus impossible to enumerate all possible uses. It is however possible to identify uses that are useful generally and network effects strongly (unfortunately too strongly) encourage focusing on common uses. > It rather kills the idea of hard coded registries for all eventualities I > think. That I like. As I really like the import of post modernist > sensibility. This argument is worth something. > > best Christian > --000000000000c97be0059b95d5ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 7, 2020 at 5:49 PM Christian <cdel@firsthand.net> wrote:
=
=20 =20 =20

picking up as a post modern fag end...

On 07/01/2020 19:53, Phillip Hallam-Baker wrote:
Resolution of many types of name is inherently ambiguous because the context varies.. We cannot resolve a barcode on a physical object like a can of beans. But we can ask for information on the can of beans and we can order an instance of the can of beans for delivery. And both forms of 'location= 9; are going to be subjective and depend on the context in which they are attempted.

I suppose the question is can a schema capture both identifier and locator contexts (my plural) unambiguously in all cases?

D= efinitely not because the identifier interpretation can change over time. A= dditional contexts can be added. The identifier may be grandfathered into a= new scheme. It may be abandoned.

Should I take your post modernist interpretation as saying the answer is no - we have to live with ambiguity, even to the extent of the failure to resolve one or other or possibly both and do so without breaking wind?

We can deny that the ambiguity exists. = We can say the earth is flat as well. But it won't change anything.=C2= =A0

But given this interpretation what language is needed if URI and URN linguistically don't meet the need?=C2=A0

Or is the other interpretation to offer a list of contexts that work and exclude application for the others?

In which case which is the more useful approach for building real world apps and their networks?=C2=A0

I believe that the Intern= et was founded on the principle of allowing every user to experiment and to= extend. It is thus impossible to enumerate all possible uses. It is howeve= r possible to identify uses that are useful generally and network effects s= trongly (unfortunately too strongly) encourage focusing on common uses.

It rather kills the idea of hard coded registries for all eventualities I think. That I like. As I really like the import of post modernist sensibility. This argument is worth something.

best Christian

--000000000000c97be0059b95d5ad-- From nobody Tue Jan 7 16:31:20 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBE5120077 for ; Tue, 7 Jan 2020 16:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK5MJLTW3gMi for ; Tue, 7 Jan 2020 16:31:03 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8BB12007C for ; Tue, 7 Jan 2020 16:31:03 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id k24so1343604ioc.4 for ; Tue, 07 Jan 2020 16:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GEmqktg5R6YlC/lTNgD0xWDOxoKsEXTtJtguhv3Lphg=; b=M23p7xZoHcSzvfaRoMklcm2lLX0MJFarEppfvTJNEWiOAxazkqK4PGFCS6AgWjzb18 uvI67mwhOxx8dSuq4Waz+6TmMZO7N8U8C5Xbw24hyPoKedu6PuAKeNmRrnhDb3RgZHnK y1lfDuoAsp1IIVESUO64sKovA74fdZKx13630= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GEmqktg5R6YlC/lTNgD0xWDOxoKsEXTtJtguhv3Lphg=; b=JbkYDNHlbXwWuySB7Tp7Pzxgt3ALWz0HQsVimRssHDIKR8i+B6oWQp6Y4HM9gsuw+a MW+mVNWuCDYNF/dycjroT0b0cnBMJ2CnsjQHGlXbX3KS2W9tCSFFJ5VCYNEIOpB9WgA/ mPeqZprY+P4OnkS04ZCh7t8nCkmEBwBbIWD3f59nxxdo0dUdbC3KzCWgV03yNAKMbq3/ pXHTq2o7eDqH5OyTC7Aio21JWjEI9gMGtQuaqJmZMbWZeChWZ+rzxUrmawoYFe6RJIPP G+4walqsAflMAhyQ7qPGiYwMsD/pHbSfPDmf2Y2d0V3XCO3MFIMD9tWJZZ2Ymtw1zEZk 4mUA== X-Gm-Message-State: APjAAAWejPcsQl7qnCHUL3SKLBpapw6IgWBTGU1DI2qrGjQJXvwxxjd/ Awwai7rqcHO3oGYHTYdm1AAZMw== X-Google-Smtp-Source: APXvYqzp5quT3VRoz26zX84/B/mFs8sjjqA3VG/HXAi+dXbzPNFii9KHriFxYRUZGvd25w1XJ4DJ+w== X-Received: by 2002:a5d:8901:: with SMTP id b1mr1304834ion.246.1578443462391; Tue, 07 Jan 2020 16:31:02 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id y18sm393992ilm.9.2020.01.07.16.31.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 16:31:01 -0800 (PST) To: John C Klensin , Adam Roach , iesg@ietf.org Cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org References: <87E116C31DAF1434C3C3937F@PSB> <444B2465A9B73F3D0DE59FFF@PSB> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Tue, 7 Jan 2020 17:31:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <444B2465A9B73F3D0DE59FFF@PSB> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:31:06 -0000 On 1/7/20 12:11 PM, John C Klensin wrote: > Instead, I was trying to raise a far more narrow question: Given > that RFC 3986 separates names and locators and that we have > already had confusion about what is appropriate in URNs based on > the language there, does this document make things worse? I > think it may. Even a statement fragment (from the first > paragraph of Section 3 and inherited from 7320) like "...as > links that are exchanged as part of the protocol, rather than > statically specified syntax" are inconsistent with the use of > keyword values in some URN namespaces as static indicators. Indeed, it's not immediately obvious what a "protocol" would be in the case of many URN namespaces, precisely because the URN is a name rather than a locator. > If > you want to ask the slightly different question of whether, if > RFC 7320 made things worse, does this I-D make things even worse > than that, I don't have an easy answer except to note at least > one example: The last paragraph of Section 2.3, which appears to > be new, says > >> Extensions MUST NOT define a structure within individual URI >> components (e.g., a prefix or suffix), again to avoid >> collisions and erroneous client assumptions. > > But, as I understand that rule, it is precisely what some rules, > and provisions for namespace-specific rules, in RFC 8141, do. It's not clear to me whether a URN namespace counts as a 7320bis protocol extension (which can "offer new capabilities that could apply to any identifier, or to a large subset of possible identifiers"); however a definition of, say, URN r-components would probably fit the bill, and such a definition might well define structures that would violate the aforementioned MUST NOT. > Again, the solution at this point appears to be either to be > much more careful about binding the statements in the I-D to the > concept of ownership or to indication that this specification > does not apply to URNs (or, if preferred, to what 3986 describes > as "name" URIs) at all. That might be the best approach. Peter From nobody Tue Jan 7 21:09:04 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E20120041; Tue, 7 Jan 2020 21:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwM6zHv61ByI; Tue, 7 Jan 2020 21:08:47 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA8B120025; Tue, 7 Jan 2020 21:08:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ip3aC-000A6x-Tu; Wed, 08 Jan 2020 00:08:40 -0500 Date: Wed, 08 Jan 2020 00:08:34 -0500 From: John C Klensin To: Peter Saint-Andre , Adam Roach , iesg@ietf.org cc: art@ietf.org, mnot@mnot.net, urn@ietf.org, ietf@ietf.org Message-ID: <83F6216862324B84D43C9280@PSB> In-Reply-To: References: <87E116C31DAF1434C3C3937F@PSB> <444B2465A9B73F3D0DE59FFF@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 05:08:50 -0000 --On Tuesday, January 7, 2020 17:31 -0700 Peter Saint-Andre wrote: >... >> If >> you want to ask the slightly different question of whether, if >> RFC 7320 made things worse, does this I-D make things even >> worse than that, I don't have an easy answer except to note >> at least one example: The last paragraph of Section 2.3, >> which appears to be new, says >> >>> Extensions MUST NOT define a structure within individual URI >>> components (e.g., a prefix or suffix), again to avoid >>> collisions and erroneous client assumptions. >> >> But, as I understand that rule, it is precisely what some >> rules, and provisions for namespace-specific rules, in RFC >> 8141, do. > > It's not clear to me whether a URN namespace counts as a > 7320bis protocol extension (which can "offer new capabilities > that could apply to any identifier, or to a large subset of > possible identifiers"); however a definition of, say, URN > r-components would probably fit the bill, and such a > definition might well define structures that would violate the > aforementioned MUST NOT. I was trying to avoid getting dragged down into details, both in the hope of keeping the message as short as possible and to avoid a distracting side-discussion, but, yes r-components and the issues associated with pass-through information for those URN namespaces that resolve to one or more URLs were examples that crossed my mind. >> Again, the solution at this point appears to be either to be >> much more careful about binding the statements in the I-D to >> the concept of ownership or to indication that this >> specification does not apply to URNs (or, if preferred, to >> what 3986 describes as "name" URIs) at all. > > That might be the best approach. If we don't want both the discussion and the document to drag out, I believe so. best, john From nobody Wed Jan 8 19:47:49 2020 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F45120020 for ; Wed, 8 Jan 2020 19:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aePEao62Q5md for ; Wed, 8 Jan 2020 19:47:38 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F710120108 for ; Wed, 8 Jan 2020 19:47:38 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id pOCZiLxu00LOmpOnJihLCU; Thu, 09 Jan 2020 03:47:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1578541657; bh=LIk+nGUmj9dsh+ZllqFYe2TKFOBNhhqyibgS4JuJ380=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=KtBSqE7P6oIHwAPzpTfou0HVGqIUDVR7Hmnq7eoBbdKXm//V8oLPej6aF0pirHR5L WxPM6AR0ti7c36LSp1g4Bpb7rGGl+ata1XuBMEFjVYWswtUNED0INuMeZcm3f9+De5 LYX8NjWwRNCSV+vhZDxpVH48Q5+hn3GxoyFUUokOy2lEoj5l0/PPWiNIiGFpMXIyVG 0T7In1B6T1ZEzrlFtsxFCc/cyK9zv642B8DIgl2KWf8FJebW37azRwSWH20JaeNtLs X1XONRIqWBeFdZG0G1oAvrLZn76h5zkrNsOmNnfvEul33C7j3kd9N+8x+AZy/UijeL P95E0Cz2NoUDA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:1e00:222:fbff:fe91:d396]) by resomta-ch2-08v.sys.comcast.net with ESMTPA id pOnHim3Bday2upOnIiO4Wu; Thu, 09 Jan 2020 03:47:36 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0093lY5M014578; Wed, 8 Jan 2020 22:47:34 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0093lYv6014573; Wed, 8 Jan 2020 22:47:34 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: art@ietf.org, mnot@mnot.net, urn@ietf.org In-Reply-To: <87E116C31DAF1434C3C3937F@PSB> (john-ietf@jck.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Jan 2020 22:47:33 -0500 Message-ID: <874kx58f56.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [urn] [art] URNs and Last Call: (URI Design and Ownership) to Best Current Practice X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 03:47:43 -0000 I am surprised to read a document that is marked "best current practice" but filled with MUST and MUST NOT specifications. I expect "best current practice" to be advisory. However, perhaps I am not understanding the IETF use of BCP. But this document does claim the right to override any existing RFC, which seems to be excessive unless the document receives very wide vetting and approval: There may be existing IETF specifications that already deviate from the guidance in this document. In these cases, it is up to the relevant communities (i.e., those of the URI scheme as well as that which produced the specification in question) to determine an appropriate outcome; e.g., updating the scheme definition, or changing the specification. As a nit, there is a reference to "BCP115": [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006, . but my copy of bcp-index.txt says: 0115 [BCP number 115 is retired. It was mistakenly assigned to RFC 4395. RFC 4395 is BCP 35.] And I think the name/locator distinction is easy to overemphasize. It is often useful, but instead of trying to hammer all applications into a single theoretical structure separating "names" and "locators", it's less error-prone and more useful to examine each instance of the distinction individually in the context within which it will operate, at which point all sorts of knotty theoretical problems have obvious solutions. Getting down to the substance of this document, it seems to largely be about how ownership of subsets of the universe of URIs is delegated. We intend the delegation to look something like: URIs-> (owned by the IETF) schema-> (owned by the IETF) namespace-> (e.g. owned by the URN experts) authority-> (owned by the domain registrant) path prefixes-> (owned by the operator of the host) resources (owned by the application instance) The problem arises when a single instance of an "application" demands a particular structure for the URI subset delegated to it, but we expect the instance's owner to be unwilling/unable to delegate a subset with that structure, e.g., because the subset demands a particular path prefix or a particular form of authority, or uses query parts in specific ways that might not be supported by the instance owner's preferred deployment method. So it might be useful to express these rules more explicitly in terms of delegeated URI subsets, and to say what sort of URI subsets an application instance can reasonably demand to be delegated to it and which it cannot. Dale