From nobody Tue Feb 2 16:47:37 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747B1ACE90 for ; Tue, 2 Feb 2016 16:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 kWoMW-J5Chkh for ; Tue, 2 Feb 2016 16:47:35 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 15EFE1ACE91 for ; Tue, 2 Feb 2016 16:47:35 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id z14so74379218igp.1 for ; Tue, 02 Feb 2016 16:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=25aqkQ7UFzHYAXAubn/JffYoIVLAbW7B5V81IB2xKSU=; b=xh1nSVp6OhFjCDp89dDxIo9GWWH9Au5U8tNHft5XBgdIgepC/vUgYHTaWOMOypsSS1 q3NDM7B54liDwYbSN5TGgLVZh2KJeOkYmFi2LPysQV/zxTyEM/hzRWs7Ise4ovJNsh75 gPxLcATo36ODuxwMTVRCGWMAhSOTcL6p50+82qpU6thhlJiWukF9hAw1mj7y0hgyeBCQ mTJhavn+uzGboQg9ZBD2M/FoLduTwdwpMMBj9yl/FFm/iC9DXo3bip2Nfl0sQCb7X5RV Td/9iNlHqNi5j2x6i+KvP58kazpijMzx39ulJ02LdVZfFaOlkoQ7te39qwDXxrX6wOpK 4BfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=25aqkQ7UFzHYAXAubn/JffYoIVLAbW7B5V81IB2xKSU=; b=XzouwGnWwXG3Xt8DUt0qeW00FwVeZT/Lf/5jm48nktKnpIbXJbFl+04pN1w/v5IPQK 4l1YDODZXkO7RePV9MCOk62q0DJ+UCwvm0ufqgn0KIutiHQVgKWMrPuxaBPajcUXGHMw DVYcQRQLSgmyCiT7iiPwdMXWGQRLF/M++YZ/btsCwwkCq39Q9NiaGM7dEGJELUYr2Vlt IUGU2kLXWgyMFSBMrKN281OUrIlSuBgLJAS4GBtNFhaCp7OMwlQfx/pN8TCijoufOwBv 40ZyzivS0Z8TPT9aCYOz2/Sdym5ky3Kz/4kCTeKYy8bVHqOIdqc8Jf923fufqUidH8C1 PRmw== X-Gm-Message-State: AG10YOQHZff7uhNXAM8GZVtHikE4nxsOjYWntgJyvJYgq2INSJQDAodxrW9fzkI4xPLfWXaca51pSrc0LCuuwg== MIME-Version: 1.0 X-Received: by 10.50.73.168 with SMTP id m8mr676643igv.53.1454460454523; Tue, 02 Feb 2016 16:47:34 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.155.198 with HTTP; Tue, 2 Feb 2016 16:47:34 -0800 (PST) Date: Tue, 2 Feb 2016 19:47:34 -0500 X-Google-Sender-Auth: dcVSzZafrJX0G62q_70-6lG_-xE Message-ID: From: Barry Leiba To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [urn] The next version of the core documentation is almost ready... X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 00:47:36 -0000 The document editors are preparing and are about to post a new draft version that attempts to propose resolutions for most open issues and to call out what remains. We all expect discussion to ensue, and our collective goal is to bring this stuff to rough consensus and finish up the core documentation, replacing 2141 and 3406. A few words on the "rough consensus" part: As chair, I'd like to ask everyone to step back from intents, ideals, and strongly held preferences -- not to eliminate them, but to step back from them -- and consider what we can accept that will bring us to closure on these updates and enable the URN deployment cases that have been brought up. We know that not everyone will get the results they really want. What we hope is that we can come to where everyone can get results they can accept. The bottom line is moving forward without breaking what's out there, even if we might have to break a guiding principle we started with. I ask everyone to put their efforts into finding something we can reach consensus on. Disagreements will work best with clear explanations of what's broken and specific alternative solutions. I'd like to see us wrap this up before IETF 95 -- so, by the end of March. If we all put good faith into aiming for that, I think it's a reachable goal. I'll be watching the discussion and intend to encourage issue resolution and discourage arguments that aren't going anywhere, repetition, ratholes, and repetition. In particular, we have to declare dead issues as dead, and not revisit them without significant information that's truly *new*, and I'll be keeping an eye on that, especially. I think that a hard URN/not-URN distinction, continued discussion of persistence, and discussion of URN resolution/resolvers are examples of issues that we ought to be done with at this point. Barry, urnbis chair From nobody Thu Feb 4 05:19:32 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0251B2D55; Wed, 3 Feb 2016 13:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 b1yeXZ4dHuIx; Wed, 3 Feb 2016 13:29:26 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 1BA5A1B2D54; Wed, 3 Feb 2016 13:29:26 -0800 (PST) Received: by mail-pa0-x233.google.com with SMTP id cy9so19770284pac.0; Wed, 03 Feb 2016 13:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=MEXNU88jLQBWZYYY6b7Z6jUl8KthqNqx3DVETcmgUn0=; b=vypAYvPbPcGfnogdDe+Dh0C+X1nDYkFuqv2Gbl3QJZ1fyfIxuM7KHUA+jkqZX1xQHn 68/3OL5HEljwsXz9VqEAoX5BFccGdO7YAtIdA+kTv4ldJLupcD+lYd1pNAO7Gj+FNCIt +LTyWHmeHQaEbqvqH7NOJ+dzPTPVSZKc1nmuRVTUGHSPNB/3NlHIrENRVCeJZxf5QYqh fpqKbNYzGZ18t5gFx0y6VIcytF3B83WEPpCGQKHcK+0en5hiz6FNnfHXktBk3rtH/8Ia RTz0oT66qdme4pGdcA4iXV51sz6uxczsWrIM/nKOE3EpseokE4RPASYJRRpxYX59WV1d wc/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:cc:to; bh=MEXNU88jLQBWZYYY6b7Z6jUl8KthqNqx3DVETcmgUn0=; b=dT2wmqyjZXcIpzhoPla2lmCxydm/MhDgyrlBobOhXL8Hw3O2KO2fzMc8xQqmuPhK1J T8zzKax20eAcX4GmV6VqBxNNcxCPv+PxFTl3IyFukl6FLCPskyz7unlIXTX52VMFSjw5 gzyz2xsOrSFehklKZ3/b6QG7rpmX+r29PM1xoi94a9sbgxVCJyup++1TM3lmqmIPMVZM BTkN0qdfeavUA296XlJiMG6w4RJfhkVR67icCNaIAWMDybmPQ03aljYVyjOm3/SFl7ty ebcNeDuf3AmIEsfurKEkJvtRB6Pq+5yT2zY9kw/RkHZYxi2BAUbd1HGGJ9USlSefXU1X e40Q== X-Gm-Message-State: AG10YORq2Kw4+2b5H11vG+y59J1HhRd7HY3SlBvsPff/CAA2fBg3dfypQlkXMWAEymN3CQ== X-Received: by 10.66.141.165 with SMTP id rp5mr5888599pab.56.1454534965667; Wed, 03 Feb 2016 13:29:25 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1002::56a? ([2001:420:c0c8:1002::56a]) by smtp.gmail.com with ESMTPSA id qj8sm11866831pac.40.2016.02.03.13.29.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Feb 2016 13:29:24 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_EE5EE20D-2E1D-4DEF-A8BF-11A8CB8509DD" Message-Id: <92FD7518-F8F5-4463-9D55-0F8746F45353@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Wed, 3 Feb 2016 13:29:24 -0800 References: <20160203194835.1105.20239.idtracker@ietfa.amsl.com> To: urn@ietf.org, urn-nid@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2016 05:19:28 -0800 Cc: Francis Dupont , Alissa Cooper , "Romascanu, Dan \(Dan\)" , Benoit Claise , Barry Leiba , Stephen Farrell Subject: [urn] Fwd: New Version Notification for draft-mahesh-mef-urn-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 21:29:28 -0000 --Apple-Mail=_EE5EE20D-2E1D-4DEF-A8BF-11A8CB8509DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks first of all for reviewing the draft. I have incorporated the = changes suggested in this version of the draft. Cheers. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-mahesh-mef-urn-02.txt > Date: February 3, 2016 at 11:48:35 AM PST > To: "Mahesh Jethanandani" >=20 >=20 > A new version of I-D, draft-mahesh-mef-urn-02.txt > has been successfully submitted by Mahesh Jethanandani and posted to = the > IETF repository. >=20 > Name: draft-mahesh-mef-urn > Revision: 02 > Title: URN Namespace for MEF Documents > Document date: 2016-02-03 > Group: Individual Submission > Pages: 5 > URL: = https://www.ietf.org/internet-drafts/draft-mahesh-mef-urn-02.txt > Status: https://datatracker.ietf.org/doc/draft-mahesh-mef-urn/ > Htmlized: https://tools.ietf.org/html/draft-mahesh-mef-urn-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-mef-urn-02 >=20 > Abstract: > This document describes the Namespace Identifier (NID) 'mef' for > Uniform Resource Names (URNs) used to identify resources published = by > MEF Forum (https://www.mef.net). MEF specifies and manages = resources > that utilize this URN identification model. Management activities > for these and other resources types are handled by the manager of = the > MEF Assigned Names and Numbers (MANN) registry. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_EE5EE20D-2E1D-4DEF-A8BF-11A8CB8509DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks first of all for reviewing the draft. I have = incorporated the changes suggested in this version of the draft.

Cheers.

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-mahesh-mef-urn-02.txt
Date: = February 3, 2016 at 11:48:35 AM = PST
To: = "Mahesh Jethanandani" <mjethanandani@gmail.com>


A new version of I-D, = draft-mahesh-mef-urn-02.txt
has been successfully = submitted by Mahesh Jethanandani and posted to the
IETF = repository.

Name: = draft-mahesh-mef-urn
Revision: 02
Title:= = URN Namespace for MEF Documents
Document date: = 2016-02-03
Group: Individual Submission
Pages:= = 5
URL: =            https://www.ietf.org/internet-drafts/draft-mahesh-mef-urn-02.tx= t
Status: =         https://datatracker.ietf.org/doc/draft-mahesh-mef-urn/
Htmlized:       https://tools.ietf.org/html/draft-mahesh-mef-urn-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-mef-urn-02=

Abstract:
  This = document describes the Namespace Identifier (NID) 'mef' for
=   Uniform Resource Names (URNs) used to identify resources = published by
  MEF Forum (https://www.mef.net). =  MEF specifies and manages resources
=   that utilize this URN identification model.  Management = activities
  for these and other resources = types are handled by the manager of the
  MEF = Assigned Names and Numbers (MANN) registry.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_EE5EE20D-2E1D-4DEF-A8BF-11A8CB8509DD-- From nobody Thu Feb 4 05:31:12 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956D61B2F1E for ; Thu, 4 Feb 2016 05:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 Ab0cdqk9uGSs for ; Thu, 4 Feb 2016 05:31:10 -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 61E741B2F17 for ; Thu, 4 Feb 2016 05:31:10 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aRK05-000D2L-9Z for urn@ietf.org; Thu, 04 Feb 2016 08:31:09 -0500 Date: Thu, 04 Feb 2016 08:31:04 -0500 From: John C Klensin To: urn@ietf.org Message-ID: 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] draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 13:31:11 -0000 Hi. draft-ietf-urnbis-rfc2141bis-urn-15 is in the posting queue and should be posted later today. Significant changes, all except the first discussed on-list in one form or another: (1) Some rearrangements and editorial changes to make the document more clear (not really significant). (2) Explicit text about the situation we are in and avoidance of topics that would require boiling oceans, etc. (3) Changed syntax for r-component and q-component and a much more restricted explanation of what the latter is about (although the idea of a resolver-ID has been incorporated) (4) A bit more discussion of character sets and coding. See the change log and the document itself for more information. Please review. While reviewing, note that we have not done a careful review of the contents of the registration template in comparison to the more general text in some time and please do that an check for consistency. Personal opinion, but I hope this is the last version of 2141bis with significant and substantive changes. I expect we will need one more pass/ revision before WG LC, but don't expect major changes. If I'm wrong about that, we should get on with it, but please see Barry's recent note. best, john From nobody Thu Feb 4 05:31:22 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E559E1B2F25; Thu, 4 Feb 2016 05:31:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160204133120.20011.13947.idtracker@ietfa.amsl.com> Date: Thu, 04 Feb 2016 05:31:20 -0800 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-15.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 13:31:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-15.txt Pages : 36 Date : 2016-02-04 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" scheme and a particular URN namespace, with the intent that the URN will be either a persistent, location-independent resource identifier or in some cases an abstract designator that is persistent but that does not identify a resource. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 5 02:46:27 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C961A1A8A for ; Fri, 5 Feb 2016 02:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 LsU0Xd6n-sPh for ; Fri, 5 Feb 2016 02:46:23 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0102.outbound.protection.outlook.com [104.47.125.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF331A1A8D for ; Fri, 5 Feb 2016 02:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q8de8v7qJNWSGqKHKby66CRBTu0h4kwkhtzmxdqkwbY=; b=lsnTRVePaN7MtR7sjqa8KYf1UvNu7lZ/hmzJVK2V9EF9KMfKrce4ggeuLco9aWuc5mj/3ifTf86nnSeI3HjkrLmB2quMVpOLUXY8VRaokRBzzNjBjq6jAUNv8vuFCywhbSTku2Xo6KZnuaJClKjirZ/2KMxvg7VF1rHWpjI3NTE= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0141.jpnprd01.prod.outlook.com (10.161.134.13) with Microsoft SMTP Server (TLS) id 15.1.403.16; Fri, 5 Feb 2016 10:46:19 +0000 To: Carsten Bormann , References: <56A8CFE5.5010200@tzi.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56B47D77.6030904@it.aoyama.ac.jp> Date: Fri, 5 Feb 2016 19:46:15 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A8CFE5.5010200@tzi.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0001.jpnprd01.prod.outlook.com (25.161.131.139) To TY1PR01MB0141.jpnprd01.prod.outlook.com (25.161.134.13) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0141; 2:Td7bl0Tk2cEmRWeCvWosJrAEeJaOsxAtuvEd8VD0JxRBiXHp1p83fXa9wItz81N3Hrzocc9RgeFZuLRsH4k3txTEWaanLB/chYS8zPBpJvV/LXy0IpOTCUvazBgDyIUu0a6kpLsxbiuxeOK/hQHgxA==; 3:QOhlXBnm+YSoz2OT0FAco3s0fICavEvqEd0b4LccGHGFmR8VsL2n93/6TmOe8GxCaK4QIpbE+ERfI/OhIxriIqASOfCfjwphZRxoRSYnyX8x9Mfz+nMYgDSTNLuJZJWW; 25:WKrF3OR3FeqxZN6Kx9yfzoYwdVw2rOo91JvpMo8Tz+CbH9Eq8FJurmx0rPgx+UGJ6M6oTENlKkDRJXfT9XSapStPY8BATWDRyvXYDuqH2PA7YPtHwN+53k83juD4M1wx7BUEmyQonW2s/dyXeiKCN3sXNvWMZLS+P8I3FnhUwbwK5BLr6JPmgk3CsctsnNNIvmgjGezkHmdmtm5Abn1CiCCCXsf1Xs4xebcwV9hLsnqXLSLids0BGipCQK/AdeqCanGtdabXHiEvwSrH4QuDYOrX5p749ES/UvZOetMCRXaM+Sf4P8zZsKBlPdToL3x0; 4:1xrJwPL1XGdqwNVIgWFBHGX6wgY17Agfo4QFcbpj6dQQ8ZB5YICxBIHmogmK4wlcnbzg782yIoijDLl607ix8EqW/wmOubgaA/DBpW5XKd9VqdyrPBw7JS55LANky+4B2GeNnXLLoW6tWhmksZnwyywP6OucBXa3rUMDMV5t2v8uzp6RrEDV8jreH6LHiklu/ZS5DG3anm8vs+c8dR3qlhuVyg+z86QRp0DnX0tJpCoGOEJLGctV73cnbEtACtoqcMk8Xelu+lhw4N8scPQssuZMRago3PdzJMCq6wTw7bPPPSeq56v9RzFHmisv2G8YKKtsfbR0nYcrsrc/Ru2r412weBjgafTFoC9wYgql39o= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0141; X-MS-Office365-Filtering-Correlation-Id: ef47e66f-c2dc-4624-f37e-08d32e19949d X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:TY1PR01MB0141; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0141; X-Forefront-PRVS: 0843C17679 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(479174004)(24454002)(42186005)(50986999)(59896002)(77096005)(65816999)(76176999)(87266999)(5008740100001)(54356999)(586003)(92566002)(6116002)(3846002)(86362001)(33656002)(1096002)(23676002)(83506001)(64126003)(2906002)(80316001)(2870700001)(19580405001)(19580395003)(189998001)(50466002)(87976001)(5001770100001)(107886002)(5001960100002)(4001350100001)(122386002)(65806001)(47776003)(5004730100002)(74482002)(40100003)(2950100001)(15975445007)(65956001)(66066001)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0141; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQxOzIzOkwrOVlZWjB2R2t4L3lneG12a2hqVERCVTFF?= =?utf-8?B?NmpCdUZqamhNcTNyZDBTK3ljekpxTnBTMFlqWEVKQ3l1NU5uOTFrSWk0ZVRx?= =?utf-8?B?M2p6ZlJaNTNDWmRjcFYwS0JJdkluSXAzUmdualduYVRwbnVKU3VyV0NncWJk?= =?utf-8?B?ZmZRek0vNGdQR3FjMS9hMHV3NjNjRERSTmFZVFgrN253UmhIN1JpRGJIQVUz?= =?utf-8?B?TW85WnR0UUJFZzV1NytPektwZWdIUHlQV2tUZjVrZkpCc1BQYXVHZTJuZE4x?= =?utf-8?B?OTdqbzhKYkNSYnh0OGU2MkJBZU9xUy9iREV1OEgxd3FWTGl2NzZJbE1jZERB?= =?utf-8?B?UnhIcVJ2R2t5KzhJUmJ5ekkvbUdOL0FQYzVHK0Y2K2tLQU1tY0VoV2J4ODYz?= =?utf-8?B?bWVPY0RnZjdZcm1ZNXBPZzlPb1lYQVZpL3NndDJ4R0ZpZjJucnk0Y3JYOVFU?= =?utf-8?B?Yks3NlgwM3ZqMDFHdHFFZHpTMmtXTzg5Qm9oT2ZYa1FhTmhXL1FudEFaOU1t?= =?utf-8?B?M1dMQjJSZ2FSSkxmM3k4UEV4RWRRVFNBb2g0K1I2Z04xMmVmcFZXWFN5RXV1?= =?utf-8?B?V3ZXcHJIOTFYVlpRc3d2Q0NhWWdHb1lDdE50NG51QzJkWEEvc3I2dmY4bTdh?= =?utf-8?B?Mlgya2NyYjdUT3BqVVRzNUd2a1d2SGxpa3ZLRGlBeEJwTHlMZlNLOXpJeFZS?= =?utf-8?B?blNNeGZVWFNtaEY2TXRGMVpPNk8va01wQ3V2Z2Z5N0VGanlrSUhzb3RhcW5Y?= =?utf-8?B?Z3BkSnBGeFB6YlEvWGhnMW8rOFVhYk5hWlQrTG83MXpEOHhtY0VrdWRaSGJ3?= =?utf-8?B?RklhNFdHcStTNHMwZW5YRWFaOVVOR3RjamxySzhtaGdYOE14UGxEOTd4blFq?= =?utf-8?B?UWhKVGtQcG5oK1ZTK0NsZGsyRTA5VzlYdDlRYms0U1hYS004bVBDTjBKUEx3?= =?utf-8?B?clVCQUM3Snl2SVpoajF5UVdkVXZNWWc1dk12NmRJTUkvRnYyS0d2ZWJ2aVpj?= =?utf-8?B?QjRQS2U2Ukl2TkJyZXEzRTl6MmNJMjNtN3ZnZEZjS2tIY3paeTUxemxIN0Ru?= =?utf-8?B?MXZoQ1hsL1IxSElDOUdOMEJHeHBySWVTTHcrczBnMXRyTXVRb1lwZ3pzQmxN?= =?utf-8?B?R2xyUC9lNkJmYW1LbkJmdUNKMTFJb3pReVVYeDZ0VDA0TlE5SjFpbEVKK3hu?= =?utf-8?B?UVpEenFXNE8vZGYrMlRBYVdEUDN2dlJLTWxJeTR5S1dibmFVWVUvNEYzK0la?= =?utf-8?B?ZzZncEIzN3AxVFdScU5RaC9kVGFHS1EyTjFuY3JrdWZiYXJDdDNpMGNHQkw0?= =?utf-8?B?Q2svQjJoUUordXo3QWFISk0rY1VtTXV5WStPNWpDajBubWdGcDg3cHdvM0po?= =?utf-8?B?ajRtTUFDek5mUVd3dnJsODFDQ3RIckFvTzREaWxqQk45VzdnMzdvRkFjZU5l?= =?utf-8?B?K0FrWGhycE9nY2RIUE5KcHNkRTFKWXRzYTFDUkdGTHdFY3doaGh4REhRYTVw?= =?utf-8?B?bmhUVTQ1UGhaajc3RExEQnMvdXdFYzN5OGE1YUk1MXV1ODBneG91dmRKa3c3?= =?utf-8?B?SGl6T09qUnVMQXhKRElIQmtWSVFCei9zdHNETXloVnFEdk9XS0RQUU1WSmNO?= =?utf-8?B?Z3A2VWhzTStwM01YY2lFdmROZHhCSnBhMXFWZmJwZGM0SnUrQVdNd2dnPT0=?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0141; 5:MCtgjJ3n9Z++iQezGr29i3IkMQ1bF7TifJFbYJWSx/OvztPKF2BIhBmjtGax+iT28K2OVJ25NE32ZyDPLgfOuPvPaSxTMYy23YhAR2gKuaoRwRQgGLO+VYPCMGz09yfYvtBbc3unv1J/EbNxLtbA3w==; 24:V2WVD5qF+TjFg4iSvViMXZGAIbHggjCvVCuddFemIdbybpSITuzo+QO87gqlh16ZCjywcCs5z/ghKFioLIpNc0AQOqsYzgFggQqYVJYl2DI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Feb 2016 10:46:19.1186 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0141 Archived-At: Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 10:46:26 -0000 Hello Carsten, I think the issue below has come up repeatedly in different groups, but probably never got enough traction. Unfortunately, I can't remember any details, but you should probably find something if you dig deeper, either for using URNs or for using URLs. Sorry for not being of more help. Regards, Martin. On 2016/01/27 23:10, Carsten Bormann wrote: > In W3C WoT IG, we are looking at employing RDF to represent information > that is today often held in Web links (RFC 6690, RFC 5988). > That includes media types, but also maybe link relation types and other > registry content. > It would be great to have a canonical mapping to URIs for all these. > Has there been any attempt in the past to define, say, URNs for media types? > Any other advice on how to obtain stable URIs for protocol constants? > (I don't think we want to use the URL to the IANA registry page.) > > Grüße, Carsten > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Fri Feb 5 09:54:29 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BA31A00E1 for ; Fri, 5 Feb 2016 09:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 98-ReRBaWyPi for ; Fri, 5 Feb 2016 09:54:27 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (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 EEABB1A0027 for ; Fri, 5 Feb 2016 09:54:26 -0800 (PST) Received: by mail-qg0-x22b.google.com with SMTP id u30so73582547qge.1 for ; Fri, 05 Feb 2016 09:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j6DprdEzzBSJyqRh0kNxog4YS/tImmYMMYhz71GmXDo=; b=WdntYGm+/I/xub0jZC1VJcTQGI/c9djlc0/iOH1W8VJkOnYT5clCKquYYnS+i4KPPl cWIrPqoMU7FRFhpg3EcilBcstP1TPFu+D64y2mmvoB235GsCbQXHxErNgcnLpC/P5D8M +6toOpXIjjY1ABhWNXKpY0qI2iHCgvFtRlaUGA9TOF4W4y9ABOZzdDgvklQl08M0KBtO DnHglJa5omt66HYvhAv0F/Idy2axSPafIvIjcwvA5dTCmhn6M9dbH8KiYy0o0lI4MOQS IfXyLGkvSLUteFYKyLKtu4GEWxsE2Q29ILoKnB+H1XUp1MVq073M270XRWbENOkyIciO ucoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=j6DprdEzzBSJyqRh0kNxog4YS/tImmYMMYhz71GmXDo=; b=UXP5ytNjvuykF5Hro6IsIH7Aieb37+DRfk4Op0onUZ0tPfhHkt//blKGZmioqUoodV S95vIk6oCuoSDs5586mpQcUMJ9XL1RWrb7naBlgR4JE88YR7olbuSUrwLD1e8/Nb4xqw 3AuApOyH4IEqwFdz0hV0dFXJHDCvuZEwHZLaE/cAt8ug8HUNybMxfkY53mDxAgKh1hje LKW935BXBsKfMRiVn+4QJ+uJ4b9WikjQgxgXYh+d7I2+xSiNWEVm12cMTOeeEqt/NkHq PsykYJKX2jBV7lZhg60mUcq7jI8wtYZpOwz6ppyp5JxSTOz9n8Od+2fMEveTTFAyujtE APSQ== X-Gm-Message-State: AG10YORrmoGDozCLcbS5i91C3LctEhsy6s5xZW08Kmqw+DvJD+QY0SFKnCTD0wZAzZwPC9OnddGJHe3LtCf+WA== X-Received: by 10.140.109.100 with SMTP id k91mr18469734qgf.54.1454694866175; Fri, 05 Feb 2016 09:54:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.14.211 with HTTP; Fri, 5 Feb 2016 09:54:06 -0800 (PST) In-Reply-To: <56B47D77.6030904@it.aoyama.ac.jp> References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> From: Ted Hardie Date: Fri, 5 Feb 2016 09:54:06 -0800 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Graham Klyne Content-Type: multipart/alternative; boundary=001a1139b43ac14c52052b098ab5 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:54:28 -0000 --001a1139b43ac14c52052b098ab5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've added Graham Klyne, because he worked on RDF representations of IETF media types during the content negotiation work many years ago. Theory states that you could register these are protocol parameters under the registry set up in RFC 3553 ( http://www.iana.org/assignments/params/params.xhtml#params-1), but I think you would find that you'd basically have to create the mappings rather than rely on a set already in place. regards, Ted Hardie On Fri, Feb 5, 2016 at 2:46 AM, Martin J. D=C3=BCrst wrote: > Hello Carsten, > > I think the issue below has come up repeatedly in different groups, but > probably never got enough traction. Unfortunately, I can't remember any > details, but you should probably find something if you dig deeper, either > for using URNs or for using URLs. > > Sorry for not being of more help. > > Regards, Martin. > > > On 2016/01/27 23:10, Carsten Bormann wrote: > >> In W3C WoT IG, we are looking at employing RDF to represent information >> that is today often held in Web links (RFC 6690, RFC 5988). >> That includes media types, but also maybe link relation types and other >> registry content. >> It would be great to have a canonical mapping to URIs for all these. >> Has there been any attempt in the past to define, say, URNs for media >> types? >> Any other advice on how to obtain stable URIs for protocol constants? >> (I don't think we want to use the URL to the IANA registry page.) >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >> >> > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > --001a1139b43ac14c52052b098ab5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've added Graham Klyne, because he worked on R= DF representations of IETF media types during the content negotiation work = many years ago.

Theory states that you could register t= hese are protocol parameters under the registry set up in RFC 3553 (http://ww= w.iana.org/assignments/params/params.xhtml#params-1), but I think you w= ould find that you'd basically have to create the mappings rather than = rely on a set already in place.

regards,

<= div class=3D"gmail_default" style=3D"font-family:garamond,serif;font-size:s= mall">Ted Hardie

On Fri, Feb 5, 2016 at 2:46 AM, Martin J. D=C3=BCrst <duerst= @it.aoyama.ac.jp> wrote:
Hello Carsten,

I think the issue below has come up repeatedly in different groups, but pro= bably never got enough traction. Unfortunately, I can't remember any de= tails, but you should probably find something if you dig deeper, either for= using URNs or for using URLs.

Sorry for not being of more help.

Regards,=C2=A0 =C2=A0Martin.


On 2016/01/27 23:10, Carsten Bormann wrote:
In W3C WoT IG, we are looking at employing RDF to represent information
that is today often held in Web links (RFC 6690, RFC 5988).
That includes media types, but also maybe link relation types and other
registry content.
It would be great to have a canonical mapping to URIs for all these.
Has there been any attempt in the past to define, say, URNs for media types= ?
Any other advice on how to obtain stable URIs for protocol constants?
(I don't think we want to use the URL to the IANA registry page.)

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn

--001a1139b43ac14c52052b098ab5-- From nobody Sat Feb 6 11:35:45 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C1C1A907A; Sat, 6 Feb 2016 11:35:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160206193542.2232.4334.idtracker@ietfa.amsl.com> Date: Sat, 06 Feb 2016 11:35:42 -0800 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-semantics-clarif-03.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 19:35:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : URN Semantics Clarification Author : John C Klensin Filename : draft-ietf-urnbis-semantics-clarif-03.txt Pages : 11 Date : 2016-02-06 Abstract: Experience has shown that identifiers associated with persistent names have properties and requirements that may be somewhat different from identifiers associated with the locations of objects. This is especially true when such names are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Library, Museum, Publisher, and Information Science communities and other users, this specification separates URNs from the semantic constraints that many people believe are part of the specification for Uniform Resource Identifiers (URIs) in RFC 3986, updating that document accordingly. The syntax of URNs is still constrained to that of RFC 3986, so generic URI parsers are unaffected by this change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-semantics-clarif-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 6 11:41:35 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB2C1AC3CE for ; Sat, 6 Feb 2016 11:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 XJE86AY8f5tn for ; Sat, 6 Feb 2016 11:41:32 -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 80E101A9119 for ; Sat, 6 Feb 2016 11:41:32 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aS8jb-000K4m-7g for urn@ietf.org; Sat, 06 Feb 2016 14:41:31 -0500 Date: Sat, 06 Feb 2016 14:41:26 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <4562EADF0DFB9E2C1304337A@JcK-HP8200.jck.com> 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] draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 19:41:34 -0000 I've just posted a new version of draft-ietf-urnbis-semantics-clarif, largely because -02 was scheduled to expire next week. I have gone through it and updated some of the text to reflect the last few versions is 2141bis, e.g., by dropping comments about p-components and mentioning r-components. I've also tidied up the language and explanations in several places. I don't believe that any of the changes are really substantive, but the WG should review the revised draft to be sure I haven't messed anything up. john p.s. An update for the registration transition I-D, draft-ietf-urnbis-ns-reg-transition will follow in a few days, probably with almost no changes other than an update to the date. From nobody Sun Feb 7 14:34:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D2A1A6F44 for ; Sun, 7 Feb 2016 14:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 W3PRGV1fDDUM for ; Sun, 7 Feb 2016 14:34:45 -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 F03FB1A6F39 for ; Sun, 7 Feb 2016 14:34:44 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aSXul-000NtE-To for urn@ietf.org; Sun, 07 Feb 2016 17:34:43 -0500 Date: Sun, 07 Feb 2016 17:34:38 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <655C976223FCCC2DE6251563@JcK-HP8200.jck.com> 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] draft-ietf-urnbis-ns-reg-transition X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 22:34:50 -0000 Hi. draft-ietf-urnbis-ns-reg-transition-06 is now in the posting queue. As compared to the previous version, it has updated references, an explicit reference to the IANA URN namespace registry, and some minor editorial tuning. We will eventually need to come back to this document after the 2141bis registration template is complete (see prior note about reviewing that template in 2141bis-15) and we are ready to move forward, but probably time can be better spent now than on review this document. The one important exception is that, if anyone has (or knows of) existing registrations that could usefully be changed to reflect the new model, this would be the right time to start thinking about them, if only because minor patches could be made as part of this I-D without requiring new documents. john From nobody Sun Feb 7 14:35:20 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E91A6F39; Sun, 7 Feb 2016 14:35:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160207223517.31248.59445.idtracker@ietfa.amsl.com> Date: Sun, 07 Feb 2016 14:35:17 -0800 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-ns-reg-transition-06.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 22:35:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised of the IETF. Title : Uniform Resource Name (URN) Namespace Registration Transition Authors : John C Klensin Juha Hakala Filename : draft-ietf-urnbis-ns-reg-transition-06.txt Pages : 8 Date : 2016-02-07 Abstract: The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed in [[RFC 2141bis]]. That document adopts a different model. This document specifies IANA instructions to adapt selected existing registrations to the new model. It also obsoletes some previous RFCs to eliminate any ambiguity about the status of new templates and updated registrations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-ns-reg-transition-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-ns-reg-transition-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 9 09:05:20 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6652F1ACD41; Tue, 9 Feb 2016 09:05:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160209170518.25953.15651.idtracker@ietfa.amsl.com> Date: Tue, 09 Feb 2016 09:05:18 -0800 Archived-At: Subject: [urn] New Version Notification - draft-martin-urn-globus-02.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 17:05:18 -0000 A new version (-02) has been submitted for draft-martin-urn-globus: https://www.ietf.org/internet-drafts/draft-martin-urn-globus-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-martin-urn-globus/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-martin-urn-globus-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Feb 9 17:16:27 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 480691AD2D5; Tue, 9 Feb 2016 17:16:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "DraftTracker Mail System" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160210011626.29518.51181.idtracker@ietfa.amsl.com> Date: Tue, 09 Feb 2016 17:16:26 -0800 Archived-At: Cc: urn@ietf.org, barryleiba@gmail.com, barryleiba@computer.org Subject: [urn] Last Call: X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 01:16:26 -0000 Last Call Request has been submitted for https://datatracker.ietf.org/doc/draft-martin-urn-globus/ From nobody Wed Feb 10 05:45:07 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 241081B2ACE; Wed, 10 Feb 2016 05:45:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160210134504.31541.50561.idtracker@ietfa.amsl.com> Date: Wed, 10 Feb 2016 05:45:04 -0800 Archived-At: Cc: draft-martin-urn-globus@ietf.org, urn@ietf.org, barryleiba@gmail.com, barryleiba@computer.org Subject: [urn] Last Call: (A URN Namespace for Globus) to Informational RFC X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 13:45:04 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'A URN Namespace for Globus' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a URN (Uniform Resource Name) namespace that is used by Globus for naming persistent resources. The file can be obtained via https://datatracker.ietf.org/doc/draft-martin-urn-globus/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-martin-urn-globus/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Feb 12 07:57:33 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BD5661A87A3; Thu, 11 Feb 2016 16:27:06 -0800 (PST) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938231A6FDF; Thu, 11 Feb 2016 16:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EvDCcFAP6Mrx; Thu, 11 Feb 2016 16:27:02 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BD81A6FB8; Thu, 11 Feb 2016 16:26:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F1EC21C07A1; Thu, 11 Feb 2016 16:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1455236818; bh=eK0FoKBEp+VIjguZYuIFbDSR7kTCO7NnayfalRYmTfg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BCUsuKjeTOT0In6vb+eK2AaDlfqaFDd86CaXoUp2EdA/s3MnY4lQSEPl7+P+JcxU0 Sd7Wqaty4YMJoYCoV0VSONED4LD/FqeMNX7EBnnLcyUsuqExPiz9nYF6bCqtF27lCY s58uCGITLKse58JARniP5oeeytMmQuJrNJIY8cHE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 80A931C059C; Thu, 11 Feb 2016 16:26:58 -0800 (PST) To: "A. Jean Mahoney" , General Area Review Team , draft-martin-urn-globus.all@ietf.org References: <56BD072F.4080905@nostrum.com> From: "Joel M. Halpern" Message-ID: <56BD269D.1040703@joelhalpern.com> Date: Thu, 11 Feb 2016 19:26:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BD072F.4080905@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 12 Feb 2016 07:57:31 -0800 Subject: [urn] [Gen-art] Review: draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 00:27:06 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-martin-urn-globus-02 A URN Namespace for Globus Reviewer: Joel M. Halpern Review Date: 11-Feb-2016 IETF LC End Date: 9-March-2016 IESG Telechat date: 17-March-2016 Summary: This document is nearly ready for publication as an informational RFC. This reviewer assumes that the appropriate message has been or will be sent to urn-nid@apps.ietf.org. Major issues: As per the pointer in this document to RFC 3406 section 4.3, this document is required to have a Namespace Considerations section which "outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements)." While there is a section called Namespace Considerations, what it lists is the envisioned usages, not the reasons existing name spaces are insufficient. Minor issues: N/A Nits/editorial comments: N/A From nobody Sat Feb 13 06:50:08 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8441B3341 for ; Sat, 13 Feb 2016 06:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.794 X-Spam-Level: X-Spam-Status: No, score=0.794 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 z-o2IljUIO_8 for ; Sat, 13 Feb 2016 06:49:53 -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 014FE1B3340 for ; Sat, 13 Feb 2016 06:49:52 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aUbWA-000MPF-Hk for urn@ietf.org; Sat, 13 Feb 2016 09:49:50 -0500 Date: Sat, 13 Feb 2016 09:49:45 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> 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] ReL draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 14:49:54 -0000 Hi. Writing primarily as the pen-holding editor for -15 and the likely one for -16.... It has now been over a week since -15 was posted and there have been absolutely no comments. I am fairly sure the mailing list is working because there have been postings about two URN NID registration proposals --proposals that would presumably be handled quite differently under the new, 2141bis rules. I hope, although I'm afraid to assume, that the silence means that -15 reflects agreement on the basic technical, protocol, and procedural issues and how to handle them and an acceptable and reasonably balanced way of dealing with the issues we clearly are not ready to handle and reach consensus about. There is a lot of new text (compared to -13 and -14) in the document but I believe we've discussed enough of the issues on-list that none of it should be a surprise. Whether the text correctly and optimally reflects the WG's views is a separate question, so I'd really appreciate comments on that question, preferably soon enough that we don't lose momentum again. In particular, I would hope that people would pay careful attention to, and comment on: (1) Do the registration template and supporting information still reflect what we want there? They have not been carefully reviewed, much less revised, in the last few drafts, and we need to think about other changes and whether they should be reflected in the NID/ Namespace registration specifications. (2) We've seen two proposals for NID registrations in the last week or two. Would the registration template and new procedure adequately reflect whatever we've learned from them? Would we be happy having them go through under the new procedure? (3) Is the ABNF consistent with everyone's expectations, especially noting the the change in introducers for r-component and q-component eliminates several problems (including the controversy about ordering) but may introduce a few others. In particular, is everyone ok with q-component and r-component appearing in either order (as the text and ABNF now say) or is there some reason to require a specific order)? Similarly, the text contains some words about the implications of "?" followed by neither (new) delimiter but the ABNF doesn't call the issue out. Is that ok with everyone? If it is not, please propose ABNF changes and/or text. (4) Is the spec now clear enough? Are there places that need work? If so, please at least identify the places and the issues and, if possible, propose text. Possibly others have other issues, but it would be good to identify them soon. Speaking personally, I'd be very pleased if we could get far enough that I could spin up and post a new draft on the weekend of the 20th and then go into WG Last Call the following week. Especially given the silence of the last week, I think that ought to be possible. IMO, the best parting present we could give Barry before he formally steps down as AD would be to let him get an IETF LC wrapped up and the WG either shut down or concluded except for RFC Editor review. john From nobody Wed Feb 17 19:11:58 2016 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6751A90AE; Wed, 17 Feb 2016 08:35:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160217163525.27026.97975.idtracker@ietfa.amsl.com> Date: Wed, 17 Feb 2016 08:35:25 -0800 Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 19:11:56 -0800 Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@gmail.com Subject: [urn] urnbis - Not having a session at IETF 95 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 16:35:25 -0000 Barry Leiba, a chair of the urnbis working group, indicated that the urnbis working group does not plan to hold a session at IETF 95. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Feb 17 19:11:59 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AD5551B2F45; Wed, 17 Feb 2016 13:49:59 -0800 (PST) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842281B2F42 for ; Wed, 17 Feb 2016 13:49:59 -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, HTML_MESSAGE=0.001, SPF_FAIL=0.001] autolearn=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 mtADOfe5kazH for ; Wed, 17 Feb 2016 13:49:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 347AE1B2F3F for ; Wed, 17 Feb 2016 13:49:50 -0800 (PST) Received: from mx0.ccs.nrl.navy.mil ([2001:480:20:118:118::211]:33996 helo=ccs.nrl.navy.mil) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aW9ym-0000fZ-Uo for draft-martin-urn-globus.all@tools.ietf.org; Wed, 17 Feb 2016 13:49:50 -0800 Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u1HLn367017264 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2016 16:49:03 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E" Date: Wed, 17 Feb 2016 16:49:03 -0500 Message-Id: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-martin-urn-globus.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email X-Helo-Check-Failed: Verification failed for HELO ccs.nrl.navy.mil X-SA-Exim-Connect-IP: 2001:480:20:118:118::211 X-SA-Exim-Rcpt-To: draft-martin-urn-globus.all@tools.ietf.org X-SA-Exim-Mail-From: catherine.meadows@nrl.navy.mil X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-martin-urn-globus.all@ietf.org Resent-Message-Id: <20160217214950.347AE1B2F3F@ietfa.amsl.com> Resent-Date: Wed, 17 Feb 2016 13:49:50 -0800 (PST) Resent-From: catherine.meadows@nrl.navy.mil Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 19:11:56 -0800 Cc: Catherine Meadows Subject: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 21:49:59 -0000 --Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draftt describes a Uniform Resource Name (URN) namespace that is = used by the Globus software-as-a-service provider for naming persistent resources. The main requirement is that these = identifiers which will persist in external systems, and which must be identifiable as references to Globus entities. The draft specifies = the syntax, and describes mechanisms for enforcing uniqueness. In = particular, URNs may not be reassigned. =20 In the Security Considerations section, the authors refer the reader to = RFC=E2=80=99s 1737 and 2141. The security considerations in RFC 1737 = refer to authentication mechanisms which are outside the scope of the document. The recommendations of RFC = 1737, however, may require more attention. Its Security Considerations = section runs as follows: =20 This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. The draft does not propose any special meanings for characters in the = Namespace Specific String, but I think it would be good to add a sentence in the Security = Considerations Section mentioning this stipulation, and pointing out that it does not apply in your case because no such = spacial meaning is proposed. I consider this document Ready With Nits. Cathy is being proposed,=20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have reviewed this document as part of the security = directorate's
ongoing effort to review all IETF documents = being processed by the IESG.
These comments were written = primarily for the benefit of the security
area directors. = Document editors and WG chairs should treat these
comments = just like any other last call comments.

This draftt describes a Uniform = Resource Name (URN) namespace that is used by the Globus = software-as-a-service provider
for naming = persistent resources.  The main requirement is that these = identifiers which will persist in external systems, and which = must
be identifiable as references to Globus = entities.  The draft specifies the syntax, and describes mechanisms = for enforcing uniqueness.  In particular, URNs
may not be reassigned.  

In the Security Considerations section, = the authors refer the reader to RFC=E2=80=99s 1737 and 2141.  The = security considerations in RFC 1737 refer to authentication = mechanisms
which are outside the scope of the = document.  The recommendations of RFC 1737, however, may require = more attention.  Its Security Considerations section runs as = follows:

 
This document specifies the syntax for = URNs.  While some namespaces
  =  resolvers may assign special meaning to certain of the characters = of
   the Namespace Specific String, any = security consideration resulting
   from = such assignment are outside the scope of this document.  It = is
   strongly recommended that the = process of registering a namespace
  =  identifier include any such considerations.
The draft does not propose any special = meanings for characters in the Namespace Specific String,
but I think it would be good to add a sentence in the = Security Considerations Section mentioning this stipulation,
and pointing out that it does not apply in your case because = no such spacial meaning is proposed.

I consider this document Ready With = Nits.

Cathy

is being proposed, 
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_11BF8542-4C35-4518-8182-878E912BD67E-- From nobody Thu Feb 18 07:35:23 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE21B2A9D for ; Thu, 18 Feb 2016 07:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 c8YLF38QianT for ; Thu, 18 Feb 2016 07:35:19 -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 ECE9A1B2ABE for ; Thu, 18 Feb 2016 07:35:09 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aWQbf-000FkK-TE; Thu, 18 Feb 2016 10:35:03 -0500 Date: Thu, 18 Feb 2016 10:34:58 -0500 From: John C Klensin To: Catherine Meadows Message-ID: In-Reply-To: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> References: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> 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: Cc: Alexey Melnikov , urn@ietf.org, Barry Leiba Subject: Re: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:35:21 -0000 Cathy, (Barry and/or Alexey, please see the "p.s" below.) Your review of the above document was copied to the URNBIS WG mailing list, I think due to an AD decision that the WG should look at new URN NID registration requests to help inform its work going forward. In that light... --On Wednesday, February 17, 2016 16:49 -0500 Catherine Meadows wrote: >... > In the Security Considerations section, the authors refer the > reader to RFC's 1737 and 2141. The security considerations > in RFC 1737 refer to authentication mechanisms which are > outside the scope of the document. The recommendations of RFC > 1737, however, may require more attention. Its Security > Considerations section runs as follows: > > This document specifies the syntax for URNs. While some > namespaces resolvers may assign special meaning to certain > of the characters of the Namespace Specific String, any > security consideration resulting from such assignment are > outside the scope of this document. It is strongly > recommended that the process of registering a namespace > identifier include any such considerations. The successor to RFC 2141, draft-ietf-urnbis-rfc2141bis-urn ("2141bis" below), has, at least IMO, a much more comprehensive view of character and character code considerations than 2141 or 1737. I (and I assume the WG) would appreciate your taking a look at that, partially on the theory that you might draw the short straw for reviewing a successor on IETF LC and it is far easier to have a discussion and make changes before that stage is reached (at least some of us believe that the current version is the next-to-last before WG Last Call), but specifically to address two questions. (1) RFC 1737 is a 21+ year old Informational document. URNs have evolved considerably since then. Do you think its Security Considerations (or other) sections are sufficiently outdated that 2141bis should explicitly update 1737 to deprecate that section and point people to newer documents? (2) More generally, do you think the Security Considerations section of 2141bis are adequate? If not, what changes would you propose or issues you would recommend addressing? You probably should read the introductory material in 2141bis before answering because it explains some constraints that may be relevant. >... best, john p.s. Barry, Alexey, I don't think the above has any significant impact on draft-martin-urn-globus-02, so have not copied this note to the IESG. If you disagree, feel free. That said, I think that normative references to 1737, especially in conjunction with the sort of handwaving in the Security Considerations section of the present draft, are a bad idea and should be discouraged for the reasons implied above. I don't know whether I would recommend it or not, but, if the issue Cathy raises are significant enough, it would be possible to approve this draft with a normative pointer to 2141bis, let the registration go forward, but then let this document sit in the RFC Editor queue until 2141bis is ready for publication. From nobody Thu Feb 18 08:34:06 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9F01B2F0C for ; Thu, 18 Feb 2016 08:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3dLPUKR1fAhQ for ; Thu, 18 Feb 2016 08:34:02 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 27B711B2EFF for ; Thu, 18 Feb 2016 08:34:02 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u1IGXxQE014870 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 18 Feb 2016 11:33:59 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_69CB84A2-AE4A-422F-A71C-71CE4D4B2605" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Catherine Meadows In-Reply-To: Date: Thu, 18 Feb 2016 11:33:59 -0500 Message-Id: References: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> To: John C Klensin X-Mailer: Apple Mail (2.3112) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Cc: urn@ietf.org, Catherine Meadows , Barry Leiba , Alexey Melnikov Subject: Re: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:34:05 -0000 --Apple-Mail=_69CB84A2-AE4A-422F-A71C-71CE4D4B2605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sure, John, I=E2=80=99ll be happy to take a look at 2141bis and get back = to you all. If I get an opinion to you by sometime next week, is that soon enough? Cathy Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = > On Feb 18, 2016, at 10:34 AM, John C Klensin = wrote: >=20 > Cathy, >=20 > (Barry and/or Alexey, please see the "p.s" below.) >=20 > Your review of the above document was copied to the URNBIS WG > mailing list, I think due to an AD decision that the WG should > look at new URN NID registration requests to help inform its > work going forward. In that light... >=20 > --On Wednesday, February 17, 2016 16:49 -0500 Catherine Meadows > wrote: >=20 >> ... >> In the Security Considerations section, the authors refer the >> reader to RFC's 1737 and 2141. The security considerations >> in RFC 1737 refer to authentication mechanisms which are >> outside the scope of the document. The recommendations of RFC >> 1737, however, may require more attention. Its Security >> Considerations section runs as follows: >>=20 >> This document specifies the syntax for URNs. While some >> namespaces resolvers may assign special meaning to certain >> of the characters of the Namespace Specific String, any >> security consideration resulting from such assignment are >> outside the scope of this document. It is strongly >> recommended that the process of registering a namespace >> identifier include any such considerations. >=20 > The successor to RFC 2141, draft-ietf-urnbis-rfc2141bis-urn > ("2141bis" below), has, at least IMO, a much more comprehensive > view of character and character code considerations than 2141 or > 1737. I (and I assume the WG) would appreciate your taking a > look at that, partially on the theory that you might draw the > short straw for reviewing a successor on IETF LC and it is far > easier to have a discussion and make changes before that stage > is reached (at least some of us believe that the current version > is the next-to-last before WG Last Call), but specifically to > address two questions. >=20 > (1) RFC 1737 is a 21+ year old Informational document. URNs > have evolved considerably since then. Do you think its > Security Considerations (or other) sections are sufficiently > outdated that 2141bis should explicitly update 1737 to deprecate > that section and point people to newer documents? >=20 > (2) More generally, do you think the Security Considerations > section of 2141bis are adequate? If not, what changes would you > propose or issues you would recommend addressing? You probably > should read the introductory material in 2141bis before > answering because it explains some constraints that may be > relevant. >=20 >> ... >=20 > best, > john >=20 >=20 > p.s. Barry, Alexey, I don't think the above has any significant > impact on draft-martin-urn-globus-02, so have not copied this > note to the IESG. If you disagree, feel free. That said, I > think that normative references to 1737, especially in > conjunction with the sort of handwaving in the Security > Considerations section of the present draft, are a bad idea and > should be discouraged for the reasons implied above. I don't > know whether I would recommend it or not, but, if the issue > Cathy raises are significant enough, it would be possible to > approve this draft with a normative pointer to 2141bis, let the > registration go forward, but then let this document sit in the > RFC Editor queue until 2141bis is ready for publication. >=20 --Apple-Mail=_69CB84A2-AE4A-422F-A71C-71CE4D4B2605 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sure, John, I=E2=80=99ll be happy to take a look at 2141bis = and get back to you all.  If I get an opinion to you by
sometime next week, is that soon enough?

Cathy

Catherine = Meadows
Naval Research Laboratory
Code = 5543
4555 Overlook Ave., S.W.
Washington DC, = 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.mil

On Feb 18, 2016, at 10:34 AM, John C Klensin <john-ietf@jck.com> = wrote:

Cathy,

(Barry and/or Alexey, = please see the "p.s" below.)

Your review of = the above document was copied to the URNBIS WG
mailing = list, I think due to an AD decision that the WG should
look = at new URN NID registration requests to help inform its
work= going forward.   In that light...

--On Wednesday, February 17, 2016 16:49 -0500 Catherine = Meadows
<catherine.meadows@nrl.navy.mil> wrote:
...
In = the Security Considerations section, the authors refer the
reader to RFC's 1737 and 2141.  The security = considerations
in RFC 1737 refer to authentication = mechanisms which are
outside the scope of the document. =  The recommendations of RFC
1737, however, may = require more attention.  Its Security
Considerations = section runs as follows:

This document = specifies the syntax for URNs.  While some
namespaces =    resolvers may assign special meaning to certain
of the characters of    the Namespace Specific = String, any
security consideration resulting =    from such assignment are
outside the = scope of this document.  It is    strongly
recommended that the process of registering a namespace
identifier include any such considerations.

The successor to RFC 2141, = draft-ietf-urnbis-rfc2141bis-urn
("2141bis" below), has, = at least IMO, a much more comprehensive
view of character = and character code considerations than 2141 or
1737. =  I (and I assume the WG) would appreciate your taking a
look at that, partially on the theory that you might draw = the
short straw for reviewing a successor on IETF LC and = it is far
easier to have a discussion and make changes = before that stage
is reached (at least some of us believe = that the current version
is the next-to-last before WG = Last Call), but specifically to
address two questions.

(1) RFC 1737 is a 21+ year old Informational = document.  URNs
have evolved considerably since then. =   Do you think its
Security Considerations (or = other) sections are sufficiently
outdated that 2141bis = should explicitly update 1737 to deprecate
that section = and point people to newer documents?

(2) = More generally, do you think the Security Considerations
section of 2141bis are adequate?  If not, what changes = would you
propose or issues you would recommend = addressing?  You probably
should read the = introductory material in 2141bis before
answering because = it explains some constraints that may be
relevant.

...

best,
=    john


p.s. = Barry, Alexey, I don't think the above has any significant
impact on draft-martin-urn-globus-02, so have not copied = this
note to the IESG.  If you disagree, feel free. =   That said, I
think that normative references = to 1737, especially in
conjunction with the sort of = handwaving in the Security
Considerations section of the = present draft, are a bad idea and
should be discouraged = for the reasons implied above.  I don't
know whether = I would recommend it or not, but, if the issue
Cathy = raises are significant enough, it would be possible to
approve this draft with a normative pointer to 2141bis, let = the
registration go forward, but then let this document = sit in the
RFC Editor queue until 2141bis is ready for = publication.


= --Apple-Mail=_69CB84A2-AE4A-422F-A71C-71CE4D4B2605-- From nobody Thu Feb 18 08:58:12 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456471B2DA3 for ; Thu, 18 Feb 2016 08:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 LH0LzYIPpYAb for ; Thu, 18 Feb 2016 08:58:10 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 5C5131B2CAF for ; Thu, 18 Feb 2016 08:58:10 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so79749808iom.1 for ; Thu, 18 Feb 2016 08:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ljVBmwdV31lQImVgoN/XL+5ukdKGWh2z5s1WQE8tza0=; b=fDiba7JorTyUPJVgwNBX2jCCzagI5RRinFc5QWhuap7coIsB0zuRPuDxZ8iYIvX7i7 UeTlPwAXdxTEFyKIZHmYyNriwGZL9RPQH7V21WxSFhQQI1vY9hdRlRswJdgax7UAKoEU UAJro3wHftbDdT9VmAyVVkFaiQqFDHPlPepB4/6pTgOG0ifJjGcU+ChS0px2LLKxZ8KA oo8DSsWR788P2RJ6YXiNfxs8SZkQB+OP8NQVrbX7oahlzW9BAxVxQMGs2VVoHAxx7fj8 P4VR8oC5HfRKEp4AlJgUCTbYVb8rjH+nuXLGeKsPiHil2tPTMFcvexhOUVCsRI5QYq1S ZRUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ljVBmwdV31lQImVgoN/XL+5ukdKGWh2z5s1WQE8tza0=; b=AMHOrYbApLz0bpU9itl+txx0pG6dslxSpijfDIg9Puhxg23Pe6tN5S+9mdtlekI0FU hCkk+sPcyJYshDxWcoG5Ja2fI//AMDhdhYPoCkDLP12ApqEOhJketrOgZ5TQzERrdXD7 TTTV2KbeXAOAjx3WH/D2onPEMKugwVoHCa8MyEg4GQ+xj0pv2X0tLI66l6s8xuq9EubU Mih6wMmhRGM99YzBVsKa+aGA5dKinO99ahIPfulzCg0kZKHg9PaPyXVUf9laUJhHrzVB 846aS8CWiCTNvZgAO43PNcjx9Taf4en2rcoKU00yXz0cyU3OzST4/gjFcGVH7hEoxrj2 EhJA== X-Gm-Message-State: AG10YOTUPDcYkIGXqUFR9L8FNemUUi+15jwx3I/b1i9hazOhBiqWUa5WINCnMMhTBbfyfe10+CfWbTIsmlTPdQ== MIME-Version: 1.0 X-Received: by 10.107.12.14 with SMTP id w14mr12089797ioi.8.1455814689829; Thu, 18 Feb 2016 08:58:09 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.156.5 with HTTP; Thu, 18 Feb 2016 08:58:09 -0800 (PST) In-Reply-To: References: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> Date: Thu, 18 Feb 2016 08:58:09 -0800 X-Google-Sender-Auth: CM1QDJ862hMPEnuD8gpLjPDgfVw Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" , Catherine Meadows , Alexey Melnikov Subject: Re: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:58:11 -0000 > p.s. Barry, Alexey, I don't think the above has any significant > impact on draft-martin-urn-globus-02, so have not copied this > note to the IESG. If you disagree, feel free. That said, I > think that normative references to 1737, especially in > conjunction with the sort of handwaving in the Security > Considerations section of the present draft, are a bad idea and > should be discouraged for the reasons implied above. I don't > know whether I would recommend it or not, but, if the issue > Cathy raises are significant enough, it would be possible to > approve this draft with a normative pointer to 2141bis, let the > registration go forward, but then let this document sit in the > RFC Editor queue until 2141bis is ready for publication. I would not like to have this registration be dependent upon the publication of 2141bis, however imminent we think that might be. On the other hand, the actual registration is done at IESG approval, and doesn't wait for RFC publication, so maybe that's good enough. Better, though, might be to think about what security considerations actually need to be in this document, and to put them in, and not rely on pointers. We've been doing many, many URN namespace registrations with security considerations that just point to 2141, and I can't really imagine why this one is any different. Barry From nobody Thu Feb 18 11:00:43 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2111B31E6 for ; Thu, 18 Feb 2016 11:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 zCgL_dHkNfH1 for ; Thu, 18 Feb 2016 11:00:40 -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 3607F1B31D7 for ; Thu, 18 Feb 2016 11:00:39 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aWToU-000Ga0-7c; Thu, 18 Feb 2016 14:00:30 -0500 Date: Thu, 18 Feb 2016 14:00:25 -0500 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: References: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> 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: Cc: urn@ietf.org, Catherine Meadows , Alexey Melnikov Subject: Re: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:00:41 -0000 --On Thursday, February 18, 2016 08:58 -0800 Barry Leiba wrote: >> p.s. Barry, Alexey, I don't think the above has any >> significant impact on draft-martin-urn-globus-02, so have not >> copied this note to the IESG. If you disagree, feel free. >> That said, I think that normative references to 1737, >> especially in conjunction with the sort of handwaving in the >> Security Considerations section of the present draft, are a >> bad idea and should be discouraged for the reasons implied >> above. I don't know whether I would recommend it or not, >> but, if the issue Cathy raises are significant enough, it >> would be possible to approve this draft with a normative >> pointer to 2141bis, let the registration go forward, but then >> let this document sit in the RFC Editor queue until 2141bis >> is ready for publication. > > I would not like to have this registration be dependent upon > the publication of 2141bis, however imminent we think that > might be. On the other hand, the actual registration is done > at IESG approval, and doesn't wait for RFC publication, so > maybe that's good enough. That is exactly what I was thinking. Whether it is a good idea to hold the published document is a separate question and one I'm happy to leave to the IESG's judgment. > Better, though, might be to think about what security > considerations actually need to be in this document, and to > put them in, and not rely on pointers. We've been doing many, > many URN namespace registrations with security considerations > that just point to 2141, and I can't really imagine why this > one is any different. Indeed. And, depending on how Cathy feels about this one, I'd actually be happier if the pointer to 1737 was dropped and that the globus document simply referenced 2141 and supplied whatever other information is needed explicitly. A reference to 2141bis is a plausible alternative, IMO, but that gets tied up with the issue above. john From nobody Thu Feb 18 11:02:00 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFA1B2E94 for ; Thu, 18 Feb 2016 11:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 k1QpdDc39a4v for ; Thu, 18 Feb 2016 11:01:49 -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 707971B2CDF for ; Thu, 18 Feb 2016 11:01:49 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aWTpk-000Gak-Cl; Thu, 18 Feb 2016 14:01:48 -0500 Date: Thu, 18 Feb 2016 14:01:43 -0500 From: John C Klensin To: Catherine Meadows Message-ID: <95A17F65C12FBC66101671D6@JcK-HP8200.jck.com> In-Reply-To: References: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> 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: Cc: Alexey Melnikov , urn@ietf.org, Barry Leiba Subject: Re: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 19:01:53 -0000 --On Thursday, February 18, 2016 11:33 -0500 Catherine Meadows wrote: > Sure, John, I'll be happy to take a look at 2141bis and get > back to you all. If I get an opinion to you by sometime next > week, is that soon enough? Yes, sometime next week would be great. I wish the volume of comments on the WG list were such that I could make an argument for tomorrow (or yesterday), but it hasn't been. thanks, john From nobody Fri Feb 19 04:32:21 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8A1B2D1B for ; Fri, 19 Feb 2016 04:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 KpVf26SV2yCx for ; Fri, 19 Feb 2016 04:32:18 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6D41B2B3C for ; Fri, 19 Feb 2016 04:32:18 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DC8FF509BD; Fri, 19 Feb 2016 07:32:16 -0500 (EST) To: urn@ietf.org References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> From: Sean Leonard Message-ID: <56C70B14.60702@seantek.com> Date: Fri, 19 Feb 2016 04:31:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010909030005010307010705" Archived-At: Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 12:32:20 -0000 This is a multi-part message in MIME format. --------------010909030005010307010705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Yes, rely on mappings... There is another issue, namely that media types define parameters, some=20 of which may be required for interoperability. For example, "text/plain; = charset=3DUTF-8" will be interpreted differently (in a way that matters a= =20 lot) than "text/plain" or "text/plain; charset=3Diso-8859-15". It would be a straightforward mapping to say=20 , but the parameters present a=20 significant challenge. I would suggest defining the protocol slot to be=20 "media type" in the first place, in which case you can tack on the=20 parameters after the ; delimiter like normal. If you are trying to stuff = a different, or validated, media type compared to the resource that the=20 URI is pointing to, you can use ni: (RFC 6920) or data: (RFC 2397), or=20 you can invent your own URI scheme. Sean On 2/5/2016 9:54 AM, Ted Hardie wrote: > I've added Graham Klyne, because he worked on RDF representations of=20 > IETF media types during the content negotiation work many years ago. > > Theory states that you could register these are protocol parameters=20 > under the registry set up in RFC 3553=20 > (http://www.iana.org/assignments/params/params.xhtml#params-1), but I=20 > think you would find that you'd basically have to create the mappings=20 > rather than rely on a set already in place. > > regards, > > Ted Hardie > > On Fri, Feb 5, 2016 at 2:46 AM, Martin J. D=FCrst=20 > > wrote: > > Hello Carsten, > > I think the issue below has come up repeatedly in different > groups, but probably never got enough traction. Unfortunately, I > can't remember any details, but you should probably find something > if you dig deeper, either for using URNs or for using URLs. > > Sorry for not being of more help. > > Regards, Martin. > > > On 2016/01/27 23:10, Carsten Bormann wrote: > > In W3C WoT IG, we are looking at employing RDF to represent > information > that is today often held in Web links (RFC 6690, RFC 5988). > That includes media types, but also maybe link relation types > and other > registry content. > It would be great to have a canonical mapping to URIs for all > these. > Has there been any attempt in the past to define, say, URNs > for media types? > Any other advice on how to obtain stable URIs for protocol > constants? > (I don't think we want to use the URL to the IANA registry page= =2E) > > Gr=FC=DFe, Carsten > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn --------------010909030005010307010705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Yes, rely on mappings...

There is another issue, namely that media types define parameters, some of which may be required for interoperability. For example, "text/plain; charset=UTF-8" will be interpreted differently (in a way that matters a lot) than "text/plain" or "text/plain; charset=iso-8859-15".

It would be a straightforward mapping to say <urn:ietf:params:mt:text/plain>, but the parameters present a significant challenge. I would suggest defining the protocol slot to be "media type" in the first place, in which case you can tack on the parameters after the ; delimiter like normal. If you are trying to stuff a different, or validated, media type compared to the resource that the URI is pointing to, you can use ni: (RFC 6920) or data: (RFC 2397), or you can invent your own URI scheme.

Sean

On 2/5/2016 9:54 AM, Ted Hardie wrote:
I've added Graham Klyne, because he worked on RDF representations of IETF media types during the content negotiation work many years ago.

Theory states that you could register these are protocol parameters under the registry set up in RFC 3553 (http://www.iana.org/assignments/params/params.xhtml#params-1), but I think you would find that you'd basically have to create the mappings rather than rely on a set already in place.

regards,

Ted Hardie

On Fri, Feb 5, 2016 at 2:46 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
Hello Carsten,

I think the issue below has come up repeatedly in different groups, but probably never got enough traction. Unfortunately, I can't remember any details, but you should probably find something if you dig deeper, either for using URNs or for using URLs.

Sorry for not being of more help.

Regards,   Martin.


On 2016/01/27 23:10, Carsten Bormann wrote:
In W3C WoT IG, we are looking at employing RDF to represent information
that is today often held in Web links (RFC 6690, RFC 5988).
That includes media types, but also maybe link relation types and other
registry content.
It would be great to have a canonical mapping to URIs for all these.
Has there been any attempt in the past to define, say, URNs for media types?
Any other advice on how to obtain stable URIs for protocol constants?
(I don't think we want to use the URL to the IANA registry page.)

Grüße, Carsten

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn



_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn

--------------010909030005010307010705-- From nobody Fri Feb 19 06:56:40 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36BE1B2D42 for ; Fri, 19 Feb 2016 06:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 87zNUiqSdxDr for ; Fri, 19 Feb 2016 06:56:36 -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 4A9CE1B2CC6 for ; Fri, 19 Feb 2016 06:56:36 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aWmTz-000KHC-1U; Fri, 19 Feb 2016 09:56:35 -0500 Date: Fri, 19 Feb 2016 09:56:30 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: In-Reply-To: <56C70B14.60702@seantek.com> References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> <56C70B14.60702@seantek.com> 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 for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:56:39 -0000 Hi. Partially because this WG is years overdue on its primary task, when I read through the comments below, what I mostly hear is a difficult and controversial task and area trying to suck us into a huge rat hole, and to drag everything else we are doing (like 2141bis) into the hole with it. So I'd like to see (and recommend) if this can simply be ruled out of scope, at least until the three current documents are complete and finished with IETF Last Call. In addition to the comments that have been made already, it may be useful to remember the following: (i) Even though this thread started in a W3C discussion, there remain a number of leaders in the W3C community who are unalterably opposed to URNs and the URN concept. It appears to me that opposition has become sufficiently much of a religious issue that, even if we were to define a model for handling media types as URNs, they would be unlikely to willingly adopt them, perhaps pushing instead for a media-type-specific URI scheme. (ii) We've been pushed several times by people in IETF circles to define the limits of URNs (possibly even at what 2141 permits) and encourage the development of other URI schemes, even if they are name-like rather than locator-like, for situations that don't fit. I think those two comments are consistent with Sean's remarks but, for me right now, I just hope we can keep this discussion out of the critical path of this WG. People who have read so far are reminded that 2141bis-15 was posted about two weeks ago and we have not seen a single substantive comment on the list since. Does that imply that we are ready for WG Last Call on it (or on a slightly revised version to correct a few minor editorial errors)? john --On Friday, February 19, 2016 04:31 -0800 Sean Leonard wrote: > Yes, rely on mappings... >=20 > There is another issue, namely that media types define > parameters, some of which may be required for > interoperability. For example, "text/plain; charset=3DUTF-8" > will be interpreted differently (in a way that matters a lot) > than "text/plain" or "text/plain; charset=3Diso-8859-15". >=20 > It would be a straightforward mapping to say > , but the parameters present a > significant challenge. I would suggest defining the protocol > slot to be "media type" in the first place, in which case you > can tack on the parameters after the ; delimiter like normal. > If you are trying to stuff a different, or validated, media > type compared to the resource that the URI is pointing to, you > can use ni: (RFC 6920) or data: (RFC 2397), or you can invent > your own URI scheme. >=20 > Sean >=20 > On 2/5/2016 9:54 AM, Ted Hardie wrote: >> I've added Graham Klyne, because he worked on RDF >> representations of IETF media types during the content >> negotiation work many years ago. >>=20 >> Theory states that you could register these are protocol >> parameters under the registry set up in RFC 3553=20 >> (http://www.iana.org/assignments/params/params.xhtml#params-1 >> ), but I think you would find that you'd basically have to >> create the mappings rather than rely on a set already in >> place. >>=20 >> regards, >>=20 >> Ted Hardie >>=20 >> On Fri, Feb 5, 2016 at 2:46 AM, Martin J. D=C3=BCrst=20 >> > >> wrote: >>=20 >> Hello Carsten, >>=20 >> I think the issue below has come up repeatedly in >> different groups, but probably never got enough traction. >> Unfortunately, I can't remember any details, but you >> should probably find something if you dig deeper, either >> for using URNs or for using URLs. >>=20 >> Sorry for not being of more help. >>=20 >> Regards, Martin. >>=20 >>=20 >> On 2016/01/27 23:10, Carsten Bormann wrote: >>=20 >> In W3C WoT IG, we are looking at employing RDF to >> represent information >> that is today often held in Web links (RFC 6690, RFC >> 5988). That includes media types, but also maybe link >> relation types and other >> registry content. >> It would be great to have a canonical mapping to URIs >> for all these. >> Has there been any attempt in the past to define, >> say, URNs for media types? >> Any other advice on how to obtain stable URIs for >> protocol constants? >> (I don't think we want to use the URL to the IANA >> registry page.) >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >>=20 >>=20 >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn >=20 From nobody Sat Feb 20 20:46:37 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1241B1ACED3 for ; Sat, 20 Feb 2016 20:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 KBM4zXNmFoE0 for ; Sat, 20 Feb 2016 20:46:35 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124371A0130 for ; Sat, 20 Feb 2016 20:46:35 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DB8BB509BB for ; Sat, 20 Feb 2016 23:46:33 -0500 (EST) To: urn@ietf.org References: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56C940ED.7050709@seantek.com> Date: Sat, 20 Feb 2016 20:45:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] ReL draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 04:46:36 -0000 On 2/13/2016 6:49 AM, John C Klensin wrote: > Hi. > > Writing primarily as the pen-holding editor for -15 and the > likely one for -16.... John and Peter (and other editors/contributors), thank you for your service. Okay so I finally combed through the new documents, and have feedback that you are requesting. I believe it is best to send a few concise e-mails rather than a big long one, so that is what I will do. Sean From nobody Sat Feb 20 21:11:07 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203961AD1F5 for ; Sat, 20 Feb 2016 21:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=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 oSOm-rzAmoDW for ; Sat, 20 Feb 2016 21:11:05 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B93F1A1B21 for ; Sat, 20 Feb 2016 21:11:05 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1BC0F509BD for ; Sun, 21 Feb 2016 00:11:03 -0500 (EST) To: urn@ietf.org References: From: Sean Leonard Message-ID: <56C946AC.8090402@seantek.com> Date: Sat, 20 Feb 2016 21:10:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Editorial Re: draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 05:11:06 -0000 Editorial issues for urnbis-rfc2141bis-urn-15: Several dots that do not function as periods are followed by two spaces, e.g., Section 1.1: "their uses outlined (Cf. [RFC 1737]) issues of persistent identifiers". I suspect this is an artifact of the xml2rfc process, but it's not good and should be squelched. Section 2.1: NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent) as a consequence of requirements imposed by RFC 3986. That is not actually true. The entire NID : NSS production conforms to the path-rootless rule; paths are case-sensitive at the URI level of abstraction. (Specific schemes can make parts of the path case-insensitive.) You might be confusing this with the host rule, which is case-insensitive (RFC 3986 Section 3.2.2). I am calling this "editorial" simply because that new text about RFC 3986 is not accurate about RFC 3986. Section 2.3: Interpretation of r-components is discused in Section 2.3.2 below. Change to: The interpretation of r-components is discussed in Section 2.3.2 below. Section 6.1: 2. The syntax of URNs assigned within the namespace, including the internal syntax and anticipated effects of q-components or r-components (syntax and interpretation of f-components appears in RFC 3986). "The" is needed in the parenthetical. I would prefer this to read: 2. The syntax of URNs assigned within the namespace, including the internal syntax and anticipated effects of q-components or r-components. The syntax and interpretation of f-components appears in RFC 3986. (Actually I take issue with this item on a technical basis, but I shall save that for my non-editorial e-mail.) Sean On 2/4/2016 5:31 AM, John C Klensin wrote: > Please review. From nobody Sat Feb 20 21:24:03 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8FF1B30AB for ; Sat, 20 Feb 2016 21:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 PojQwe_WOU8m for ; Sat, 20 Feb 2016 21:24:00 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C991B30A5 for ; Sat, 20 Feb 2016 21:24:00 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1A383509BB for ; Sun, 21 Feb 2016 00:23:58 -0500 (EST) To: urn@ietf.org References: <4562EADF0DFB9E2C1304337A@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56C949B2.9070004@seantek.com> Date: Sat, 20 Feb 2016 21:22:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <4562EADF0DFB9E2C1304337A@JcK-HP8200.jck.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [urn] Editorial Re: draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 05:24:01 -0000 On 2/6/2016 11:41 AM, John C Klensin wrote: > I've just posted a new version of > draft-ietf-urnbis-semantics-clarif, largely because -02 was > scheduled to expire next week. I have gone through it and > updated some of the text to reflect the last few versions is > 2141bis, e.g., by dropping comments about p-components and > mentioning r-components. I've also tidied up the language and > explanations in several places. Editorial review of urnbis-semantics-clarif-03: Section 1: requiremnts -> requirements Appendix B.3: discused -> discussed Appendix B.5: oMade a few substantive updates to reflect evolution in 2141bis, particularly the elimination of p-component as a separate category and the added distinction between q-component and r-component.. Remove second period. I honestly do not see the need for Section 8. IANA Considerations. This=20 document is something of a missive; it does not define an actionable=20 (technically implementable) standard so I believe it can dispense with=20 the general advice that the majority of RFCs ought to have IANA=20 Considerations sections. Sean From nobody Sat Feb 20 21:24:14 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928F91B30EF for ; Sat, 20 Feb 2016 21:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 5Ste2hXwZVFj for ; Sat, 20 Feb 2016 21:24:12 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC561B30F1 for ; Sat, 20 Feb 2016 21:24:12 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 390ED509BD for ; Sun, 21 Feb 2016 00:24:11 -0500 (EST) To: urn@ietf.org References: <655C976223FCCC2DE6251563@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56C949BF.1030107@seantek.com> Date: Sat, 20 Feb 2016 21:23:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <655C976223FCCC2DE6251563@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] draft-ietf-urnbis-ns-reg-transition X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 05:24:13 -0000 From my perspective, this one is okay. I did not find any nits to pick, = other than that the document seems mostly to be a matter of housekeeping = for existing registrations (and I cannot think of any additional=20 registrations to update). However, this document raises a novel issue in my mind, which I will=20 spin up under a separate thread. Sean On 2/7/2016 2:34 PM, John C Klensin wrote: > Hi. > > draft-ietf-urnbis-ns-reg-transition-06 is now in the posting > queue. As compared to the previous version, it has updated > references, an explicit reference to the IANA URN namespace > registry, and some minor editorial tuning. > > We will eventually need to come back to this document after the > 2141bis registration template is complete (see prior note about > reviewing that template in 2141bis-15) and we are ready to move > forward, but probably time can be better spent now than on > review this document. The one important exception is that, if > anyone has (or knows of) existing registrations that could > usefully be changed to reflect the new model, this would be the > right time to start thinking about them, if only because minor > patches could be made as part of this I-D without requiring new > documents. > > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sun Feb 21 07:30:45 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12F81B32EB for ; Sun, 21 Feb 2016 07:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.401 X-Spam-Level: *** X-Spam-Status: No, score=3.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, MANGLED_OFF=2.3] autolearn=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 ld4xf0j59Kk7 for ; Sun, 21 Feb 2016 07:30:42 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FF01B32E4 for ; Sun, 21 Feb 2016 07:30:41 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXVy1-000PAl-C2; Sun, 21 Feb 2016 10:30:37 -0500 Date: Sun, 21 Feb 2016 10:30:32 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <59DCB1F7C5F5908773EFBF11@JcK-HP5.jck.com> In-Reply-To: <56C946AC.8090402@seantek.com> References: <56C946AC.8090402@seantek.com> 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 Archived-At: Subject: Re: [urn] Editorial Re: draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 15:30:44 -0000 --On Saturday, February 20, 2016 9:10 PM -0800 Sean Leonard wrote: > Editorial issues for urnbis-rfc2141bis-urn-15: > > Several dots that do not function as periods are followed by > two spaces, e.g., Section 1.1: "their uses outlined (Cf. [RFC > 1737]) issues of persistent identifiers". I suspect this is an > artifact of the xml2rfc process, but it's not good and should > be squelched. Thanks. You can take this up on the rfc-interest or xml2rfc list if you like. Those sorts of issue are supposed to be XML stylesheet matters and, even if we went to the trouble to patch around it now (and I/we could figure out how), the risk would be high that things would be fouled up again the next time I hand off to Peter (we are using different tools) or we hand off to the RFC Editor. I have inserted a comment to the latter into the XML to remind them to pay attention to this. > > Section 2.1: > NIDs are case insensitive (e.g., "ISBN" and "isbn" are > equivalent) as > a consequence of requirements imposed by RFC 3986. > > That is not actually true. The entire NID : NSS production > conforms to the path-rootless rule; paths are case-sensitive > at the URI level of abstraction. (Specific schemes can make > parts of the path case-insensitive.) You might be confusing > this with the host rule, which is case-insensitive (RFC 3986 > Section 3.2.2). I am calling this "editorial" simply because > that new text about RFC 3986 is not accurate about RFC 3986. But the rule about case-insensitivity in NIDs goes back to 2141 and earlier. What fix would you like to see? I could insert a sentence (probably starting "Nonetheless...") in the discussion of the relationship to 3986, but I'm not at all confident that would be satisfactory. Suggested text would be appreciated. > Section 2.3: > > Interpretation of r-components is discused in > Section 2.3.2 below. > > Change to: > The interpretation of r-components is discussed in Section > 2.3.2 below. I can argue this either way and materials above it are a tad inconsistent, but I've changed the working copy to reflect the above. However, the change comes with the warning that it is quite possible that the RFC Editor will undo the change or make other changes and the odds of our (or at least my) fighting them about it are about zero). > Section 6.1: > > 2. The syntax of URNs assigned within the namespace, > including the iinternal syntax and anticipated effects of > q-components or r-components (syntax and interpretation of > f-components appears in RFC 3986). > "The" is needed in the parenthetical. I would prefer this to > read: > > 2. The syntax of URNs assigned within the namespace, > including the internal syntax and anticipated effects of > q-components or r-components. The syntax and interpretation > of f-components appears in RFC 3986. Changed as indicated. Note to others: in future, comments like this are likely to turn into "please see how you feel about this" notes to the RFC Editor. >... john From nobody Sun Feb 21 07:42:16 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86301AD33F for ; Sun, 21 Feb 2016 07:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 1_M52QpXcHMv for ; Sun, 21 Feb 2016 07:42:14 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23781AC82C for ; Sun, 21 Feb 2016 07:42:13 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A5F89509BB for ; Sun, 21 Feb 2016 10:42:12 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <56C9DA98.3010905@seantek.com> Date: Sun, 21 Feb 2016 07:41:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [urn] Full review of urnbis-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 15:42:15 -0000 This is a full technical review of urnbis-15. While Section 1.1 Specificity and This Standard feels long-winded, I can = at least appreciate and applaud the attempt to grapple with the tensions = that have plagued this work. For the final publication, this section=20 should be made more concise. Of these paragraphs: The first paragraph is a bit convoluted but I agree with the technical=20 content. The second paragraph is convoluted and tries hard to thumb off what=20 "resolution" means. In this regard, it only adds vagueness without=20 substantial technical merit. There is no such thing as "URL resolution", = at least from the standpoint of RFC 3986. There is only URI=20 dereferencing. Section 1.2 Terminology needs to precede Section 1.1=20 Specificy and This Standard, because Section 1.2 actually discusses=20 resolution versus dereferencing, and introduces the concept of URL as=20 distinguished from the generic RFC 3986 URI case. Paragraph 3 is technically on the money. I believe an example either in=20 Paragraph 3 or in Section 2.2 (or in its own section) would be helpful.=20 Consider: when encoding a whole number (i.e., nonnegative integer), the=20 URN namespace can encode the number 65535 as: urn:foo:65535 urn:foo:FFFF urn:foo:ffFf urn:foo:177777 urn:foo:=EF=BC=96=EF=BC=95=EF=BC=95=EF=BC=93=EF=BC=95 (not actually in= a URI protocol slot--this would=20 be in a IRI protocol slot) urn:foo:%EF%BC%96%EF%BC%95%EF%BC%95%EF%BC%93%EF%BC%95 The point being...URN constrains the representation and encoding of the=20 unique identifier, but the namespace still has wide latitude to map the=20 identifier to ASCII or Unicode code points, so long as that mapping is=20 deterministic and bijective. At the same time, Paragraph 3 is a bit overstated. The main problem is=20 in NSS. NID is ASCII-only. As of draft-15, resolverID is also ASCII-only = (unless you plan on encoding something in Punycode!), and r-component=20 appears to be a cop-out. We can't help f-component or q-component=20 because the URI spec governs those. Paragraph 4 is an extremely long sentence. It can be made more concise,=20 or removed for publication. *** I agree that "described in [RFC2483]" is better than "defined in=20 [RFC2483]", as it implies that RFC 2483 is on-the-out (although, out of=20 scope for this WG). *** This is an editorial comment with technical implications: Section 2 says "...extend the URN syntax to natively allow characters=20 outside the ASCII range..." "to natively allow" is a split infinitive. Put "natively" somewhere else = in that sentence. That being said, the technical implication is that URN syntax could--in=20 a different world--"natively allow characters outside the ASCII range".=20 I do not know what is native and what is non-native. Since we are=20 talking about changes since RFC 2141, I do not perceive this=20 specification is doing anything really different. I would axe this=20 paragraph entirely. What matters is the technical content of Section 2.2 = NSS regarding UTF-8. The technical changes about q-component and r-component warrant their=20 own e-mail. Section 2.3.3: f-component The changes are fine, except for one thing: The f-component MUST NOT be passed to resolution services -> Clients SHOULD NOT pass f-components to resolution servers unless [...] I see what is trying to be done here. At the same time, I think that it=20 fudges on the component model. Look, you can make a web browser that=20 operates on the "client side" (where the client retrieves the HTML and=20 image bits from the Internet, and then turns them into pixels on a=20 display) or on the "server side" (where the server retrieves the HTML=20 and image bits, turns them into pixels, and then blits them to a remote=20 viewer over the Internet, whether that is a low-power device or a remote = desktop or some kind--even if that blitting protocol runs over HTTP).=20 That does not really affect the constituent protocols of web browsers=20 (HTTP, HTML, image formats, WebSockets, etc.). Resolution services should be defined as those components that take the=20 relevant parts of a URN and transform the data into "resolved" results.=20 The relevant parts of the URN are the NID, NSS, and r-component.=20 Irrelevant parts of the URN are q-component and f-component. Therefore,=20 if a service happens to be implemented more comprehensively, it is like=20 the web-browser-on-the-server that I indicated. The service has a URN=20 resolver *component*, plus other *components* that are doing=20 URN-to-resource things. I would therefore stick with the -14 wording of "MUST NOT", and better=20 define resolution services (or components) accordingly. The registration sections (6 and 7) are okay. Sean From nobody Sun Feb 21 07:44:32 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029E21B32F4 for ; Sun, 21 Feb 2016 07:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 42GoLRu9do8N for ; Sun, 21 Feb 2016 07:44:29 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6AE1B32F3 for ; Sun, 21 Feb 2016 07:44:29 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2F335509BE; Sun, 21 Feb 2016 10:44:27 -0500 (EST) To: John C Klensin , urn@ietf.org References: <56C946AC.8090402@seantek.com> <59DCB1F7C5F5908773EFBF11@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <56C9DB20.5090509@seantek.com> Date: Sun, 21 Feb 2016 07:43:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <59DCB1F7C5F5908773EFBF11@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Editorial Re: draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 15:44:31 -0000 On 2/21/2016 7:30 AM, John C Klensin wrote: > > --On Saturday, February 20, 2016 9:10 PM -0800 Sean Leonard > wrote: > >> Editorial issues for urnbis-rfc2141bis-urn-15: >> >> Several dots that do not function as periods are followed by >> two spaces, e.g., Section 1.1: "their uses outlined (Cf. [RFC >> 1737]) issues of persistent identifiers". I suspect this is an >> artifact of the xml2rfc process, but it's not good and should >> be squelched. > Thanks. You can take this up on the rfc-interest or xml2rfc > list if you like. Those sorts of issue are supposed to be XML > stylesheet matters and, even if we went to the trouble to patch > around it now (and I/we could figure out how), the risk would be > high that things would be fouled up again the next time I hand > off to Peter (we are using different tools) or we hand off to > the RFC Editor. I have inserted a comment to the latter into > the XML to remind them to pay attention to this. Okay. It may be that "Cf." is the problem, instead of "cf." (lowercase). I have reason to believe that some abbreviations such as "cf." and "i.e." have manual overrides in the source code. >> Section 2.1: >> NIDs are case insensitive (e.g., "ISBN" and "isbn" are >> equivalent) as >> a consequence of requirements imposed by RFC 3986. >> >> That is not actually true. The entire NID : NSS production >> conforms to the path-rootless rule; paths are case-sensitive >> at the URI level of abstraction. (Specific schemes can make >> parts of the path case-insensitive.) You might be confusing >> this with the host rule, which is case-insensitive (RFC 3986 >> Section 3.2.2). I am calling this "editorial" simply because >> that new text about RFC 3986 is not accurate about RFC 3986. > But the rule about case-insensitivity in NIDs goes back to 2141 > and earlier. What fix would you like to see? I could insert a > sentence (probably starting "Nonetheless...") in the discussion > of the relationship to 3986, but I'm not at all confident that > would be satisfactory. Suggested text would be appreciated. Suggested: NIDs are case-insensitive. No reference to RFC 3986. Also the example is not terribly illuminating. We know what case-sensitivity is. Sean From nobody Sun Feb 21 07:51:08 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E71B2D2A for ; Sun, 21 Feb 2016 07:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=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 NZgEur_NCLDK for ; Sun, 21 Feb 2016 07:51:06 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0191A88AD for ; Sun, 21 Feb 2016 07:51:05 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXWHn-000PEw-95; Sun, 21 Feb 2016 10:51:03 -0500 Date: Sun, 21 Feb 2016 10:50:58 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <83BFD0D520FEC2411F332211@JcK-HP5.jck.com> In-Reply-To: <56C949B2.9070004@seantek.com> References: <4562EADF0DFB9E2C1304337A@JcK-HP8200.jck.com> <56C949B2.9070004@seantek.com> 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 Archived-At: Subject: Re: [urn] Editorial Re: draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 15:51:07 -0000 --On Saturday, February 20, 2016 9:22 PM -0800 Sean Leonard wrote: >... > Editorial review of urnbis-semantics-clarif-03: > > Section 1: > requiremnts -> requirements > > Appendix B.3: > discused -> discussed > > Appendix B.5: > > oMade a few substantive updates to reflect evolution in > 2141bis, > > particularly the elimination of p-component as a separate > category > > and the added distinction between q-component and r-component.. > > > Remove second period. Changes above made. Thanks for the careful reading, but these are the sorts of things than can normally be left to the RFC Editor to find and fix. > I honestly do not see the need for Section 8. IANA > Considerations. This document is something of a missive; it > does not define an actionable (technically implementable) > standard so I believe it can dispense with the general advice > that the majority of RFCs ought to have IANA Considerations > sections. First, if the IANA Considerations section is removed at this point, the automated posting and nit-finding tools will complain and reject the document. If you think the requirement to have it, even if it says "nothing required, please remove before publication", is unreasonable, take it up with IANA and the IESG but I can tell you that, in prior years, the judgment and experience was that leaving it out of I-Ds resulted in far more problems than the noise of having it there. Second, the second paragraph is actually substantive in the sense that it is common for IANA to come back during their pre-publication check and say "this seems to change what should be in the registry; what should be done with the old entries?" Providing an answer to that question in the document saves quite a bit of otherwise-wasted time. Personal opinion: To some extent, the above, and maybe your "missive" comment, argue for collapsing the substance into 2141bis. IIR, the WG has decided to keep them separate, at least for the present, because merging them would create a risk of introducing errors and arguing about what can be dropped entirely would take (IMO, waste) a lot of time. FWIW, if we weren't years overdue, I'd feel differently about this but, right now, I think we should get documents that are clear and correct technically finished, approved, and out ASAP and defer even spending time on this type of editorial/ document organization issue for a Full Standard 2141ter (if there is ever the energy to produce that). However, this type of issue is up to the WG Co-Chairs, whom I hope will speak up. john From nobody Sun Feb 21 08:03:40 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657921B33C3 for ; Sun, 21 Feb 2016 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=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 ATfu7n1FpotQ for ; Sun, 21 Feb 2016 08:03:37 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D651B33C2 for ; Sun, 21 Feb 2016 08:03:37 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXWTu-000PFZ-Vl; Sun, 21 Feb 2016 11:03:34 -0500 Date: Sun, 21 Feb 2016 11:03:29 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <27D17E47D74ADD149F376B58@JcK-HP5.jck.com> In-Reply-To: <56C9DB20.5090509@seantek.com> References: <56C946AC.8090402@seantek.com> <59DCB1F7C5F5908773EFBF11@JcK-HP5.jck.com> <56C9DB20.5090509@seantek.com> 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 Archived-At: Subject: Re: [urn] Editorial Re: draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 16:03:38 -0000 --On Sunday, February 21, 2016 7:43 AM -0800 Sean Leonard wrote: > On 2/21/2016 7:30 AM, John C Klensin wrote: >> >> --On Saturday, February 20, 2016 9:10 PM -0800 Sean Leonard >> wrote: >> >>> Editorial issues for urnbis-rfc2141bis-urn-15: >>> >>> Several dots that do not function as periods are followed by >>> two spaces, e.g., Section 1.1: "their uses outlined (Cf. >>> [RFC 1737]) issues of persistent identifiers". I suspect >>> this is an artifact of the xml2rfc process, but it's not >>> good and should be squelched. >> Thanks. You can take this up on the rfc-interest or xml2rfc >> list if you like. Those sorts of issue are supposed to be XML >> stylesheet matters and, even if we went to the trouble to >> patch around it now (and I/we could figure out how), the risk >> would be high that things would be fouled up again the next >> time I hand off to Peter (we are using different tools) or we >> hand off to the RFC Editor. I have inserted a comment to the >> latter into the XML to remind them to pay attention to this. > > Okay. It may be that "Cf." is the problem, instead of "cf." > (lowercase). I have reason to believe that some abbreviations > such as "cf." and "i.e." have manual overrides in the source > code. But that is part of my point because "the source code" is not am unambiguous reference because it could be "source code of the version Peter is using, source code of the version I'm using, source code of today's online version, source code for v3, etc. WG co-chairs: please either overrule me (in which case I'll try to replace all of the relevant periods with an XML entity when I find/ get a round tuit) or rule further discussion along these lines out of order. >>> Section 2.1: >>> NIDs are case insensitive (e.g., "ISBN" and "isbn" are >>> equivalent) as >>> a consequence of requirements imposed by RFC 3986. >>> >>> That is not actually true. The entire NID : NSS production >>> conforms to the path-rootless rule; paths are case-sensitive >>> at the URI level of abstraction. (Specific schemes can make >>> parts of the path case-insensitive.) You might be confusing >>> this with the host rule, which is case-insensitive (RFC 3986 >>> Section 3.2.2). I am calling this "editorial" simply because >>> that new text about RFC 3986 is not accurate about RFC 3986. >> But the rule about case-insensitivity in NIDs goes back to >> 2141 and earlier. What fix would you like to see? I could >> insert a sentence (probably starting "Nonetheless...") in the >> discussion of the relationship to 3986, but I'm not at all >> confident that would be satisfactory. Suggested text would >> be appreciated. > > Suggested: > NIDs are case-insensitive. > > > No reference to RFC 3986. Also the example is not terribly > illuminating. We know what case-sensitivity is. Reference to 3986 dropped unless someone else objects (my vague recollection is that we were told, at one state, to put it in). Same for the example so I'm disinclined to remove it unless others think it is a problem. john From nobody Sun Feb 21 09:05:55 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71881A6F90 for ; Sun, 21 Feb 2016 09:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 s0THox_hF5kN for ; Sun, 21 Feb 2016 09:05:53 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 D08D71A01F0 for ; Sun, 21 Feb 2016 09:05:52 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id g6so71449339igt.1 for ; Sun, 21 Feb 2016 09:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ScwcVshDOhxBhhXf0pm+5LDjbB5GDbD8FGtt4qSCsug=; b=CH+Ka6JenBV9DXjFKbHUlX6kd6mlHD7zJz4eYIlNs+qxE9qj1VJEZRyjCyo2XdwoVh StbyCLRtOYC3rFBE/XDjhBpjuicDpL0MZfX54222NnGmUYsAoU4+dxSwEJE4p9XJ1R5c 6gRuHjlLUuuinAQK5Ps50gOag6AOUyvPAavekjAeDWpDEyjvauQn/s9sd4sgHFPAC1k8 j+1u1fnv5Fpregv6mQPJAwSLqTGf8t8CifptvBsDynB48FE4cAxAP+pL1S4q3sjQcPiG eLtlio9EQGJZEw/PcCOQB3eYyAvea5+o41CRGmK4HyqnrbuaJomuQ13346UROuOezOg5 RvXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ScwcVshDOhxBhhXf0pm+5LDjbB5GDbD8FGtt4qSCsug=; b=GZ7s7KzlcU/bjd4i5OJTqfKcfedpFbSR+qSVQdhNY9/Fqz9oz5isKxbfdLH4lnXY9Q wsMVQVjUSWEOOtX1o4C9dBLaFi7th/YRmbDXlPr7u90EqYGubu7o1+kpudxnFnSkGYzG Gkill1IG1fT/Q0LSsZu+EhmpcDiDXgVhO/PgBwxeHzUmGnRaIOOl2F8Rb0vf2id/nbLu AWtlhmNCMZcOlchpxO8hnBGbfubc5vdeU9UOk9p4TcHdU5dcMJra28JrGEgvFKJDrCac e2y1LQUG0fxOkkxMNTq+YnaTQQ7pB7OhLvoaAsHQoSVzA/1b1PesNsh/P7FxdlXJGO5M n0UQ== X-Gm-Message-State: AG10YOSW7AAtC5FJEk7AsWeDjFeMDzwfW3xzIZEaxG3P9Lk71crSbPVWSoz0S/ZakflmjTfFUcggLGwGy5DMVw== MIME-Version: 1.0 X-Received: by 10.50.92.70 with SMTP id ck6mr6713707igb.80.1456074352295; Sun, 21 Feb 2016 09:05:52 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.184.195 with HTTP; Sun, 21 Feb 2016 09:05:52 -0800 (PST) In-Reply-To: <56C70B14.60702@seantek.com> References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> <56C70B14.60702@seantek.com> Date: Sun, 21 Feb 2016 09:05:52 -0800 X-Google-Sender-Auth: _EpZ8EP2v7wz3gpxTb4_2YEEfyU Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 17:05:54 -0000 The thing here is that URNs are meant to name things, not to provide all the information necessary to fully dereference and render the things that are named. I'll note that http URIs don't generally have the kind of information in them that you're talking about -- rather, when a client asks for a resource, the server tells the client what the media type and associated parameters are. Further, I would say that the intent of URNs, as well as the actual need in the field, is to having different URNs for different versions of things. For example, the RFC Editor will be making RFCs available in plain text, HTML, XML, PDF, and possibly other formats (some form of markdown and so forth). Those are all meant to be substantively the same, but they won't be exactly the same, and they'll have different URNs -- not one URN with some sort of parameters. I do think the scope of the work we're doing now is to revise the URN specs to meet up with current usage and needs, and to apply things we've learned since the originals were written. I think it'd be a bad idea, particularly considering how long this needed work has dragged on, to add new features that we're not sure we'll actually need or want when the rubber hits the road. Barry On Fri, Feb 19, 2016 at 4:31 AM, Sean Leonard wrote: > Yes, rely on mappings... > > There is another issue, namely that media types define parameters, some o= f > which may be required for interoperability. For example, "text/plain; > charset=3DUTF-8" will be interpreted differently (in a way that matters a= lot) > than "text/plain" or "text/plain; charset=3Diso-8859-15". > > It would be a straightforward mapping to say > , but the parameters present a significant > challenge. I would suggest defining the protocol slot to be "media type" = in > the first place, in which case you can tack on the parameters after the ; > delimiter like normal. If you are trying to stuff a different, or validat= ed, > media type compared to the resource that the URI is pointing to, you can = use > ni: (RFC 6920) or data: (RFC 2397), or you can invent your own URI scheme= . > > Sean > > > On 2/5/2016 9:54 AM, Ted Hardie wrote: > > I've added Graham Klyne, because he worked on RDF representations of IETF > media types during the content negotiation work many years ago. > > Theory states that you could register these are protocol parameters under > the registry set up in RFC 3553 > (http://www.iana.org/assignments/params/params.xhtml#params-1), but I thi= nk > you would find that you'd basically have to create the mappings rather th= an > rely on a set already in place. > > regards, > > Ted Hardie > > On Fri, Feb 5, 2016 at 2:46 AM, Martin J. D=C3=BCrst > wrote: >> >> Hello Carsten, >> >> I think the issue below has come up repeatedly in different groups, but >> probably never got enough traction. Unfortunately, I can't remember any >> details, but you should probably find something if you dig deeper, eithe= r >> for using URNs or for using URLs. >> >> Sorry for not being of more help. >> >> Regards, Martin. >> >> >> On 2016/01/27 23:10, Carsten Bormann wrote: >>> >>> In W3C WoT IG, we are looking at employing RDF to represent information >>> that is today often held in Web links (RFC 6690, RFC 5988). >>> That includes media types, but also maybe link relation types and other >>> registry content. >>> It would be great to have a canonical mapping to URIs for all these. >>> Has there been any attempt in the past to define, say, URNs for media >>> types? >>> Any other advice on how to obtain stable URIs for protocol constants? >>> (I don't think we want to use the URL to the IANA registry page.) >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >>> >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Sun Feb 21 09:19:00 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14B21A8795 for ; Sun, 21 Feb 2016 09:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 7Vk2YG7FpwCj for ; Sun, 21 Feb 2016 09:18:58 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 5DE641A87AC for ; Sun, 21 Feb 2016 09:18:58 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id y8so71552498igp.0 for ; Sun, 21 Feb 2016 09:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=J3VdYrFaxVqj7KE4fLxNEpjna0oaOaL4u6wYhf8pYno=; b=nqsWZFpXxpXJGv9SlI/DJSKHGrJkRTZym8kfxPigJ1yZb7jZbKb1KMRVqj4tw2J9GK iKyB2xEqwM4/ee5krrhrdSaAxAbNY8gXMoYVYoXF5LDPYXUSl+aSvvhNqXnSDPeYLuvP VjsJ85TxMVkXbP3U+ZXABnG9EkxOHIUDyppbNCn7RuZy5VSuHLAhHWBNevpuEsEOIKys k6xQrC0Lbyl69iF5RAUySVRHeXoM69KrGNZaVdFbzsmXnvSAkvoZQ8AwDR7Li++/JW5m iVGuqOHEJnxDOaMBtvGb+gJ6dII5EJMxoJD17AyB0+y6eHA2+JFxCeU9vDrBwRWwRIct tsRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J3VdYrFaxVqj7KE4fLxNEpjna0oaOaL4u6wYhf8pYno=; b=mAjmoIaAzxiEnc06Vxb6Mfsdei9s78FCdJBa5oVqROdN4wIqUvNeFW4603nFhkeYhx As0evoMuF88V/WZs8VutviiJm7UhAM9JhP60CPgGKznr9wk/tGWlsMSOwh3kl2DXNQRe pGf91iWYO7dbqe3UeQplA1+deGy+nBe7jdKW7itjOPbUO+PDzwjXGvOhg6p8LEvI8c3o l85jWGGDNuRb9DGGkWQMJwVsJxu/T3djHcqVEX38uXPuh7wJQD3QgxqOykfH5FpmKPtT G6YJLO8fPJ9kVbBXeM8HWNQCHcwerOFJPAmW7vcM7nGhJlZqQw1g+w48/Y5mXnRqvttC sq6Q== X-Gm-Message-State: AG10YOTc1vd0RSFZbNgrZK0REDJovpq7pi8wms6QrhghTuXi/gEjmifMOGh22EHWnZby5FV29L0+NJKodbhAwg== MIME-Version: 1.0 X-Received: by 10.50.92.70 with SMTP id ck6mr6760509igb.80.1456075137834; Sun, 21 Feb 2016 09:18:57 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.184.195 with HTTP; Sun, 21 Feb 2016 09:18:57 -0800 (PST) In-Reply-To: <27D17E47D74ADD149F376B58@JcK-HP5.jck.com> References: <56C946AC.8090402@seantek.com> <59DCB1F7C5F5908773EFBF11@JcK-HP5.jck.com> <56C9DB20.5090509@seantek.com> <27D17E47D74ADD149F376B58@JcK-HP5.jck.com> Date: Sun, 21 Feb 2016 09:18:57 -0800 X-Google-Sender-Auth: QeiN6ujk5LJAWaTURgfJurpWgmI Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Editorial Re: draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 17:18:59 -0000 >>>> Several dots that do not function as periods are followed by >>>> two spaces, e.g., Section 1.1: "their uses outlined (Cf. >>>> [RFC 1737]) issues of persistent identifiers". I suspect >>>> this is an artifact of the xml2rfc process, but it's not >>>> good and should be squelched. >>> >>> Thanks. You can take this up on the rfc-interest or xml2rfc >>> list if you like. Those sorts of issue are supposed to be XML >>> stylesheet matters and, even if we went to the trouble to >>> patch around it now (and I/we could figure out how), the risk >>> would be high that things would be fouled up again the next >>> time I hand off to Peter (we are using different tools) or we >>> hand off to the RFC Editor. I have inserted a comment to the >>> latter into the XML to remind them to pay attention to this. >> >> Okay. It may be that "Cf." is the problem, instead of "cf." >> (lowercase). I have reason to believe that some abbreviations >> such as "cf." and "i.e." have manual overrides in the source >> code. > > But that is part of my point because "the source code" is not am > unambiguous reference because it could be "source code of the > version Peter is using, source code of the version I'm using, > source code of today's online version, source code for v3, etc. We've already spent more cycles in the several messages about this than it's worth. This is (1) a total nit and (2) an artifact of the tools we're using. Please, let's just stop getting wound up about things like this. I think it's great that the document is in such good shape that we have to call out minor misspellings and question the number of spaces after dots. That attests to the great job done by the editor; thanks, John. That said, let's go easy on the nitpicking, and really try to focus on the content. If there are editorial issues that affect the meaning, let's absolutely get those right. For other editorial issues it's fine to note them, and it's also fine to say, "Thanks for the editorial notes," and not to respond to each one. Barry From nobody Sun Feb 21 09:30:45 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF40B1A89C5 for ; Sun, 21 Feb 2016 09:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 LTE6TjiUzrl4 for ; Sun, 21 Feb 2016 09:30:43 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 71E3E1A89E9 for ; Sun, 21 Feb 2016 09:30:40 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id 5so67631006igt.0 for ; Sun, 21 Feb 2016 09:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jc++jpinFD0S8Uz3fN6/XMVmHKFcj3EOnPUGF3nR0Kc=; b=I8jI+mKb0Wi2+MGOr8HH6j//II/wZPFJWYDdMCOCezolxdfVy9Q4bdqI8bWLKqrFXD SsNafhgNhLuMJdhTjSt3KvpZzQ2ofh8A8VZmJeM+SlahUrcj5XeAv4Ba+LC6tAw6uer9 zNqye5M/XCyU+fKA8hyy0d6LUXhIo5O5xI262yn4Nob94QZCPxQFyQhABfD3r/fTdDL0 n9PTkh8QhhBBFrPJSQd6S/isf/1SebaI2mQLkHM8H63q86I17ju2bXPB7z6ajg8X+grP DzxGUTlBrPqvrcP3XGAAWclC8I6i1gP/wVLOBLRUycSmAAAkyvxyKeu9ZyMXZ+p+HTJh mVWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jc++jpinFD0S8Uz3fN6/XMVmHKFcj3EOnPUGF3nR0Kc=; b=PHAqAi7153HbqBixZpeoag7R6XR2Awak2UJiIcW24Wup7m00KawjuM/c/lO4XJ+o4A DEWGAVyryelCtlvesfv40+yX9Ah5OVdFXzU9wAqyPNLVzUuc57cJmJf8mfeF32WURGe7 ZTfUFjqRBFRubW/u8sQVVKwnsnas3FXohRJ6vM+0Omek21CO1b3OXUoj83iO/KoQUeeE /QFWIWSioM9xRX3vRmnKamnY4pa2oAjqvQ2OPNv59GIUg98HBwYhD45QGyoZHkglhUjj ma6xJAMk3BZqir3s0D8Pfr80TdbeY1pO6zbqwvnxkUrSaWvyrvkrs2JBC8crlSM9bZMz 5J1g== X-Gm-Message-State: AG10YOTzDP4CQA7xtTtXg/NEnbq/i3NSm58z3ilEcKxiE118D13n1PfL+qEschz8KPCqvlxtvdO/o1KbEYNsxw== MIME-Version: 1.0 X-Received: by 10.51.17.34 with SMTP id gb2mr2107306igd.13.1456075839881; Sun, 21 Feb 2016 09:30:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.184.195 with HTTP; Sun, 21 Feb 2016 09:30:39 -0800 (PST) In-Reply-To: <56C949B2.9070004@seantek.com> References: <4562EADF0DFB9E2C1304337A@JcK-HP8200.jck.com> <56C949B2.9070004@seantek.com> Date: Sun, 21 Feb 2016 09:30:39 -0800 X-Google-Sender-Auth: kQZvo_fVqJcZXhfvwD6k9NZRLRY Message-ID: From: Barry Leiba To: Sean Leonard Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "urn@ietf.org" Subject: Re: [urn] Editorial Re: draft-ietf-urnbis-semantics-clarif-03 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 17:30:43 -0000 > I honestly do not see the need for Section 8. IANA Considerations. This > document is something of a missive; it does not define an actionable > (technically implementable) standard so I believe it can dispense with the > general advice that the majority of RFCs ought to have IANA Considerations > sections. It's not general advice and it's not just a majority. It's a pretty strong rule and it's essentially all drafts that are going to the IESG for approval. Let's not argue this point any more; there's no future in it, and arguing it won't make the document better. We can argue that this document doesn't need to be published separately -- it was done this way as a WG-management thing. Anyone making that argument should say *specifically* how the salient information should be folded into 2141bis. Barry From nobody Sun Feb 21 09:36:49 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B691A874E for ; Sun, 21 Feb 2016 09:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=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 GEV6DwM50oLA for ; Sun, 21 Feb 2016 09:36:45 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4458E1A6F8A for ; Sun, 21 Feb 2016 09:36:45 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXXvy-000PTL-VH; Sun, 21 Feb 2016 12:36:38 -0500 Date: Sun, 21 Feb 2016 12:36:33 -0500 From: John C Klensin To: Barry Leiba , Sean Leonard Message-ID: <87CE19143D4A23743142D66D@JcK-HP5.jck.com> In-Reply-To: References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> <56C70B14.60702@seantek.com> 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 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 17:36:46 -0000 --On Sunday, February 21, 2016 9:05 AM -0800 Barry Leiba wrote: > The thing here is that URNs are meant to name things, not to > provide all the information necessary to fully dereference and > render the things that are named. I'll note that http URIs > don't generally have the kind of information in them that > you're talking about -- rather, when a client asks for a > resource, the server tells the client what the media type and > associated parameters are. > > Further, I would say that the intent of URNs, as well as the > actual need in the field, is to having different URNs for > different versions of things. For example, the RFC Editor > will be making RFCs available in plain text, HTML, XML, PDF, > and possibly other formats (some form of markdown and so > forth). Those are all meant to be substantively the same, but > they won't be exactly the same, and they'll have different > URNs -- not one URN with some sort of parameters. Barry, While I agree with everything else in your note, the above example is less clear to me and less clear because the "substantively the same" part. So, just as I can imagine http://www.rfc-editor.org/info/rfc2141?format=PDF as a plausible alternate to https://www.rfc-editor.org/rfc/pdfrfc/rfc2141.txt.pdf in some brave new world, I can imagine urn:ietf:rfc:2141?=format=PDF As a URN whose intent is to name RFC 2141 (everything up to the "?") and to "resolve to" any of the locations at which the PDF form of that RFC can be located. I think this sort of thing has to be a per-namesspace decision, lest it make us all crazy. If that decision has been made and document for the "IETF" NID, or even for the nid:"rfc" sub-namespace (whatever those are), I don't think I've seen the document. > I do think the scope of the work we're doing now is to revise > the URN specs to meet up with current usage and needs, and to > apply things we've learned since the originals were written. > I think it'd be a bad idea, particularly considering how long > this needed work has dragged on, to add new features that > we're not sure we'll actually need or want when the rubber > hits the road. +Many john From nobody Sun Feb 21 09:48:32 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D341A902C for ; Sun, 21 Feb 2016 09:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 RdE_dr14YaGN for ; Sun, 21 Feb 2016 09:48:29 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EF01A9027 for ; Sun, 21 Feb 2016 09:48:28 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9C37C509BD for ; Sun, 21 Feb 2016 12:48:27 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <56C9F82F.80103@seantek.com> Date: Sun, 21 Feb 2016 09:47:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 17:48:31 -0000 The most significant technical changes in urnbis-15 are the treatment of q-component and r-component. As such, all of these changes are somewhat related. I applaud the attempt to identify q-component with "?=" syntax and r-component with "?+" syntax. You get an E for effort. Unfortunately, it is unworkable, and if there is one thing that I am going to be a stick-in-the-mud about, it's going to be this. This WG concluded that q-component can contain the entire contents of a query component of a URI [RFC3986]. Therefore, q-component can contain any production, including "?=" and "?+". It is entirely possible that some URI out there permits "?+" (and in fact, I am pretty sure that HTTP URIs permit such a sequence). This means that the proposed URN syntax is ambiguous. Since q-component can be any query character and since q and r-components are in the query position of URIs, the *only* way to distinguish q-component unambiguously is to put q-component in the second position, and r-component in the first position. The URN syntax can then constrain r-component not to include "?", so "?" delimits r-component from q-component. This is entirely implementable. namestring = assigned-name [ "?" r-component [ "?" q-component ] ] [ "#" f-component ] q-component = query r-component = resolverID ":" *( pchar / "/" ) That's the much-simplified ABNF. That means that if you want q-component and no r-component, q-component is preceded by "??". Okie-dokie. If you really, really want "??" to delimit r-component, then you can have a tripartite construction: ??r-component ?q-component ??r-component?q-component I think this is more convoluted than the proposed syntax and ABNF above. But it can be done. *** It is said in Section 2.3 and q-component and f-component are namespace-independent. However, r-component is apparently *sometimes* namespace-independent, and sometimes namespace-dependent. Schizophrenia! Is it dependent, or independent?? If it is "sometimes dependent" (depending on the namespace definition), then...obviously it's namespace-dependent, because it always depends on whether the namespace says it's dependent or independent! I believe that the WG really should resolve this before concluding this work...although it's not quite as much of a show-stopper as the ?+ ?= syntax issue above. Right now, r-components are namespace-dependent. The question is whether we want to define things like resolverID to be "read" relative to the NID, or not. We have already concluded that a resolution service will take the NID, NSS, and r-component in when doing its job (but neither q-component nor f-component). From that standpoint, r-component will always be interpreted with NID in view. Should a hypothetical resolverID "info" be defined essentially on a per-namespace basis, or should it be defined as a global resolution operation, "get some information about this URN", which may or may not apply to different URNs in different cases? My view is that the people writing durable, universal naming schemes should not be required to be in the business (directly) of dictating what resolution services get developed or not, and vice-versa. I.e., the URN namespace registration template should not require new URN namespaces to specify a set of resolution ops. From that view, it follows that r-component is namespace-independent, in the sense that the maintainers of urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a stab at their own spins on the resolverID "foo" or "info" or "abcdefg". The namespaces of "resolverID" and therefore r-components more generally are global and orthogonal to the NID / NSS part. We may wish to subdivide that global namespace into parts that incorporate NIDs, such as "*foo" being syntactic sugar for "urn-nid-specific-op-isbn!foo". (E.g., every URN namespace maintainer also gets a chunk of the resolverID namespace for its personal use for "free"--but this namespace is orthogonal to the URN NID/NSS namespace and does not have the same durability and uniqueness requirements.) I accept that such further definition is out-of-scope for this draft if we want to get it out in 2016. But we need to lay the groundwork. *** I am very relieved to see that resolverID made it into this spec. That being said, resolverID and the other part after the colon both under-deliver and over-deliver in material respects. "?" is out as a character because that needs to be used to distinguish r-component from q-component. I accept that resolverID is ASCII-only (no percent-encoding, and therefore no UTF-8). This makes things simpler. I also accept that trying to constrain resolverID to particular things (namely a list of keywords) is going to drag this work on too long. That being said, there is no reason at this juncture to limit resolverID to LDH (letter digit hyphen). Since ":" delimits resolverID from the rest, we only need to remove ":". Allowing other characters will provide more flexibility. Therefore, proposal: resolverID = unreserved / sub-delims / "@" / "/" Since we are defining resolverID, the momentum is sufficient to structure the syntax of the other part. Although I am not combing through the history of the mailing list, I believe a handful of voices called for name/value pairs, and nobody strenuously objected. Here is a proposal: r-component = resolverID [ ":" r-params ] ; overall repertoire is *(pchar / "/") ; but "/" is not used--also "@" and ":" are not used ; because they are potentially used elsewhere ; and it's just better to limit parsing r-params = r-param *( ( ";" / "&" ) r-param ) r-param = rp-name [ "=" rp-values ] ; pct-encoded prohibited in rp-name. Worth discussing rp-name = *( unreserved / "!" / "$" / "'" / "(" / ")" / "*" / "+" ) rp-values = rp-value *( "," rp-value ) ; mostly isomorphic with encodeURIComponent except $ and + ; but that is intentional rp-value = *( unreserved / pct-encoded / "!" / "$" / "'" / "(" / ")" / "*" / "+" ) Compared with draft-14-seantek, the main difference is that I constricted rp-name so that it does not permit percent-encoding. I believe this is in keeping with the proposed resolverID being ASCII-only. In contrast, rp-value should be UTF-8. Note: The draft-15 ABNF for r-component requires r-component to have both resolverID and at least one character after the ":". I believe that is a mistake: it should be permissible to specify resolverID without anything afterwards. Sean From nobody Sun Feb 21 10:24:52 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B441A9154 for ; Sun, 21 Feb 2016 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 JIuHx5hGexeJ for ; Sun, 21 Feb 2016 10:24:50 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB501A90FC for ; Sun, 21 Feb 2016 10:24:50 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 31D35509BD for ; Sun, 21 Feb 2016 13:24:48 -0500 (EST) To: urn@ietf.org References: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> From: Sean Leonard Message-ID: <56CA00B5.5060804@seantek.com> Date: Sun, 21 Feb 2016 10:23:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] ReL draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 18:24:51 -0000 Let me respond to John's specific questions... On 2/13/2016 6:49 AM, John C Klensin wrote: > (1) Do the registration template and supporting information > still reflect what we want there? They have not been carefully > reviewed, much less revised, in the last few drafts, and we need > to think about other changes and whether they should be > reflected in the NID/ Namespace registration specifications. They are okay. (See prior e-mail.) > > (2) We've seen two proposals for NID registrations in the last > week or two. Would the registration template and new procedure > adequately reflect whatever we've learned from them? Would we > be happy having them go through under the new procedure? I am fine with them going through under the new procedure. I believe=20 that the registration template and procedure are good enough. > > (3) Is the ABNF consistent with everyone's expectations, > especially noting the the change in introducers for r-component > and q-component eliminates several problems (including the > controversy about ordering) but may introduce a few others. In > particular, is everyone ok with q-component and r-component > appearing in either order (as the text and ABNF now say) or is > there some reason to require a specific order)? Similarly, the > text contains some words about the implications of "?" followed > by neither (new) delimiter but the ABNF doesn't call the issue > out. Is that ok with everyone? If it is not, please propose > ABNF changes and/or text. This is a big problem, to the point of being unimplementable. Already=20 covered per prior e-mail. > > (4) Is the spec now clear enough? Are there places that need > work? If so, please at least identify the places and the issues > and, if possible, propose text. Hopefully my prior e-mail covered the places that need work. Three areas = to highlight (here--covered extensively in prior e-mail) are: 1. whether r-component is namespace-dependent or namespace-independent, 2. UTF-8 encoding enforcement, and 3. whether f-component ought to be passed to resolvers. My summary: 1. draft-15 is dependent but it should be independent. 2. draft-15 has it right technically on UTF-8 but is not concise enough=20 in saying how it is. 3. draft-15 says f-component SHOULD NOT be passed to resolvers, but it=20 should say that f-component MUST NOT be passed to resolvers. "Resolver"=20 needs to be more carefully defined so that this axiomatically pops out=20 of the definition. Sean From nobody Sun Feb 21 11:47:02 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B361A8F38 for ; Sun, 21 Feb 2016 11:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 eVjn1SNEV86P for ; Sun, 21 Feb 2016 11:46:59 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F10D1A88BC for ; Sun, 21 Feb 2016 11:46:59 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0EBB2509BB for ; Sun, 21 Feb 2016 14:46:57 -0500 (EST) To: "urn@ietf.org" From: Sean Leonard Message-ID: <56CA13F5.7070707@seantek.com> Date: Sun, 21 Feb 2016 11:45:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [urn] Are ISO 3166 country codes stable enough for URN use? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:47:00 -0000 In reviewing the latest draft-ietf-urnbis-ns-reg-transition, I noticed the dependency on NBN [RFC3188], which in turn depends on ISO 3166. An example is . URNs are supposed to be stable and durable over time... but are ISO 3166 country codes stable enough for URN? I have not actually read all of the details of ISO 3166. But ISO 3166 grapples with an intensely political question: how to name countries. I read this PDF: http://unstats.un.org/unsd/tradekb/Attachment194.aspx And it says that "withdrawn [codes] may not be reused for five years". That means that they can be reused in five years. I think that violates some URN principles. NBN isn't the first time we have seen ISO 3166 country codes in URNs. There is the urn:lex proposal (not really sure where that is now). There are also my proposals for urn:xmlns and urn:rdf. However in my proposals, the entire NSS is assigned on a first-come, first-served basis: the relationship between two- and three-character ISO 3166 country codes being part of the NSS is purely a coincidence and therefore reassignment of a country code does not affect the durability and immutability of the assigned string. Sean From nobody Sun Feb 21 12:24:39 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3471AC415 for ; Sun, 21 Feb 2016 12:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_34=0.6] autolearn=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 FmQlYHbDj0mF for ; Sun, 21 Feb 2016 12:24:35 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA5C1AC413 for ; Sun, 21 Feb 2016 12:24:35 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXaYR-0000au-2V; Sun, 21 Feb 2016 15:24:31 -0500 Date: Sun, 21 Feb 2016 15:24:26 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> In-Reply-To: <56C9F82F.80103@seantek.com> References: <56C9F82F.80103@seantek.com> 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 Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:24:38 -0000 Sean, I disagree with most of your note. Much of this response is intended ed to clarify the area(s) of disagreement, not to argue with you about the points. At least for the present, I'll leave that to others... and to the co-chairs to decide how far we want to go about the last issue. --On Sunday, February 21, 2016 9:47 AM -0800 Sean Leonard wrote: > The most significant technical changes in urnbis-15 are the > treatment of q-component and r-component. As such, all of > these changes are somewhat related. > > I applaud the attempt to identify q-component with "?=" syntax > and r-component with "?+" syntax. You get an E for effort. > > Unfortunately, it is unworkable, and if there is one thing > that I am going to be a stick-in-the-mud about, it's going to > be this. Alternatives are welcome, but I believe we have been down this path and that there is (at least so far) no consensus for blowing off 3986 syntax entirely and that the WG concluded that embedding r-component and q-component in the syntax of a 3986 "query" was the way to go. If you want to re-argue that question, I need to hear from the WG Co-Chairs before proceeding. If we stick with "embedding in query", then, as I read the rule in 3896, the part starts after the first "?" and extends to the end of the URI or the first "#". That means that _anything_ (other than "#"), including "+", "=", and more "?"s with or without associated characters is, from a 3986 standpoint, just part of that and poses no issues for 3986. Now, I think there _are_ two issues with this idea of embedding q-component and r-component in <3986-query>. One arises if one says "you can't only use the 3986 syntax, you have to interpret it the way http-URLs do". Put differently, there is no requirement that the hypothetical generic URI parser be able to divide the <3986-query> into r-components or q-components because it doesn't know anything about them. I believe the WG has decided, in the "syntax only" notion, to not entertain that position further and that, if you want to reopen it, you need to convince the WG (and certainly the Co-Chairs) that you have something new. The other issue is what we actually mean by "embedding", and is a more complex question. So far, the WG has believed that simply delimiting the two substrings is sufficient. However, if we need to specify that any appearances of "?", or "?=" or, most particularly, "?+" in those strings must be %-encoded and then that the URN-parser needs to be able to decode one level of %-encoding before putting the contents of the q-component into a URL as a , it seems to me that is easily accomplished in terms of the document and not a big deal for a URN-parser/evaluator. It would add a bit to the confusion we already have with IRIs and where %-encoding is required and optional, but not very much. So, while I think we need to straighten out whether that encoding requirement is needed, I don't see the problem as anything near "unworkable". > This WG concluded that q-component can contain the entire > contents of a query component of a URI [RFC3986]. Therefore, > q-component can contain any production, including "?=" > and "?+". It is entirely possible that some URI out there > permits "?+" (and in fact, I am pretty sure that HTTP URIs > permit such a sequence). This means that the proposed URN > syntax is ambiguous. At most, only if "?+" is not required to be encoded. See above. > Since q-component can be any query character and since q and > r-components are in the query position of URIs, the *only* way > to distinguish q-component unambiguously is to put q-component > in the second position, and r-component in the first position. > The URN syntax can then constrain r-component not to include > "?", so "?" delimits r-component from q-component. This is > entirely implementable. I think the WG has been down that path, has concluded that there are use cases for "?" in r-components (even if not in your model of r-components, see below). If we need to go through it again, we need to hear from the co-chairs, especially (IMO) about whether you are raising a new issue or reiterating an old one. >... > *** > It is said in Section 2.3 and q-component and f-component are > namespace-independent. However, r-component is apparently > *sometimes* namespace-independent, and sometimes > namespace-dependent. Schizophrenia! Is it dependent, or > independent?? > > If it is "sometimes dependent" (depending on the namespace > definition), then...obviously it's namespace-dependent, > because it always depends on whether the namespace says it's > dependent or independent! I think that is correct and that, if we are going to stick with resolverID, the only thing that is namespace-independent is the interpretation of a given registered resolverID (see below). If the WG agrees and it is not already obvious, suggestions about how to clarify the text would be welcome. > I believe that the WG really should resolve this before > concluding this work...although it's not quite as much of a > show-stopper as the ?+ ?= syntax issue above. Right now, > r-components are namespace-dependent. The document's intent was that the only thing about r-components that is namespace-independent is the ability to parse one into a resolverID and a rest-of-the-r-component. That was put in as a compromise with, and concession to, you. If it no longer works for you, it can be taken back out, making r-components entirely namespace-dependent. > The question is whether we want to define things like > resolverID to be "read" relative to the NID, or not. We have > already concluded that a resolution service will take the NID, > NSS, and r-component in when doing its job (but neither > q-component nor f-component). From that standpoint, > r-component will always be interpreted with NID in view. See above. > Should a hypothetical resolverID "info" be defined essentially > on a per-namespace basis, or should it be defined as a global > resolution operation, "get some information about this URN", > which may or may not apply to different URNs in different > cases? Again, my understanding was that resolverIDs were to be defined independent of the namespace/NID that uses them. If that was not the intent, then the text almost certainly needs work -- but most or all of the justification for specifying the ability to parse the r-component to identify the resolverID also disappears. > My view is that the people writing durable, universal naming > schemes should not be required to be in the business > (directly) of dictating what resolution services get developed > or not, and vice-versa. I.e., the URN namespace registration > template should not require new URN namespaces to specify a > set of resolution ops. > > From that view, it follows that r-component is > namespace-independent, in the sense that the maintainers of > urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a > stab at their own spins on the resolverID "foo" or "info" or > "abcdefg". The namespaces of "resolverID" and therefore > r-components more generally are global and orthogonal to the > NID / NSS part. I hope that is consistent with what the text says. However, the intent of the text was that maintainers of particular namespaces _do_ get to specify what resolverIDs are used with them, just not how a given resolverID that they intend to permit is interpreted. If your notion that any resolverID can be used with any NID/ namespace, then it takes on a lot of the properties that 3986 assigned to . I believe the WG has decided to not go there, but need the WG co-chairs for this. > We may wish to subdivide that global namespace into parts that > incorporate NIDs, such as "*foo" being syntactic sugar for > "urn-nid-specific-op-isbn!foo". (E.g., every URN namespace > maintainer also gets a chunk of the resolverID namespace for > its personal use for "free"--but this namespace is orthogonal > to the URN NID/NSS namespace and does not have the same > durability and uniqueness requirements.) I accept that such > further definition is out-of-scope for this draft if we want > to get it out in 2016. But we need to lay the groundwork. This is, IMO, going _really_ far down the path that I thought we agreed we weren't going to try to traverse... as a necessary measure for getting finished any time in the near future. If you disagree, please try to convince the Co-Chairs and (idenally from my standpoint) do it off list. > *** > > I am very relieved to see that resolverID made it into this > spec. Some of your comments above (and the next one) suggest that its introduction raises too many other issues that need to be resolved and that it should be taken back out. > That being said, resolverID and the other part after the colon > both under-deliver and over-deliver in material respects. > > "?" is out as a character because that needs to be used to > distinguish r-component from q-component. > > I accept that resolverID is ASCII-only (no percent-encoding, > and therefore no UTF-8). This makes things simpler. I also > accept that trying to constrain resolverID to particular > things (namely a list of keywords) is going to drag this work > on too long. > > That being said, there is no reason at this juncture to limit > resolverID to LDH (letter digit hyphen). Since ":" delimits > resolverID from the rest, we only need to remove ":". Allowing > other characters will provide more flexibility. Therefore, > proposal: >... I'm not going to engage on this unless others in the WG show an interest in a discussion, one that is active and focused enough to not hold us up for months debating a few characters for which there is no demonstrated need beyond "we could...". In defense of that position, I think we should remember that it is much easier to add (allow) a previously-prohibited character if it turns out to be necessary than it is to delete one that turns out to be a problem. >... > Since we are defining resolverID, the momentum is sufficient > to structure the syntax of the other part. Although I am not > combing through the history of the mailing list, I believe a > handful of voices called for name/value pairs, and nobody > strenuously objected. Again, I believe the WG explicitly decided to not do this, partially because it is questionable whether there is momentum to do _anything_ beyond finishing up on the current path (if then) and partially because it is not clear that there is general agreement with your model about what "resolvers" are about. I believe the Co-Chairs have already rules further proposals in this area off-topic. john From nobody Sun Feb 21 12:35:34 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0D21ACD38 for ; Sun, 21 Feb 2016 12:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_35=0.6] autolearn=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 Rt0mKMkzKNx0 for ; Sun, 21 Feb 2016 12:35:32 -0800 (PST) Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BE71ACD36 for ; Sun, 21 Feb 2016 12:35:31 -0800 (PST) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXaj4-0000dy-VU; Sun, 21 Feb 2016 15:35:30 -0500 Date: Sun, 21 Feb 2016 15:35:25 -0500 From: John C Klensin To: Sean Leonard , urn@ietf.org Message-ID: <1804C7530E646E7F15CDD2E8@JcK-HP5.jck.com> In-Reply-To: <56CA13F5.7070707@seantek.com> References: <56CA13F5.7070707@seantek.com> 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 Archived-At: Subject: Re: [urn] Are ISO 3166 country codes stable enough for URN use? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:35:33 -0000 Sean, Very briefly and having spend far too much time immersed in a well-known use of 3166 and it implications, two observations: (1) The "we can, and probably will, reassign a code after five years" rule have been dead for some years. You should be careful about what you treat as an authoritative reference. Because of (2), I may regret even mentioning that. (2) The definition of "persistent enough" or "stable enough" inevitably has to be per-namespace. One of the earliest examples in the discussions that led to URNs was "the weather in..." which can be as stable as location names are as a reference but whose object is typically entirely unstable. This isn't a WG topic. When the NDN spec is revised, you can certainly have the discussion in the context of that revision (assuming they don't simply decide to register something based on a document published elsewhere which, fwiw, is certainly what I would be inclined to do if I were in their position). john --On Sunday, February 21, 2016 11:45 AM -0800 Sean Leonard wrote: > In reviewing the latest draft-ietf-urnbis-ns-reg-transition, I > noticed the dependency on NBN [RFC3188], which in turn depends > on ISO 3166. > > An example is . > > URNs are supposed to be stable and durable over time... > > but are ISO 3166 country codes stable enough for URN? > > I have not actually read all of the details of ISO 3166. But > ISO 3166 grapples with an intensely political question: how to > name countries. I read this PDF: > http://unstats.un.org/unsd/tradekb/Attachment194.aspx > > And it says that "withdrawn [codes] may not be reused for five > years". That means that they can be reused in five years. I > think that violates some URN principles. > > NBN isn't the first time we have seen ISO 3166 country codes > in URNs. There is the urn:lex proposal (not really sure where > that is now). > > There are also my proposals for urn:xmlns and urn:rdf. However > in my proposals, the entire NSS is assigned on a first-come, > first-served basis: the relationship between two- and > three-character ISO 3166 country codes being part of the NSS > is purely a coincidence and therefore reassignment of a > country code does not affect the durability and immutability > of the assigned string. > > Sean > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Sun Feb 21 12:38:43 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644FF1A8869 for ; Sun, 21 Feb 2016 12:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 WrICBM9bhJfM for ; Sun, 21 Feb 2016 12:38:39 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904C41A87A9 for ; Sun, 21 Feb 2016 12:38:39 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 52BF6509BD; Sun, 21 Feb 2016 15:38:38 -0500 (EST) To: John C Klensin , urn@ietf.org References: <56CA13F5.7070707@seantek.com> <1804C7530E646E7F15CDD2E8@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <56CA2012.3060504@seantek.com> Date: Sun, 21 Feb 2016 12:37:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1804C7530E646E7F15CDD2E8@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Are ISO 3166 country codes stable enough for URN use? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:38:41 -0000 Ok. It sounds like the durability and persistence requirements for URNs are being relaxed somewhat, compared to the old days. I'm fine with that, carry on. Sean On 2/21/2016 12:35 PM, John C Klensin wrote: > Sean, > > Very briefly and having spend far too much time immersed in a > well-known use of 3166 and it implications, two observations: > > (1) The "we can, and probably will, reassign a code after five > years" rule have been dead for some years. You should be > careful about what you treat as an authoritative reference. > Because of (2), I may regret even mentioning that. > > (2) The definition of "persistent enough" or "stable enough" > inevitably has to be per-namespace. One of the earliest > examples in the discussions that led to URNs was "the weather > in..." which can be as stable as location names are as a > reference but whose object is typically entirely unstable. > > This isn't a WG topic. When the NDN spec is revised, you can > certainly have the discussion in the context of that revision > (assuming they don't simply decide to register something based > on a document published elsewhere which, fwiw, is certainly what > I would be inclined to do if I were in their position). > > john > > > --On Sunday, February 21, 2016 11:45 AM -0800 Sean Leonard > wrote: > >> In reviewing the latest draft-ietf-urnbis-ns-reg-transition, I >> noticed the dependency on NBN [RFC3188], which in turn depends >> on ISO 3166. >> >> An example is . >> >> URNs are supposed to be stable and durable over time... >> >> but are ISO 3166 country codes stable enough for URN? >> >> I have not actually read all of the details of ISO 3166. But >> ISO 3166 grapples with an intensely political question: how to >> name countries. I read this PDF: >> http://unstats.un.org/unsd/tradekb/Attachment194.aspx >> >> And it says that "withdrawn [codes] may not be reused for five >> years". That means that they can be reused in five years. I >> think that violates some URN principles. >> >> NBN isn't the first time we have seen ISO 3166 country codes >> in URNs. There is the urn:lex proposal (not really sure where >> that is now). >> >> There are also my proposals for urn:xmlns and urn:rdf. However >> in my proposals, the entire NSS is assigned on a first-come, >> first-served basis: the relationship between two- and >> three-character ISO 3166 country codes being part of the NSS >> is purely a coincidence and therefore reassignment of a >> country code does not affect the durability and immutability >> of the assigned string. >> >> Sean >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > > From nobody Sun Feb 21 12:56:49 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB951A903B for ; Sun, 21 Feb 2016 12:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-5, TVD_FROM_1=0.999] autolearn=ham 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 FphhEQ0ADwVM for ; Sun, 21 Feb 2016 12:56:44 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED2B1A92EF for ; Sun, 21 Feb 2016 12:56:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,482,1449532800"; d="scan'208,217";a="469129173" Received: from sea19-co-svc-lb5-vlan3.sea.amazon.com (HELO email-inbound-relay-64008.pdx4.amazon.com) ([10.47.22.166]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2016 20:56:40 +0000 Received: from ex10-hub-7001.ant.amazon.com (pdx1-ws-svc-lb16-vlan3.amazon.com [10.239.138.214]) by email-inbound-relay-64008.pdx4.amazon.com (8.14.7/8.14.7) with ESMTP id u1LKubYb000802 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 21 Feb 2016 20:56:38 GMT Received: from EX13D08UWB004.ant.amazon.com (10.43.161.232) by ex10-hub-7001.ant.amazon.com (10.43.103.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 21 Feb 2016 12:56:37 -0800 Received: from EX13D08UWB003.ant.amazon.com (10.43.161.186) by EX13D08UWB004.ant.amazon.com (10.43.161.232) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 21 Feb 2016 20:56:36 +0000 Received: from EX13D08UWB003.ant.amazon.com ([10.43.161.186]) by EX13D08UWB003.ant.amazon.com ([10.43.161.186]) with mapi id 15.00.1076.000; Sun, 21 Feb 2016 20:56:36 +0000 From: "Phillips, Addison" To: Sean Leonard , John C Klensin , "urn@ietf.org" Thread-Topic: [urn] Are ISO 3166 country codes stable enough for URN use? Thread-Index: AQHRbOC1lAcisi/u0kSqRw25RHBqK5829QeAgAAAnwCAAAVNKg== Date: Sun, 21 Feb 2016 20:56:36 +0000 Message-ID: <7req9kjyve7mdncaaxk7omij.1456091779789@email.android.com> References: <56CA13F5.7070707@seantek.com> <1804C7530E646E7F15CDD2E8@JcK-HP5.jck.com>,<56CA2012.3060504@seantek.com> In-Reply-To: <56CA2012.3060504@seantek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_7req9kjyve7mdncaaxk7omij1456091779789emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [urn] Are ISO 3166 country codes stable enough for URN use? X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:56:48 -0000 --_000_7req9kjyve7mdncaaxk7omij1456091779789emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you were still concerned about 3166 stability, note the the language sub= tag registry (BCP 47) maintains a stabilized version for the region set of = subtags. Because it still isn't okay to reuse the codes, even over periods = longer than five years. (Sent from my Fire tablet) On February 22, 2016, at 12:39 AM, Sean Leonard wrot= e: Ok. It sounds like the durability and persistence requirements for URNs are being relaxed somewhat, compared to the old days. I'm fine with that, carry on. Sean On 2/21/2016 12:35 PM, John C Klensin wrote: > Sean, > > Very briefly and having spend far too much time immersed in a > well-known use of 3166 and it implications, two observations: > > (1) The "we can, and probably will, reassign a code after five > years" rule have been dead for some years. You should be > careful about what you treat as an authoritative reference. > Because of (2), I may regret even mentioning that. > > (2) The definition of "persistent enough" or "stable enough" > inevitably has to be per-namespace. One of the earliest > examples in the discussions that led to URNs was "the weather > in..." which can be as stable as location names are as a > reference but whose object is typically entirely unstable. > > This isn't a WG topic. When the NDN spec is revised, you can > certainly have the discussion in the context of that revision > (assuming they don't simply decide to register something based > on a document published elsewhere which, fwiw, is certainly what > I would be inclined to do if I were in their position). > > john > > > --On Sunday, February 21, 2016 11:45 AM -0800 Sean Leonard > wrote: > >> In reviewing the latest draft-ietf-urnbis-ns-reg-transition, I >> noticed the dependency on NBN [RFC3188], which in turn depends >> on ISO 3166. >> >> An example is . >> >> URNs are supposed to be stable and durable over time... >> >> but are ISO 3166 country codes stable enough for URN? >> >> I have not actually read all of the details of ISO 3166. But >> ISO 3166 grapples with an intensely political question: how to >> name countries. I read this PDF: >> http://unstats.un.org/unsd/tradekb/Attachment194.aspx >> >> And it says that "withdrawn [codes] may not be reused for five >> years". That means that they can be reused in five years. I >> think that violates some URN principles. >> >> NBN isn't the first time we have seen ISO 3166 country codes >> in URNs. There is the urn:lex proposal (not really sure where >> that is now). >> >> There are also my proposals for urn:xmlns and urn:rdf. However >> in my proposals, the entire NSS is assigned on a first-come, >> first-served basis: the relationship between two- and >> three-character ISO 3166 country codes being part of the NSS >> is purely a coincidence and therefore reassignment of a >> country code does not affect the durability and immutability >> of the assigned string. >> >> Sean >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > > > _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn --_000_7req9kjyve7mdncaaxk7omij1456091779789emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you were still concerned about 3166 stability, note the t= he language subtag registry (BCP 47) maintains a stabilized version for the= region set of subtags. Because it still isn't okay to reuse the codes, eve= n over periods longer than five years.

(Sent from my Fire tablet)



On February 22, 2016, at 12:39 AM, Sean Leonard <dev+ietf@seantek.co= m> wrote:

Ok.

It sounds like the durability and persistence requirements for URNs are being relaxed somewhat, compared to the old days.

I'm fine with that, carry on.

Sean

On 2/21/2016 12:35 PM, John C Klensin wrote:
> Sean,
>
> Very briefly and having spend far too much time immersed in a
> well-known use of 3166 and it implications, two observations:
>
> (1) The "we can, and probably will, reassign a code after five > years" rule have been dead for some years.  You should be > careful about what you treat as an authoritative reference.
> Because of (2), I may regret even mentioning that.
>
> (2) The definition of "persistent enough" or "stable en= ough"
> inevitably has to be per-namespace.  One of the earliest
> examples in the discussions that led to URNs was "the weather
> in..." which can be as stable as location names are as a
> reference but whose object is typically entirely unstable.
>
> This isn't a WG topic.  When the NDN spec is revised, you can
> certainly have the discussion in the context of that revision
> (assuming they don't simply decide to register something based
> on a document published elsewhere which, fwiw, is certainly what
> I would be inclined to do if I were in their position).
>
>     john
>
>
> --On Sunday, February 21, 2016 11:45 AM -0800 Sean Leonard
> <dev+ietf@seantek.com> wrote:
>
>> In reviewing the latest draft-ietf-urnbis-ns-reg-transition, I
>> noticed the dependency on NBN [RFC3188], which in turn depends
>> on ISO 3166.
>>
>> An example is <URN:NBN:fi-fe19981001>.
>>
>> URNs are supposed to be stable and durable over time...
>>
>> but are ISO 3166 country codes stable enough for URN?
>>
>> I have not actually read all of the details of ISO 3166. But
>> ISO 3166 grapples with an intensely political question: how to
>> name countries. I read this PDF:
>> = http://unstats.un.org/unsd/tradekb/Attachment194.aspx
>>
>> And it says that "withdrawn [codes] may not be reused for fiv= e
>> years". That means that they can be reused in five years. I >> think that violates some URN principles.
>>
>> NBN isn't the first time we have seen ISO 3166 country codes
>> in URNs. There is the urn:lex proposal (not really sure where
>> that is now).
>>
>> There are also my proposals for urn:xmlns and urn:rdf. However
>> in my proposals, the entire NSS is assigned on a first-come,
>> first-served basis: the relationship between two- and
>> three-character ISO 3166 country codes being part of the NSS
>> is purely a coincidence and therefore reassignment of a
>> country code does not affect the durability and immutability
>> of the assigned string.
>>
>> Sean
>>
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.= ietf.org/mailman/listinfo/urn
>
>
>

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/= mailman/listinfo/urn
 --_000_7req9kjyve7mdncaaxk7omij1456091779789emailandroidcom_-- From nobody Sun Feb 21 13:05:46 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6001F1ACE37 for ; Sun, 21 Feb 2016 13:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 5VWWP24k6Esb for ; Sun, 21 Feb 2016 13:05:43 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F221ACE2E for ; Sun, 21 Feb 2016 13:05:42 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 96457509BE; Sun, 21 Feb 2016 16:05:41 -0500 (EST) To: John C Klensin , urn@ietf.org References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <56CA2669.6010900@seantek.com> Date: Sun, 21 Feb 2016 13:04:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:05:45 -0000 On 2/21/2016 12:24 PM, John C Klensin wrote: > Sean, > > I disagree with most of your note. Much of this response is > intended ed to clarify the area(s) of disagreement, not to argue > with you about the points. Well let's clarify the disagreement then... To keep things clear I am going to respond separately to the three major = points... On the namespace-independence of resolverID: > At least for the present, I'll leave > that to others... and to the co-chairs to decide how far we want > to go about the last issue. > > --On Sunday, February 21, 2016 9:47 AM -0800 Sean Leonard > wrote: > >> ... >> *** >> It is said in Section 2.3 and q-component and f-component are >> namespace-independent. However, r-component is apparently >> *sometimes* namespace-independent, and sometimes >> namespace-dependent. Schizophrenia! Is it dependent, or >> independent?? >> >> If it is "sometimes dependent" (depending on the namespace >> definition), then...obviously it's namespace-dependent, >> because it always depends on whether the namespace says it's >> dependent or independent! > I think that is correct and that, if we are going to stick with > resolverID, the only thing that is namespace-independent is the > interpretation of a given registered resolverID (see below). If > the WG agrees and it is not already obvious, suggestions about > how to clarify the text would be welcome. > =20 >> I believe that the WG really should resolve this before >> concluding this work...although it's not quite as much of a >> show-stopper as the ?+ ?=3D syntax issue above. Right now, >> r-components are namespace-dependent. > The document's intent was that the only thing about r-components > that is namespace-independent is the ability to parse one into a > resolverID and a rest-of-the-r-component. That was put in as a > compromise with, and concession to, you. If it no longer works > for you, it can be taken back out, making r-components entirely > namespace-dependent. > >> The question is whether we want to define things like >> resolverID to be "read" relative to the NID, or not. We have >> already concluded that a resolution service will take the NID, >> NSS, and r-component in when doing its job (but neither >> q-component nor f-component). From that standpoint, >> r-component will always be interpreted with NID in view. > See above. > >> Should a hypothetical resolverID "info" be defined essentially >> on a per-namespace basis, or should it be defined as a global >> resolution operation, "get some information about this URN", >> which may or may not apply to different URNs in different >> cases? > Again, my understanding was that resolverIDs were to be defined > independent of the namespace/NID that uses them. If that was > not the intent, then the text almost certainly needs work -- but > most or all of the justification for specifying the ability to > parse the r-component to identify the resolverID also disappears. > >> My view is that the people writing durable, universal naming >> schemes should not be required to be in the business >> (directly) of dictating what resolution services get developed >> or not, and vice-versa. I.e., the URN namespace registration >> template should not require new URN namespaces to specify a >> set of resolution ops. >> >> From that view, it follows that r-component is >> namespace-independent, in the sense that the maintainers of >> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a >> stab at their own spins on the resolverID "foo" or "info" or >> "abcdefg". The namespaces of "resolverID" and therefore >> r-components more generally are global and orthogonal to the >> NID / NSS part. > I hope that is consistent with what the text says. However, the > intent of the text was that maintainers of particular namespaces > _do_ get to specify what resolverIDs are used with them, just > not how a given resolverID that they intend to permit is > interpreted. I am confused with these two statements/positions and do not see how to=20 separate them. I think an example from you would be very helpful. As you wrote: "maintainers of particular namespaces [get] to specify=20 what resolverIDs are used with them". And: namespace maintainers do not=20 get to specify "how a given resolverID that they intend to permit is=20 interpreted". So the maintainer of urn:isbn can say the resolverID "info" can be used, = and "get" cannot be used. The maintainer of urn:oid can say the=20 resolverID "info" can be used, and "get" can also be used. But why do they say some resolverIDs can be used or not, when they have=20 no way to promulgate what it means? It is like saying: "You can use the number 6 in this protocol, but not=20 the number 7. Oh, but you can do whatever you want when you receive a 6."= Usually the party that specifies the values, also specifies the meanings = of the values. I actually do not care whether the resolverID is namespace-dependent or=20 namespace-independent. As I have pointed out, a resolver receives both=20 the resolverID and the NID (plus the NSS, of course), so at the level of = resolver behavior, the behavior will always be namespace-dependent=20 because it depends on the identity of the thing being named. Right now the specification equivocates because sometimes it says=20 independent and sometimes it says dependent. That is a problem. Upon reasoning it through, my position was: "people writing durable, universal naming schemes should not be required to be in the business (directly) of dictating what resolution services get developed or not, and vice-versa. I.e., the URN namespace registration template should not require new URN namespaces to specify a set of resolution ops." This is based on making it easier to register URNs. If resolverIDs=20 (resolver operations) are namespace-dependent, we must expect the URN=20 registration template to define resolution a lot better. That is more=20 work. And it may change over time based on different parties' needs. But if we want to give the URN namespace maintainers a lot more work to=20 do, I am fine with that. Just pick one and be consistent throughout the=20 document. > If your notion that any resolverID can be used > with any NID/ namespace, then it takes on a lot of the > properties that 3986 assigned to . It's more like, "do the namespace maintainers specify the resolverIDs,=20 or not". Does the urn:isbn maintainer maintain a list of resolverIDs?=20 How about urn:ietf? Where is they? (And again, it's fine if they do...but either the list needs to be in=20 the registration template, or the process of management needs to be=20 discussed in the registration template, so the list is stored elsewhere.)= In some sense this is a mirror image of Julian Reschke's discussion=20 about "what is the base URI of a URN in the XML/HTML base usage". The=20 answer is sort of, you can do that, but it doesn't make sense, so don't=20 worry about it...(at least from the standpoint of this document). Sean From nobody Sun Feb 21 13:23:37 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0291ACE5C for ; Sun, 21 Feb 2016 13:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 yQxQJmY1_xAB for ; Sun, 21 Feb 2016 13:23:34 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5BD1ACE5B for ; Sun, 21 Feb 2016 13:23:34 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5BEBA509BD; Sun, 21 Feb 2016 16:23:32 -0500 (EST) To: John C Klensin , urn@ietf.org References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <56CA2A98.4010606@seantek.com> Date: Sun, 21 Feb 2016 13:22:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:23:36 -0000 On 2/21/2016 12:24 PM, John C Klensin wrote: >> That being said, resolverID and the other part after the colon >> both under-deliver and over-deliver in material respects. >> >> "?" is out as a character because that needs to be used to >> distinguish r-component from q-component. >> >> I accept that resolverID is ASCII-only (no percent-encoding, >> and therefore no UTF-8). This makes things simpler. I also >> accept that trying to constrain resolverID to particular >> things (namely a list of keywords) is going to drag this work >> on too long. >> >> That being said, there is no reason at this juncture to limit >> resolverID to LDH (letter digit hyphen). Since ":" delimits >> resolverID from the rest, we only need to remove ":". Allowing >> other characters will provide more flexibility. Therefore, >> proposal: >> ... > a discussion, one that is active and focused enough > to not hold us up for months debating a few characters for which > there is no demonstrated need beyond "we could...". In defense > of that position, I think we should remember that it is much > easier to add (allow) a previously-prohibited character if it > turns out to be necessary than it is to delete one that turns > out to be a problem. As an implementer, that is not my position. It is one thing to say that=20 a character is "RESERVED"--it's another thing entirely to prohibit it in = the ABNF. Once this thing gets published, people will write code that implements=20 the ABNF. You can't add characters so easily. The limitation of resolverID to LDH is arbitrary and (as far as I can=20 tell, since the discussion has come up) capricious. You could say "we=20 could limit it", but you could also easily say "we could expand it". Up=20 until now the set of characters has not gotten much airplay. If you want to stuff more in the resolverID production than LDH, the=20 only way to do it based on the current ABNF in draft-15 is Punycode,=20 just like DNS. Keep it expansive. If you want you can add a note to the effect of,=20 "resolverID is supposed to be limited to LDH, other characters are=20 RESERVED or may have RESERVED purposes in other specifications." (I do=20 not advocate for this position, but I am pointing out how to do it=20 correctly, rather than put the limit in the ABNF. Note that is how RFC=20 2141 dealt with the issue of characters such as "?" and "#".) > >> ... >> Since we are defining resolverID, the momentum is sufficient >> to structure the syntax of the other part. Although I am not >> combing through the history of the mailing list, I believe a >> handful of voices called for name/value pairs, and nobody >> strenuously objected. > Again, I believe the WG explicitly decided to not do this, My recollection is that there were calls for the structure of name/value = pairs that got a lot of serious consideration. If we can agree on=20 name/value pairs then we will make serious technical progress. The discussion faltered on a *registry* of r-component name/value pairs, = but that was about reserving specific names, not about the syntactic=20 structure. Refs: http://mailarchive.ietf.org/arch/msg/urn/cOq7rl_zd4pCPdZ-kpLm-ujBvoM http://mailarchive.ietf.org/arch/msg/urn/78hKQSNHvlBx1RJnPUOczkykkFs If you can point to a definitive decision not to do this, then I will=20 desist on the point. Sean From nobody Sun Feb 21 13:43:39 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972EA1B2B80 for ; Sun, 21 Feb 2016 13:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 m62EUTHCyDHY for ; Sun, 21 Feb 2016 13:43:27 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A501B2B59 for ; Sun, 21 Feb 2016 13:43:27 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DF5EC509BB; Sun, 21 Feb 2016 16:43:25 -0500 (EST) To: John C Klensin , urn@ietf.org References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> From: Sean Leonard Message-ID: <56CA2F42.7090802@seantek.com> Date: Sun, 21 Feb 2016 13:42:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 21:43:33 -0000 On 2/21/2016 12:24 PM, John C Klensin wrote: > Sean, > > I disagree with most of your note. Much of this response is > intended ed to clarify the area(s) of disagreement, not to argue > with you about the points. At least for the present, I'll leave > that to others... and to the co-chairs to decide how far we want > to go about the last issue. > > --On Sunday, February 21, 2016 9:47 AM -0800 Sean Leonard > wrote: > >> The most significant technical changes in urnbis-15 are the >> treatment of q-component and r-component. As such, all of >> these changes are somewhat related. >> >> I applaud the attempt to identify q-component with "?=3D" syntax >> and r-component with "?+" syntax. You get an E for effort. >> >> Unfortunately, it is unworkable, and if there is one thing >> that I am going to be a stick-in-the-mud about, it's going to >> be this. > Alternatives are welcome, but I believe we have been down this > path and that there is (at least so far) no consensus for > blowing off 3986 syntax entirely and that the WG concluded that > embedding r-component and q-component in the syntax of a 3986 > "query" was the way to go. John, I want to make sure that we are discussing the exact same thing=20 since this comment makes it seem that we have different objectives. We=20 have the same objectives. The whole purpose is to put r-component and=20 q-component into the same protocol slot as the query production of RFC 39= 86. > If we stick with "embedding in query", then, as I read the rule > in 3896, the part starts after the first "?" and extends > to the end of the URI or the first "#". That means that > _anything_ (other than "#"), including "+", "=3D", and more "?"s > with or without associated characters is, from a 3986 > standpoint, just part of that and poses no issues for > 3986. Yes. 100% in agreement. > Now, I think there _are_ two issues with this idea of embedding > q-component and r-component in <3986-query>. One arises if > one says "you can't only use the 3986 syntax, you have to > interpret it the way http-URLs do". Put differently, there is > no requirement that the hypothetical generic URI parser be able > to divide the <3986-query> into r-components or q-components > because it doesn't know anything about them. That is correct. Neither of us is saying anything about HTTP or what=20 have you at this point. It's all in a production of RFC 3986. > > The other issue is what we actually mean by "embedding", and is > a more complex question. So far, the WG has believed that > simply delimiting the two substrings is sufficient. However, if > we need to specify that any appearances of "?", or "?=3D" or, most > particularly, "?+" in those strings must be %-encoded and then > that the URN-parser needs to be able to decode one level of > %-encoding before putting the contents of the q-component into a > URL as a , it seems to me that is easily accomplished in > terms of the document and not a big deal for a > URN-parser/evaluator. Ok well here we have a substantive difference, that I hope we can tease o= ut. I am not sure that "So far, the WG has believed that simply delimiting=20 the two substrings is sufficient." Some in the WG have said this=20 (references, please?); my position is that delimiting is not sufficient. = As you pointed out: if you delimit them with ?=3D ?+ etc., you must also = %-encode the constituent parts. This means multiple levels of=20 %-encoding, since % encoded characters will themselves get % encoded to %= 25. History has shown that double-encoding things is a security disaster.=20 There is a whole class of security vulnerabilities where implementations = fail to properly double-encode or double-decode things. Furthermore,=20 it's just not readable. People are going to transcribe these things=20 by-hand too, especially for library things. > It would add a bit to the confusion we > already have with IRIs and where %-encoding is required and > optional, but not very much. So, while I think we need to > straighten out whether that encoding requirement is needed, I > don't see the problem as anything near "unworkable". If it is conceded that an additional layer of %-encoding is required by=20 using ?=3D and ?+ delimiters (because, as I just said, a malicious or=20 otherwise specially crafted q-component could contain ?+ thus switching=20 the URN parser into r-component-parsing mode), then one also concedes=20 the point that the current draft-15 text--which makes no mention of=20 additional %-encoding--is "unworkable". > >> This WG concluded that q-component can contain the entire >> contents of a query component of a URI [RFC3986]. Therefore, >> q-component can contain any production, including "?=3D" >> and "?+". It is entirely possible that some URI out there >> permits "?+" (and in fact, I am pretty sure that HTTP URIs >> permit such a sequence). This means that the proposed URN >> syntax is ambiguous. > At most, only if "?+" is not required to be encoded. See above. > >> Since q-component can be any query character and since q and >> r-components are in the query position of URIs, the *only* way >> to distinguish q-component unambiguously is to put q-component >> in the second position, and r-component in the first position. >> The URN syntax can then constrain r-component not to include >> "?", so "?" delimits r-component from q-component. This is >> entirely implementable. > I think the WG has been down that path, has concluded that there > are use cases for "?" in r-components (even if not in your model > of r-components, see below). To be clear, ? in q-components is foreseeable...in that q-component =3D=20 any URI query, so ? can appear in the wild. I.e., it will appear,=20 especially in deliberately crafted payloads. We have control however over r-component, by prohibiting ? or mandating=20 that ? be %-encoded as %3F. (These are tantamount to the same thing.)=20 There are lots of other delim characters that can be imbued with=20 reserved purposes, within an r-component production. Sean From nobody Sun Feb 21 21:22:01 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9881B3420 for ; Sun, 21 Feb 2016 21:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 b1tB2uchD9j5 for ; Sun, 21 Feb 2016 21:21:52 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0105.outbound.protection.outlook.com [104.47.124.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B421B342A for ; Sun, 21 Feb 2016 21:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=czLs748hkGuGYLTEFaajVMY4UMG5ET6xCWzFu1vLpxU=; b=f2wWBoKYWhAfHq2rwNz2qnLERVL4UkzKLPynMNm9ltKDsDtBzLfLHLeMqPIPLBkMAmqNVPVkimini3XPzWIfK62dtenbtUDbuPni6lc2akpgBZ7mbo7nBD6vMO6F5u7Fl8Dl/6gFNFQWcrYBpKc2v7B25g0BIz5XD5XjuirnQMk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0143.jpnprd01.prod.outlook.com (10.161.134.147) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 22 Feb 2016 05:21:45 +0000 To: Sean Leonard , John C Klensin , References: <56C9F82F.80103@seantek.com> <38F983D67DE97CC5DC6DB919@JcK-HP5.jck.com> <56CA2669.6010900@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56CA9AE6.5020307@it.aoyama.ac.jp> Date: Mon, 22 Feb 2016 14:21:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CA2669.6010900@seantek.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS1PR01CA0020.jpnprd01.prod.outlook.com (25.161.225.158) To TY1PR01MB0143.jpnprd01.prod.outlook.com (25.161.134.147) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 2:GKrGBDSaaSKdYh0fJq8MpMfNwb29PSr3b51s4+kbOkKCzNqi0zskYS8PzzcXfRJKHFmjD+i2A779cahPYzcNFM4LHVFcCLU88ndhn2BExw2UhKj4njqoNXpnIw1RG8NAGRtJJkmwM6lXtnn+aR9rtA==; 3:m/j4lWIweRuiSAFdwHxWzsTYaQAi8LlCRljhO0u93jlmX6ZOyrHLBxdSVkI86eSCiXzbjx3i28sNyIeR/eEwIDpiIRPcKb02Hsju5y5zN8VxaFk4aV5mlcY623NosHab; 25:RkPF2LMt9d/013Xty5CzNvtTa0Cac6XaS4MbVtlao0+ppO9PKPpSyN4YLAanWBXEUnrUNSNCkZ+EqU2M6bF5HnCvj3IZJWUivVSvvnHjW5QUaGPf7QVsjzHoNEkT3OclH7Pz4kOZ8N2B/Gs0cGbxeXxq2syWpxsdbFHXPvO+hGBj+63T8rN5ZzykkHvTGrQuy3cuX94hUsFIpf/A/rUHeonSGE0uAbtAtJ1UiBct/pN0dXEEn2cmNQIL9Bdu9mdsr/nRW1w4L1KQSOO6Ef2wXv5Dee7RDqKeSQXJzWwIjV+fKRfxRCdTOPfAJpOKnJRK8R8eJ4mMh9cVYeNyIuUeCIDp1JvDWj6HH0ZfEcxFJCs= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0143; X-MS-Office365-Filtering-Correlation-Id: 5d879c35-632b-4b1b-b9e2-08d33b480e73 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(9780016760553); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:TY1PR01MB0143; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0143; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 4:lojbaS3UjgPxFlEqTFESOP9Q1tiEf+3sEKlhyd3Ml70B146b4uWxgoqm91zAjw3Eb1uD8A//PzLfwY4FQsJ5JiGk2ndVMevjCGfZNEjs7miFM5GUTzrDj3bRl/uCnOdQSRQvPXczPdWhOK6lyTbnXrSNlEdfySie/OF77MLGUKDf55yrBByD3pfdNSNnwlHWZE7zJqDKfxudpo7MJHlgZ7mvF2DFZGx6/wEvV6qqquvqJsZgdvbLw8bsz57Gqw434oqr7bHqZs+T5cNPLP0SLCbn5ZexcgA420jjhDPOXUSpIkYpAWehhNX+2B6HQJsX+adLlDY1EAXLsjmdk2kdtmP7bdbzL61HNuRw10iJ8AH2evd7l+saL8TidNYbfQMFzz/iHPvBJ6h3EvAx0wms3w== X-Forefront-PRVS: 0860FE717F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(479174004)(24454002)(5001770100001)(33656002)(4001350100001)(23676002)(107886002)(76176999)(5001960100002)(54356999)(87266999)(83506001)(50986999)(2950100001)(77096005)(86362001)(50466002)(74482002)(87976001)(5004730100002)(2906002)(92566002)(5008740100001)(230700001)(586003)(6116002)(3846002)(1096002)(42186005)(65956001)(66066001)(47776003)(40100003)(189998001)(80316001)(122386002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0143; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQzOzIzOkw5Um9HNlVPQkRxdmV3OVhHaHZCSjA1UmhQ?= =?utf-8?B?bUF4RnFDTVdMcXc4aWF0dmU4bTZ5cWVncjY4ekNISWh2NEFzaUZrZWtieXQ5?= =?utf-8?B?c2F4NEFHclc3QXVUc3o0VE1Ja0tTUWZDeHE5TGFTOWExOHk4cTZzcGJGRm9V?= =?utf-8?B?enViYlhJbHUza2tmUmJ4bWZFemJKcEhzeGp0SjlmZVF2SjI0SFF3U3JnMU94?= =?utf-8?B?OVpBNkhBell5WmJwT3dwR0p6S2JtSUUwVkZGZUU4bGV2d2JJczB4d1BSTmVU?= =?utf-8?B?aSt2cnducFA4eDZxU1UxK2EwMkcwQ0dGR2tZN1RTOEZXNnlyTHB3bHEyN2Zr?= =?utf-8?B?TlVpMHdTSVNrTWJQVkI4WE04YWQ2RlA1d2lkaUZjWlpXaSs5UTk3WU5ueCtt?= =?utf-8?B?Y3pXWTJuaHdscjcxZXJaSWg4bTJiRndtK2RwRTIvRjRnaUEyYjF3d0hFc3V4?= =?utf-8?B?WlNBV0dWNWczdVQyZmtJSU9OanA3Nk8zUGhRR0NjSm40ODJ5RlpZNzhuYlFs?= =?utf-8?B?Q2JPcjB4L0dhWDhLemsrOGFmdzRHWjEzZ1hQNXpGK1pUb0g2R25vNlJ1c1Ay?= =?utf-8?B?T1hXNzlYOXorWTZmN1RaT1lrZzRDM3Q0R2Y0aEU3aGVIRjRvZGhDK0hHT3B2?= =?utf-8?B?a2pJNlJEQzZrWjVHbFBlcUpBZjNMb0NGV01USGJDVStkMEkzUFF1QkdFZlVp?= =?utf-8?B?Slh5L0RtUDd1MEZYWDgrMG4xU05GbWlUUDl4ZTNRTXVPM2hsbklOeXBhemk2?= =?utf-8?B?VnNWRGZOcUowZDZpaEZHZkVHdlZXUHZhY09Ycnh0c05WSDdhMHpSMGF4eTY2?= =?utf-8?B?eko0Z2RhN1JuNEVaNnhsRWhRQjhDVWtwM2pTcG1DN2g4cStuQkhiaWFwcjZS?= =?utf-8?B?UlhGRWFCNWIwd1BxQ0pDbGZQUUJyU2RRczkyczBaN1dsS2dsSktmRzNnKzlD?= =?utf-8?B?SDc4aUYzbnE4eXk1aFBEdkRheWxacWMxdFhUdDZIdENlY1YzcFY1RWgrNGQr?= =?utf-8?B?N3JsdlNlSCtjQmIzK0xpN1pWQjd4RS9ZNTF2d0s3RHpiaElWcGsrdkN3R2ho?= =?utf-8?B?QkNoZkhBK2lSaVU0NDFUeTBkR3hjVVJLNjZwT1kxVXFoWDcyMW4yUDRGeXpG?= =?utf-8?B?L2RxaVREVnltWWl2UGpiZTVDem9jeVJ1SUh6dThiWmVYWlRqMzdDQlkzUlVO?= =?utf-8?B?N0lxRk56SFhESmRoUzhTMXBiQUFVQlpJaUNIRlVrK05sUmVNNDZLV1dESDJ4?= =?utf-8?B?RG1Ia0VZejdJWDBYbElTZ2tQZXdsZkxhdXBzM3dRZGxObWdHL0tkUUVseDhj?= =?utf-8?B?dGlmOFpDZUN3ZmdVaVo3QUd2WlJoYUlHOGJxZjhUaHRBTFkzT0pmTGlIYnVC?= =?utf-8?B?RGszTEplN3MxQjIrMEQwclVuWGlGeitodW9ic3p5MnZ4RlhicXJXdUU2YmUz?= =?utf-8?B?Rjl5ekVMRGlsNFNpdU1OYmZiM1NMY01IOHpqeE8zSXVsVC8rSFJyam45REIy?= =?utf-8?B?VEp0dz09?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0143; 5:N8RHQr8A36Wa5GwQ6vI2YZ0lCItylurhxBb3td1y7LVhWWSvAkuBi55oZ8gpJO7r1swTsX/s6T++7876njLAoKOG5hFIOJZwlGM2l2G/2XRZqPgnYawO1ko2BfiXU6ky+nHhXEx7jjPb37bsH9lhlw==; 24:Odm9GkHOGDPLJ6KPaWcRspI/I2WNnioYaMG04Ky4arPZ9WMuVArF7teCmvcAI1CkMVK5ZVIQW56IglLqjRAkRJpKaEL22xhmEBjUdFAZgx8= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2016 05:21:45.2864 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0143 Archived-At: Subject: Re: [urn] (urnbis-15 review) the new abnormal: q-component and r-component X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 05:21:58 -0000 On 2016/02/22 06:04, Sean Leonard wrote: > On 2/21/2016 12:24 PM, John C Klensin wrote: Sean wrote: >>> From that view, it follows that r-component is >>> namespace-independent, in the sense that the maintainers of >>> urn:isbn, urn:oid, urn:ietf, urn:nbn, etc. do not each get a >>> stab at their own spins on the resolverID "foo" or "info" or >>> "abcdefg". The namespaces of "resolverID" and therefore >>> r-components more generally are global and orthogonal to the >>> NID / NSS part. >> I hope that is consistent with what the text says. However, the >> intent of the text was that maintainers of particular namespaces >> _do_ get to specify what resolverIDs are used with them, just >> not how a given resolverID that they intend to permit is >> interpreted. > > I am confused with these two statements/positions and do not see how to > separate them. > > I think an example from you would be very helpful. I think I understand what John is trying to say: If there's a resolverID "info", and that's (for simplicity's sake) defined to return info about the author(s) and the length of the document in bytes, then it's not possible for a namespace maintainer to say that for the particular namespace, the "info" resolver also returns the date of creation, or doesn't return the length in bytes, and so on. In other words, opt-in for each resolverID is binary. That still leaves us with the problem below. > As you wrote: "maintainers of particular namespaces [get] to specify > what resolverIDs are used with them". And: namespace maintainers do not > get to specify "how a given resolverID that they intend to permit is > interpreted". > > So the maintainer of urn:isbn can say the resolverID "info" can be used, > and "get" cannot be used. The maintainer of urn:oid can say the > resolverID "info" can be used, and "get" can also be used. > > But why do they say some resolverIDs can be used or not, when they have > no way to promulgate what it means? > > It is like saying: "You can use the number 6 in this protocol, but not > the number 7. Oh, but you can do whatever you want when you receive a 6." > > Usually the party that specifies the values, also specifies the meanings > of the values. > > > I actually do not care whether the resolverID is namespace-dependent or > namespace-independent. As I have pointed out, a resolver receives both > the resolverID and the NID (plus the NSS, of course), so at the level of > resolver behavior, the behavior will always be namespace-dependent > because it depends on the identity of the thing being named. > > Right now the specification equivocates because sometimes it says > independent and sometimes it says dependent. That is a problem. > > Upon reasoning it through, my position was: > > "people writing durable, universal naming > schemes should not be required to be in the business > (directly) of dictating what resolution services get developed > or not, and vice-versa. I.e., the URN namespace registration > template should not require new URN namespaces to specify a > set of resolution ops." > > > This is based on making it easier to register URNs. If resolverIDs > (resolver operations) are namespace-dependent, we must expect the URN > registration template to define resolution a lot better. That is more > work. And it may change over time based on different parties' needs. I guess I'm with Sean here. Sean maybe implied this, but I didn't see it stated explicitly: It would make introduction of new resolution services (which might perfectly well be able to deal with preexisting URN namespaces) a lot more difficult. We don't have any magic to update specs or registrations automatically. So at the most, I'd want to limit us to something like "Namespace registrations MAY indicate some of the types of resolvers suitable for the namespace (by listing the relevant resolverIDs). Such a list does not restrict the use of resolvers to only the listed types." Regards, Martin. From nobody Sun Feb 21 21:28:56 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAF61B3444 for ; Sun, 21 Feb 2016 21:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 olunZ7FrlDq6 for ; Sun, 21 Feb 2016 21:28:52 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0139.outbound.protection.outlook.com [104.47.124.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6759A1B3443 for ; Sun, 21 Feb 2016 21:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kYe9fm7GfwEmqwe5g9fWDvneqD9i1fi91mOM9pzE1Cw=; b=OBzJwsr1vXBuCLR2g/tl4tZ9POYC+uU4LrCTAlXUT74ashtFae+YQYtQM+TX4RZJnAc/yZ+xkHFmnl1zV7wrtyL9B+u0dwcMwv2cw1WoBbGkTyF2O0BgCnPily14n7PISegunwJx9dAOvwMz7mXnjaffzoKdBnZ3hQEptjjU+iM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0144.jpnprd01.prod.outlook.com (10.161.134.148) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 22 Feb 2016 05:28:48 +0000 To: John C Klensin , References: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56CA9C8F.1040305@it.aoyama.ac.jp> Date: Mon, 22 Feb 2016 14:28:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0016.jpnprd01.prod.outlook.com (25.161.131.154) To TY1PR01MB0144.jpnprd01.prod.outlook.com (25.161.134.148) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0144; 2:TG6uYsq9OrCHkHKwF29tcEVP/4cM2s3iH6J4hzEQ0jvyHqEB+iXxkPDunh04BF3wWuHZE0O/Q2pR3VFBIaJCX6f6Kgw+zEZLEP9YWgnMHd1mCrtwAhf9YA1MBeGzSUi/rvD3j0uSUvQaD0LxiDPm0g==; 3:AXJ8TbYvj8ISik4rPMF47etlb7amQUa5POyM57Lsr0joptFNrsbohE71aDKQ7mcwjxNVH5b08++qZx2YdU9CMEHZ2KMgAw97a2xebVqmfCPX428O3idxLQVqknfM4vA5; 25:IyPx2ffQM/4AgyUJA0JqqmmxyomNHC1zbjs3yxA15MrhToDmxUuqFOJZzSzoFSjLFr9ExkRWHIhUjpxPstrnwpoO5KSoV9RVbwgU9rhco96vZWs1cBKWrNCqejp9iTngGTXlMXR4j29fnaeOq+gyVHNiP/ZeCYckKl4EeYOkT0bQQXCWnjz/mqqmEMLcXSBKnBaEt9pThaifjYR7je99+smauAZuSbaJRXIqWf40GAQkXt2zuoHUDcBmU9rGufmxvp3XDyOKZcfGQOsCGCzEucRxL5uEzkTnIdydbU44j5pUprK0Tdil5AhWyZvXBKWqor+hMFFEcKBlFGYYKnp5AG847+fMu1lHPP3/fn3QFi4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0144; X-MS-Office365-Filtering-Correlation-Id: 2b8d3235-0c0a-4a4f-71cc-08d33b490a7e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:TY1PR01MB0144; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0144; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0144; 4:EuCbP6jBwa9ukCOyFER/Hi/HNvgly62FNB/G9Kg9LuP30N3QaTICL2ymzcYuVyMKP5k3AIPry/XiywCTyaonsPd/3df/sdPNKPvmPCIa3dMmipe119PK/VGLZIL/nVthqkEAeCwT30gb/gjn5asxH6wh56QwZ6eh7tLR2DyvRvGQ2RKpyIvxYk/NP00WynIc5ac5vLpmmx6X8U6S9+BMuM5ACsYO28qXZOdRNpJmmMGcG3mKhOIWURg9ZvJiZMgBZJoEXbh9zgV6u95u8hO847MTAHFARq5qK0MJV9xQOq8e0mOmrQvdfAiwPDYYPB7Q3R1+w1fH/6sTvTJbHrNpbPxoBkL3T4HZgD1F8bRzhKY= X-Forefront-PRVS: 0860FE717F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(479174004)(24454002)(5001770100001)(33656002)(4001350100001)(23676002)(107886002)(76176999)(5001960100002)(54356999)(87266999)(83506001)(50986999)(2950100001)(77096005)(86362001)(50466002)(74482002)(230783001)(87976001)(5004730100002)(2906002)(92566002)(5008740100001)(230700001)(586003)(6116002)(3846002)(1096002)(42186005)(65956001)(66066001)(47776003)(40100003)(189998001)(80316001)(122386002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0144; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwMTQ0OzIzOjl2VzlFeGpWSXROdFljRWVvOVZhdVRUYVJ3?= =?utf-8?B?RktKa0poR2RnbTRjdnFUMnFhVGJmU21uMTBNSnh2eEpBcERjUUVpT29pNkdQ?= =?utf-8?B?b3BYZWdSTlB1T0RJa284Y1hoZGVKd1FIZmNSUjlnVWYyUGlVUCsvSnBmejMx?= =?utf-8?B?SXdmSHkzaDNvYXR5c2h1M1F0K2tpOXpZNGE5NTFpb0FWbm9lcmxPNGVzb1dq?= =?utf-8?B?YW1nVERTVXVSQ01DQ3JDMzBXMGhkZFl5bkVubmhiRnV4RndPYy9FbzdNYmw2?= =?utf-8?B?TEtzMDZIbHVuRzRCckFpUUhDMk8yZjJIWUk0REE2eTRDSmRLYWtSalZDdThh?= =?utf-8?B?RHhVSDBjcURCU0dEZ0d2em1vbWtDY2tzKzJRWUhYZlNlckRrd1dZSFVOaWtj?= =?utf-8?B?ekx6RjU3Y1FFbFJIdGUzaHRmcVNKQndxRllNdE05WFl1M0lxdnlnZ3Y3eGM0?= =?utf-8?B?VEFTNC9JemRQZ216eDE4NXc2OUtSZkRYY3FmTWNaS3lzeHJRQ1Z4bFYwc0Ns?= =?utf-8?B?d0dSOS9BMmNyeDZ1NTViNkNlcVJjSmdmYlVJekZLZ0JINVhxTGJ2aERYaDlW?= =?utf-8?B?cnhCZVhoQzVGaEJyL043M2Rhcjd6OWFIYjVSSThPZnoyNk44QWxONFltYVVl?= =?utf-8?B?UjQzc2VSOG85NHVwWnkwbU5yMkNCR05yQ1BlVGMvUXhWakFqV2VqSzhmZ1B1?= =?utf-8?B?RG14TmI0ZVRjSmplL2VpWXFsaldZZXlONGdKdXIyQVYyQVBmTWJHTUk3TXM4?= =?utf-8?B?UFljNEphQytOTWk3SU10aE54S0t2dWhnb0NNK09aRjZvdWhjNnVWUzViVEdS?= =?utf-8?B?L3dCcGVDbGhVbFJURzBvUWlWREFpZEVTRCsrV0pTZG1xV05RZkFvUW00UjAx?= =?utf-8?B?d0llckhxemRvSlBkOTVNTGI2SjV3aURDbTluVEhYcVgxblQvMGdONkxuSVZ0?= =?utf-8?B?clFlaFlIOExRVGc0UXJrZi9mNUlwVjBvYTZGK1BpYUZKK0ltbTJvRktQdWNW?= =?utf-8?B?QVFrTXhpS09mSGw3UGtoQW81VUI4ZXJwT1ZZYjlSZ0JvRGVwSVErTFFyZXJs?= =?utf-8?B?dTA5cXR6MFZLeXlNWG94ZFN5SFZuUnQ3dTRaamNlazF4Tkx5SGVYOFJJcVRX?= =?utf-8?B?eVFTODJlVHpxMS8xUjVKQjYvQ3lBemFuUjRmVjZLUUlkeWVZVVRuVGVNKzFQ?= =?utf-8?B?azQ1TXp1ekJPTWhGekIxdUNVRjVzNzBLRXhIVVFOMWQybEhCeVFUenE5RkRV?= =?utf-8?B?TFh2NDVLR2UxNzhod0xDMm40eHYyVXpLMFN6QUhZejJlaVd1d2FuMW85eW0x?= =?utf-8?B?dVYrbDF2QjZTemdSWEl1RnVVS3k2U1BKRUZLU0xNQzFvbU1XalJiSGsvWUt5?= =?utf-8?B?K09ZejdoTnVYM3FxSXJka1crU2VJYU91dS9abEpRYjd5dEJZaWtDYmVlSW02?= =?utf-8?B?TDdkZWpNb0l6ZitPZHVscFg5OTZUWnQrTWJEZmZ2QmZ4S3dtSEY2Y2ppZVBw?= =?utf-8?B?b0tmQT09?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0144; 5:MI19CxCujUp/fZUEDYzgU8djHyWGXXRRrvafl8zqPDgc3e+rp1npRkmu85wuGYqKZZHp4HuylAVjOWpbc+zLcaWAlTsxl62ZqadQY4IavBEqESOPMlY6mXw6eTyn9/C78Wdx+9sVcEb8vKuLMTr91g==; 24:IJ/fuEkdxInd0renM0l+vwxplUYUPKJRMLeKBTW3PcAtmG11BNFazbyIgsksBG5Ps32kzOLM5Cr9N6m8On2GSc21jYyQ1j8NwXtLRlBESYU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2016 05:28:48.3457 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0144 Archived-At: Subject: Re: [urn] ReL draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 05:28:55 -0000 Hello John, others, On 2016/02/13 23:49, John C Klensin wrote: > Hi. > > Writing primarily as the pen-holding editor for -15 and the > likely one for -16.... > > It has now been over a week since -15 was posted and there have > been absolutely no comments. I am fairly sure the mailing list > is working because there have been postings about two URN NID > registration proposals --proposals that would presumably be > handled quite differently under the new, 2141bis rules. On my side, the main reason is extreme business in my day job up and including yesterday. It's not that I suddenly am on vacation, but as you already may have seen from my first email on the subject, I should be able to use a bit of time on IETF matters, including URNs, in the next days/weeks. I definitely plan to have a close look at what's said on I18N/UTF-8. Regards, Martin. From nobody Sun Feb 21 21:33:23 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E40C1B345D for ; Sun, 21 Feb 2016 21:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 bOzk_aNc0KTK for ; Sun, 21 Feb 2016 21:33:16 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0134.outbound.protection.outlook.com [104.47.126.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446721B3462 for ; Sun, 21 Feb 2016 21:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GcJmhg2veUdRf8lPUkumi7Zz7XAUXAkm5m9ucqAErKM=; b=bRaet8ZgC3DKW7QXsCvt4ys16MgQrYuY5IhJenI11LuwNvB0bYbTOgbOO3HfcS/g5e0BGLFKLCRbPfH+3HEi2d3UAPML1FLrKjh0e0UIBbxfV6JrC0EbZIKvRpdee/AtolzG2qdwSgR42ic5V1Vkd4ZZaN/FDqa+KU7whsaVGFw= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0139.jpnprd01.prod.outlook.com (10.161.77.147) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 22 Feb 2016 05:33:09 +0000 To: John C Klensin , Barry Leiba , Sean Leonard References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> <56C70B14.60702@seantek.com> <87CE19143D4A23743142D66D@JcK-HP5.jck.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56CA9D95.6070000@it.aoyama.ac.jp> Date: Mon, 22 Feb 2016 14:33:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87CE19143D4A23743142D66D@JcK-HP5.jck.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0016.jpnprd01.prod.outlook.com (25.161.131.154) To OS2PR01MB0139.jpnprd01.prod.outlook.com (25.161.77.147) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0139; 2:M3y8e66FQ2cMWacbd9AmWFHZqOnbOM8WHbdQ3KyNenFfHY3URK+HQSlHquNEYRJI/kq+4kRyP1OTG6i+ACuF3vooRKcMaJWkl7Lo2rf6dn1q8tApOoc5ltuU/lC6q88I7QkoLmlpLZeQv2TK1G4UkQ==; 3:3duRz5gm9U5vrQBtatng8807B9YYtvE2cNiqO/tmYu/ASD4N1CYF21/761YC0VfsRuEDH6/pP8xyEo2htl9UT7VLx5Bug72tuZhRxlADUwIbhd59c7IpStbWDaTggoWG; 25:HfWWHNE8phxLvznsmuR93/ZgnPnIpMAakPy180VO3XOpLmEi+hpAjwqdsSNUrvNyuwmtYqdjPtC/sOKBVDY0wlYfKXilv1TyHkba9chYtnxf4/3buXRh9T5u6Md9chUSw50V1GHVE3lZdZQqlENMoD0URuYx9vMEXh9n5AvCTyi+K8VrS0GCB/i5BvhODvVq24Pu/D8ZqOSwoUX4WaPQyMbaoIT8ECOTeMo3+WCYFLWZUwiQEArClwUNeiLTjpuUQku366/K23Y7U+RkWmGkPRDvrOcTINevz8t6oHBiO3RuR0qx8Djq3+dgvdUASB0HxRXhnm2pFXngmoK6gazwVJamGEhDMFNSwXIke4rR830= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0139; X-MS-Office365-Filtering-Correlation-Id: ddf44f07-56e4-4ed7-5d3b-08d33b49a66a X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:OS2PR01MB0139; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0139; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0139; 4:aqloZsXCrzHb4JG9/qm5h4SdA92p2nW5g9HQGuMR5kDFpt8oA8Xhb7vZY/Li0aIGZyYJHK3ToK1P18gkP6USWxgi/CtUDMyScfyIK9yGW3Sy4518yFB6zDROWAKC73LitfQ0fL4MZb0+N4vSc1BPZCIRjvVOrp3AroEhPfV0PlylW8BBMR3bSCE5CPvWTQSmnjAy194eZ5LMs/1i1qPpk987uk2DrolsAUIOls+1EqoiNOc6hyYtfaxnOkqVxhfs40cYSoURCgFlN0DRGOYs4NBAomO/uFrMhWVpfvFti6evFtADtE3RJbc4llrMvh1F2hKUjtFfVAwpbJ3CYp3KhFVj1nog7XlUCeq5dUSD+kg= X-Forefront-PRVS: 0860FE717F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(479174004)(24454002)(5001770100001)(33656002)(4001350100001)(23676002)(76176999)(5001960100002)(54356999)(87266999)(83506001)(50986999)(2950100001)(77096005)(15975445007)(86362001)(93886004)(50466002)(74482002)(87976001)(5004730100002)(2906002)(4326007)(92566002)(5008740100001)(230700001)(586003)(6116002)(3846002)(1096002)(42186005)(65956001)(66066001)(47776003)(40100003)(189998001)(19580405001)(80316001)(122386002)(19580395003)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0139; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMTM5OzIzOmVzenJWOE53SW5vRmpRZTI1VlVwd2N1NnBL?= =?utf-8?B?em9HbkVqL2UzQjFHcTI4NVNOeHlQT3U1Njk3Q2gvSHpMc2lGVXByQ3pORFBt?= =?utf-8?B?UHRjSGROTHRaVk9uSTZoWHhFN2I5Yll0dXFNZ3YvM21QdDFxeElJKzN3cTVX?= =?utf-8?B?Q2JFQWJzbHYzWDJaN2gvSUQyczBwS3RqZFlEMTB3Y095UTRXYVVhM0dsMU9x?= =?utf-8?B?N29xQndJMlVqV3lHQ0N0aCtsQzYzRXN0YXluc3F3UWQ2THpWUjBuVmJkTTRJ?= =?utf-8?B?a3EvY0lOU0N1bEF1b0dwcnlXMmVuNU5qeFFUbVJ2TWRRYktMeEVHbjRVZzY5?= =?utf-8?B?RnlCcThPUmNVbGdUeG5pSUtBZFZBZXdvaGFIREJFeWpzVDFSUWZxeU85RCtn?= =?utf-8?B?emZyMGdZZU9ra1ZraVJxcmZNRUtXQlpjKzRjMHpBVGxPclVIL2pNMDl0UFpr?= =?utf-8?B?aUUzMU45WDRxKzdTT3ozRzc0M05RdDdsQU1CVFBxR01nUDhDaFJqSFdlV0Z2?= =?utf-8?B?VEkvU3A1c2lVYnVZV0ozak54RDNxd0x4TllCcElFMHVhakZhUUZMczNoYkVy?= =?utf-8?B?TWpiQWJ2YVVXUWhoN2dzeEYrTFIzR09XMnA5b0gycWtvYVlEZmRxMnNIZW1p?= =?utf-8?B?ZVVhTlpNN0Q3K2NTcnpnT3J5dXp6amc1a0xIeCt2cnIrZGw1a2pSelBySzFv?= =?utf-8?B?WThJUHQ4MEp4UUpyNzc1M0o0LzZzMW9WMmRORWVXNVo1WUxqREg2aXdzbUhn?= =?utf-8?B?Mmw0OUNOMmNMdmgvRk1PQVJmWnpFaCtaMmRwTnlaS0c5NTNtWEpCS3MrRjU0?= =?utf-8?B?VjRkbmxPTzVqUzhWZVc1WTZUM0hib09FeHVLd1BqS0toR0huUThVNmhxaVBM?= =?utf-8?B?NXpua1Rhd0c3VWxNTEdYZ1NYcmV0Sm5jZjZYaGQ0VjY5YWZDSzJFZVYwQkZ4?= =?utf-8?B?NUh4dGdKTlNVamd4dHFOTTRSQ2ExRGlwd2VrRzR6U2IzNFFRQk43RlVGMEFS?= =?utf-8?B?TTJIaFhQNUVEUVh6UVhRMFRXTFJsSk11R2VvUTZpRzhrNjhubncrZlBvQkhv?= =?utf-8?B?SHFTRVB3SEZXUmx2T1dBcHNoT1ByUHhjU3Buby9pTTFQUmgwWGNRQ1FDS01q?= =?utf-8?B?clh6RUxmM2R6VlVCbTZBL3ZUajlXSG9WbkZmcktlN2h1ejlISW03anBvYy9R?= =?utf-8?B?TzhzaEtxa1FRKzFVK1Fhbk56NW9Uc25qbmZ5aUpQaTlJTEFNeFVKK053L3o2?= =?utf-8?B?bmZ5b0JIRmxXajZ4allUdVo1S244ZjYyUlVlbk0vY0loRHg0MkxTNjNoTlY2?= =?utf-8?B?ZWpDVE5mNHoxbGlXRms4MUx5YVR2ZmJlVlpYUkpKelRSaExGaGx5MThkZThr?= =?utf-8?B?NTRpYXdvRDIycXBBemxYT2Y1L0Z3d0lzN3AzdmtMdG1TcFhPQ2RVdTlhTENy?= =?utf-8?B?SzdKd0pzeXhTUHp0em5Eb1g2dXovOWdCZ0RMZ0dWcGhZVThtdG5kRSs1QURX?= =?utf-8?B?NlBneXZuRitMYVdpcDFjQjRjbHpvK3MyQ3VUZFByK1B3RzhQMXVrOUxNZHp2?= =?utf-8?B?ZWRGRHE1TVRBT2dQMzJnc1BjdHZXQ3RPa1hlOWFPc3IyV2E1UUIyNm1LVHpV?= =?utf-8?Q?dcsKjfNQMWjUQk4V7ZiK?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0139; 5:DeL13UGtMuNT8i0QfTl0cQ/HUYgO4dlXPwDL7oVhHHpOSNXuqbg/wDFwLCMYMpwTWncOSgd4kqyz4FTbQ2FYs1xcJ+v5hbndGcYfadjahQ3C6EqQ+7zHYOeYH9d1hqMXr7SR11hYbb+ob7YwkHFQDQ==; 24:d1ULZEw7iVwzrpab1+7pRhfE4uj0WK8Rn+uVivNWaSBlft3mhXg7fgW+duV82vX3czLH9Hdl5gn315JLC+ltofp+vg5EiN5UFsH/iPaVJmM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2016 05:33:09.6886 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0139 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 05:33:21 -0000 On 2016/02/22 02:36, John C Klensin wrote: > --On Sunday, February 21, 2016 9:05 AM -0800 Barry Leiba > wrote: >> Further, I would say that the intent of URNs, as well as the >> actual need in the field, is to having different URNs for >> different versions of things. For example, the RFC Editor >> will be making RFCs available in plain text, HTML, XML, PDF, >> and possibly other formats (some form of markdown and so >> forth). Those are all meant to be substantively the same, but >> they won't be exactly the same, and they'll have different >> URNs -- not one URN with some sort of parameters. > > Barry, > > While I agree with everything else in your note, the above > example is less clear to me and less clear because the > "substantively the same" part. So, just as I can imagine > http://www.rfc-editor.org/info/rfc2141?format=PDF > as a plausible alternate to > https://www.rfc-editor.org/rfc/pdfrfc/rfc2141.txt.pdf > in some brave new world, I can imagine > urn:ietf:rfc:2141?=format=PDF > As a URN whose intent is to name RFC 2141 (everything up to the > "?") and to "resolve to" any of the locations at which the PDF > form of that RFC can be located. > > I think this sort of thing has to be a per-namesspace decision, > lest it make us all crazy. If that decision has been made and > document for the "IETF" NID, or even for the nid:"rfc" > sub-namespace (whatever those are), I don't think I've seen the > document. I agree mostly with John here. Even more, there shouldn't be anything in the specs against just using urn:ietf:rfc:2141 because in many circumstances, I'd not worry too much about which version I'd get (I'd assume HTML if I'm in a browser,..., but that's a separate issue). Regards, Martin. From nobody Sun Feb 21 21:43:14 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35791B34BB for ; Sun, 21 Feb 2016 21:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 EIl3WSfGOUHF for ; Sun, 21 Feb 2016 21:43:08 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0110.outbound.protection.outlook.com [104.47.124.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2991B34BA for ; Sun, 21 Feb 2016 21:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yHlazZ6XHe9HvefATH0k+yOYPeNNkX4152F7Gj4Jp+E=; b=MZGznrW0u73SWee8eKDd3iWqkFdz7VpwW7lPiM967ew5AWMygAzI0tZyWbXiw6nfh074vrWBq+mPbiNprsHKqeRRfcOphTVFzl1/emzOKShIGNLA8sFyr/s+Tr+BX4f5hBJp/9r7P23UV9PDM3/9gzfSE9K9vdMTLvaTr7cfGsQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0129.jpnprd01.prod.outlook.com (10.161.26.21) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 22 Feb 2016 05:43:03 +0000 To: John C Klensin , Sean Leonard , References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> <56C70B14.60702@seantek.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56CA9FE5.8080407@it.aoyama.ac.jp> Date: Mon, 22 Feb 2016 14:43:01 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0002.jpnprd01.prod.outlook.com (25.161.74.140) To KAWPR01MB0129.jpnprd01.prod.outlook.com (25.161.26.21) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 2:09FKG1/C2iuVk149EkRUOm0N+XACvD8tiAgNu+inKmrKjb6eP5oZfOyOXGZLemMgYxK0COzSxXy2C4ZmixeTpyEHiptXAEi3wZKImJWUbLrYDA4RDRJbGJjXkRxTBEIHW+NPBKVsNk9FDysFTdTtkw==; 3:uUczMguQWoaC/Ay5olJrT96sCh18Os5cg7pWTDmh6oga0uSV4NQBUst/6KyeRFAtnUtIB+OUqRagZ/3nOxF9e8GFOMLjP+hNxp+YjSjdWH226J/gRPNvx3bPiSMSjfhn; 25:mluZzPZULDkckD2oHDwtdf3ar7bO5oiCYP40TX5fuKq0aFZq66T/OxNiyPLLq8183PX2O8TJQq4j6cy9D0HEMd8y0PMdU5JlSeHGuLnY2mFlKArUFPgiEl9/tp9DKwCLm/RCKfp5rmp6uB35Dodi6vwDos77qjk9RpfjMkURGZ7P7US9QKnvMUqLVecMhMdCj+k49B2VJenUPHhBA/ko1moqqOTEnHG8zCUKfbrrafR7nbmktbdEzmnqTNd+yivBN19w/yZg6xgvzfD79xpX3/ZgQjvN+TXbhQo1iT+qIeK3zJGUIXqx48aH+3a1kTyYPUUKGJJ0OsSuiuaFqT13qfg/CI6EP+E2RdUZdRd9ubY= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0129; X-MS-Office365-Filtering-Correlation-Id: 1db88e6c-c00c-44b3-0a7b-08d33b4b085e X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:KAWPR01MB0129; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0129; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 4:1e9SePhvnoTbNZtOicrV0UPaMMbUqMj+sEax+9LMBEXALg20AfefITTVEtLWRTLCpN9CaKJ5lYHZBnjpLj2ei7wbFYTdHFp5rCllBqmxEyj0HWSbx08gK2Z5iHglqbLR2XQ+arIEUT2lKMUAB02fRio8AyM4Hx6slJ5+zgWVj3lzhdkL35j6MiVWELBfR6k3++GhaDmBklS2UZGQgnHvlEjYFGveDT4wKJ4626G5OY2yjg4+AuDwWAZ467WNjw9zFE8wfmG4MjNp0g6/nr0rq5w9m2iph/wzeFfDP/1cm6kPlGVX1Co8AjwqgWDHVB+Hiv6WTAYSF09NvURw77Ahh96H2WqkJQBauah4CZrmYeE= X-Forefront-PRVS: 0860FE717F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6049001)(6009001)(479174004)(24454002)(5001770100001)(33656002)(4001350100001)(23676002)(65816999)(107886002)(76176999)(5001960100002)(54356999)(87266999)(83506001)(50986999)(2950100001)(77096005)(86362001)(93886004)(50466002)(74482002)(59896002)(87976001)(5004730100002)(2906002)(92566002)(5008740100001)(230700001)(586003)(64126003)(6116002)(3846002)(1096002)(65806001)(42186005)(65956001)(66066001)(47776003)(40100003)(189998001)(80316001)(122386002)(3940600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0129; H:[133.2.210.64]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTI5OzIzOmVFSkswRjVRTDh2RUtyRkoxa2lsZXFlRW9u?= =?utf-8?B?RFNkNkxBbk5yQ1hRYjVjLysvL0NBckpNQ3c1anNvakhUSGQ1U3UxVjdEenRp?= =?utf-8?B?V2ppbGk4VmpFbDBoYkJpb0p4TVhkWjF6Wm1SSU1Vd3RjNllVTDJPMnI2eVYz?= =?utf-8?B?UWFTMTd2QjhjYUo3WlhWMjhnSzN6Y040UkdFcDhYS05MUWFUcGlsL3BYNnJn?= =?utf-8?B?QUhKSlBSbVJLc3cyQ3NWaEdHRWw3TEQrREhvcENoazB1NVNSVVI2TXdsTGZs?= =?utf-8?B?aGZ3Z0U5R1R1R1ZpUGN2WWY2U1pXZjZkdmRTU0JGM1JGMXZuQ0lsMW5XaWt4?= =?utf-8?B?Mk9MSitnUTRVYkVkMGhBeW05VXpKOVg5dEk2SGFJT3NIMTRueUFtRjFPVzFs?= =?utf-8?B?UENFT1lMOEtJUU4ra2s3NWVUTUdqLysyMEhqUTVEQU95SFVwR1FORXVGN01I?= =?utf-8?B?S2EyQXVRaUcyZDRCR0JQU08wY01lYVE2SzRRVElXQ25QR2huanNOaXhjM3k4?= =?utf-8?B?b2lFZWFVckIxSWM4UWMwQkMzOXIvWHNtSU0zU1Vrczdydi9HejBVaDVYSFF6?= =?utf-8?B?WlVSdTBYVnNHL0JjeHJhTnAzTC90Uk1rQmlqTTRLRlNWVzFpZXFpdXhQU1Fs?= =?utf-8?B?YWFpcFFySUk0L0FiclN0dHlWd2lJVHJZTVNhV2JkNGVCL1MvaG9STklHRVEv?= =?utf-8?B?eVVLU3drbk9jTFNsVjV1cUtYVXdBYnBDLzhTOEpFZWtBNXJjZ0dlMWhaeTRL?= =?utf-8?B?MWR1SExRNklYQ1lBSjR4WFBYWjRweUdNSXFMbGhUL3Zoa3VNaEhwYnRRbWZW?= =?utf-8?B?YysyWjNkM2oxLzlrQld4aEFtRURkK2dzK1Z1RDNyV2lQQkpQSlNwVzBvREg0?= =?utf-8?B?dkN0SGt0T2dIQjhTbTFneTRYQkhicjJ6QnduOVArbzhCZVRteVlXck5NeGNk?= =?utf-8?B?VVNlNEErd1AxZHN0Z2Z2TlJLKzVqVlNZSkNUWEIxaVlVbTVNZVRTNDdGd1Fv?= =?utf-8?B?SkVzU1pOdWxDRll1a2FaczMrS2ZEaUdBc0hPRU5uUFB1NkwxQ3ByVG5pQjZ1?= =?utf-8?B?Vk5WZkg3QWJFbTZHc3habXVmYVUyNkRQeHlwbC94SlVtQ3JPWE5xa2xSL3Fa?= =?utf-8?B?ejlvTHFOVCtsaFYyS2VQZGJJUVZXU09ocFJvTkNhdFBQcm5ZeEdZRGo4Mk9l?= =?utf-8?B?azVJOTdGVUZhZjUxb2NXUm9BZjJzMUpGbEhUallCSW45L0hDOE5Vck80WVgv?= =?utf-8?B?eU1Uc0NKMkdxTFVlWWIrUXVhT29OeEVURWlFSDc1WldnUHBkRkQ2NEpkZzhq?= =?utf-8?B?a0IwQlVpSys4TEZHckNiVlJCL0hrMHRVb0RyTUY0T3gySVNJN24wS2M5WDJZ?= =?utf-8?B?d21kNVk0MVM0cTE2NGFlRzlSUVdkR1UrSEdjVW56T2IzOW4rQ1NDcExMRmRY?= =?utf-8?B?VXE4MTg2OUJTaGhCY1laaHJYZlNNK1ZTbEhLNlRXNDJBWWIvbm5IRjNEQjdE?= =?utf-8?B?NEZQTDFKcFNCSWJEclBVMUxxY2FJN3RYakZuZEVkWXJRMHRpak5NU1FnSGtz?= =?utf-8?B?bGVhN1RVcWc4UjFlaFFYUlVnd05ZaHVJLy9ZUVowN0lNSUhodmJuRTFDSGpx?= =?utf-8?B?L0E1ZldqSkM5bkIwamEyQllOdk1Kb0VDZjI0ZlVTSTE0SmMzWkt2SkxMNFRn?= =?utf-8?B?Mk53Zm9kVW96akFNYkxqa0J3c3Y1aFQ5alV4aXQveXBHQzg3VjNHQXVwRko3?= =?utf-8?B?dmVVSEhZYzlQTXEwZUxZZz09?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0129; 5:mS/U+LFo/45clLKSObayCq53sPlxIV7B8evpmspLmXYNvCpAD4ec1xRogI+wmW4UE5mIV8zjanRPoS3MSq9IHzIr61o2jTIPK38/YGmVy2oFT1hPicewi+30lk+n09rLIZhhgljMrRcoAhL4zKhWQA==; 24:ZYud92VlPkn+ZMrNPe6+OA7ZizU8jBZ+hrjhhQVIImM5FY49/nF/m/jsFWzqtIYlw5OZGXRAiJgW7AwV3nad+bLfU0q6lh4rxuAq5SxoPeg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2016 05:43:03.5369 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0129 Archived-At: Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 05:43:13 -0000 Hello John, others, On 2016/02/19 23:56, John C Klensin wrote: > Hi. > > Partially because this WG is years overdue on its primary task, > when I read through the comments below, what I mostly hear is a > difficult and controversial task and area trying to suck us into > a huge rat hole, and to drag everything else we are doing (like > 2141bis) into the hole with it. I think you're hearing wrong. What I heard was a request for information from somebody who figured out that if anybody, then somebody on this very list might know. That was responded to by comments of the nature of "I think you might find something if you dig deeper", "here's a person you might want to contact", and "here's an aspect of your question you might want to make sure you cover". At no point in time was there any suggestion of a direct connection to our current work items. > So I'd like to see (and recommend) if this can simply be ruled > out of scope, at least until the three current documents are > complete and finished with IETF Last Call. I agree it's out of scope for the three current documents. Nobody suggested otherwise. But even in cases where a WG is very focused on its current work, there is the chance that there is some inquiry on the WG list about related work that is best made on that WG list. > In addition to the comments that have been made already, it may > be useful to remember the following: > > (i) Even though this thread started in a W3C discussion, there > remain a number of leaders in the W3C community who are > unalterably opposed to URNs and the URN concept. It appears to > me that opposition has become sufficiently much of a religious > issue that, even if we were to define a model for handling media > types as URNs, they would be unlikely to willingly adopt them, > perhaps pushing instead for a media-type-specific URI scheme. I have definitely known people at W3C who don't recommend URNs, but none of the suggested a new URI scheme instead. > (ii) We've been pushed several times by people in IETF circles > to define the limits of URNs (possibly even at what 2141 > permits) and encourage the development of other URI schemes, > even if they are name-like rather than locator-like, for > situations that don't fit. I'm not sure you are suggesting to use URNs for media types or not, but at least assuming the former, a "has anybody ever attempted to do something like this with URNs" would definitely fit on this list. > I think those two comments are consistent with Sean's remarks > but, for me right now, I just hope we can keep this discussion > out of the critical path of this WG. I very much agree here. Regards, Martin. > People who have read so far are reminded that 2141bis-15 was > posted about two weeks ago and we have not seen a single > substantive comment on the list since. Does that imply that we > are ready for WG Last Call on it (or on a slightly revised > version to correct a few minor editorial errors)? > > john From nobody Mon Feb 22 00:33:14 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD14C1A7032 for ; Mon, 22 Feb 2016 00:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006] autolearn=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 BcipQmevvTUF for ; Mon, 22 Feb 2016 00:33:12 -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 483DC1B29E3 for ; Mon, 22 Feb 2016 00:33:11 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aXlvT-0005BI-28; Mon, 22 Feb 2016 03:33:03 -0500 Date: Mon, 22 Feb 2016 03:32:58 -0500 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: <93D0378100451D30DC2BB11B@JcK-HP8200.jck.com> In-Reply-To: <56CA9FE5.8080407@it.aoyama.ac.jp> References: <56A8CFE5.5010200@tzi.org> <56B47D77.6030904@it.aoyama.ac.jp> <56C70B14.60702@seantek.com> <56CA9FE5.8080407@it.aoyama.ac.jp> 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: Cc: urn@ietf.org Subject: Re: [urn] URNs for media types and other protocol constants relevant to interoperability X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 08:33:14 -0000 --On Monday, February 22, 2016 14:43 +0900 "Martin J. = D=C3=BCrst" wrote: >> (i) Even though this thread started in a W3C discussion, = there >> remain a number of leaders in the W3C community who are >> unalterably opposed to URNs and the URN concept. It appears >> to me that opposition has become sufficiently much of a >> religious issue that, even if we were to define a model for >> handling media types as URNs, they would be unlikely to >> willingly adopt them, perhaps pushing instead for a >> media-type-specific URI scheme. >=20 > I have definitely known people at W3C who don't recommend > URNs, but none of the suggested a new URI scheme instead. Sorry, wrote too quickly and was insufficiently clear: The WG has had three sets of loud opponents with regard to the fundamentals of its work, i.e., to updating 2141 and associated documents to add additional syntax and capabilities: (1) THose who are concerned about destabilizing (e.g., reducing the permanence of) 2141-style URNs and who therefore recommend freezing it and creating a new name-type (as distinct from location-type) URI and attaching the new syntax and capabilities to it. A subset of that group has proposed not defining the new scheme as a URI at all, thereby escaping the syntax and semantics of RFC 3986 entirely (along with arguments about = them). (2) Those who believe that there is no such thing as a real set of things called URNs with properties of persistence that anyone can really define operationally and that therefore they are just confusing syntax added to what should be scheme-per-namespace URIs. They believe that all instances of urn:foo:some-NSS should be replaced by foo:something-related-to-NSS, with direct 3986-style queries and fragments. (3) THose who believe that URNs are conceptually wrong and should be replaced by either http[s] URLs or some sort of Semantic Web objects. I include in this group those who think the "resolver" discussion, e.g., what we now see as=20 urn:Example-NID:example-nss?+resolverID = some-string?=3Dfoo=3Dbar should be turned into: http://resolver-ID/some-string?foo=3Dbar A subset of the third group have clear W3C affiliations, to the point that some of them are generally assumed (including by themselves) to be speaking for W3C. A (smaller) subset of the second group are periodically assumed to be speaking for the web community and some of them seem to encourage that perception. I don't think naming names would have any value but am willing to do so offlist if you think I'm making this up. >> (ii) We've been pushed several times by people in IETF = circles >> to define the limits of URNs (possibly even at what 2141 >> permits) and encourage the development of other URI schemes, >> even if they are name-like rather than locator-like, for >> situations that don't fit. =20 > I'm not sure you are suggesting to use URNs for media types or > not, but at least assuming the former, a "has anybody ever > attempted to do something like this with URNs" would > definitely fit on this list. No I wasn't thinking of media types. I was thinking more about some of the discussions I tried to summarize in (1) above. But I agree with your comment as well. It is another topic I hope we can keep out of the critical path, but I believe that, if we were doing a document similar to RFC 1737 today, some of its statements, criteria, and requirements would be quite different with the addition of requirements for what we now call q-components and/or r-components as a small part of that. >> I think those two comments are consistent with Sean's remarks >> but, for me right now, I just hope we can keep this = discussion >> out of the critical path of this WG. >=20 > I very much agree here. Thanks. john From nobody Tue Feb 23 11:48:44 2016 Return-Path: X-Original-To: expand-draft-martin-urn-globus.all@virtual.ietf.org Delivered-To: urn@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B07D51B3622; Sun, 21 Feb 2016 23:07:40 -0800 (PST) X-Original-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Delivered-To: xfilter-draft-martin-urn-globus.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC6B1B3620; Sun, 21 Feb 2016 23:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.006, WEIRD_PORT=0.001] autolearn=ham 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 C1YjzijlbaoF; Sun, 21 Feb 2016 23:07:38 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (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 2749C1B361B; Sun, 21 Feb 2016 23:07:38 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 76C1B43AE1; Mon, 22 Feb 2016 08:07:36 +0100 (CET) To: ops-dir@ietf.org, draft-martin-urn-globus.all@ietf.org From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <56CAB3B2.1030905@restena.lu> Date: Mon, 22 Feb 2016 08:07:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="okePRjdPr0krOkWRk5TU98whuggK5I67h" Archived-At: X-Mailman-Approved-At: Tue, 23 Feb 2016 11:48:42 -0800 Subject: [urn] OPS-DIR review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 07:07:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --okePRjdPr0krOkWRk5TU98whuggK5I67h Content-Type: multipart/mixed; boundary="------------000108000008090302060709" This is a multi-part message in MIME format. --------------000108000008090302060709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is ready. It is a well-elaborated registration for a new URN namespace, and contains few operational issues to consider. All aspects of the registration are well explained, and the registration of a new namespace (rather than using existing ones) is justified (Globus should of course consider using the existing urn:ietf:params:oauth namespace where that one is sufficient; the examples given in the registration make clear that the globus namespace is used for things /not/ covered there). Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------000108000008090302060709 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------000108000008090302060709-- --okePRjdPr0krOkWRk5TU98whuggK5I67h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWyrO4AAoJEMDeajWKOdxmI1sQAKOLxSgVWa5Kg8wX+SWOZj1I AnW92zKMgdm4OXp6WHsR6Dy1V4PUJaVu9RRN3kEeWaxYj30WiQFJ695oQwJGjfiM NqBUT2ppwzZrHrjEdDsO7/o4nbw1B0HEYXpWP7xVVtl05BOKQoZZV/ARFdtMcE8w dY8Nz0EbBnt1xYCIkCa7BXfb3fqVNsBJM1KTlUvNm4ZAI7Gq4ks/0yzt3AEDnZc1 bDZyL8JvGMShXN6dEVcNCXXMclgifMxXQgEvcvQFZpWJH6S5o8PzC6mhZMDoVnMl l28TwLsT7/h1uLPHRF1QJYUEoUERpqSBXbqoqhZNl4H4MOaOatdNn56N59HrBp6H zupZh/yPqbJ9xfjcr/Qm0bl7hWyEa6LbFDCfUphx+7tx2Tdq3hlu0qQP6PxQPppO Td6sYSztlmklV2c5yIOUuBHv9S6cnWl1SG+FTcwNs3u1+qjMpSzP15/a8L4OR/Rb 6eY4cBZFaXQohDOPjdrCWpdD7vOcj9ina7h7DJ4KNwi5XxxmkdTehij1pDhlTcAx pGL4WWiQP2MNKQZahO9+tO0hDSNvC0dFE7tHmG+pMixgjwIgncaAU0b+U7s05Owz OdjsNekr6FbMdjee9efGWIMjtzzABpQsIgV2FW1RufAezS0UkTU+MpSUEDcqQnAd i4DIXLVeVd/Kosl6+4IC =Ntwh -----END PGP SIGNATURE----- --okePRjdPr0krOkWRk5TU98whuggK5I67h-- From nobody Wed Feb 24 07:45:01 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8961B375C for ; Wed, 24 Feb 2016 07:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006] autolearn=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 k21rJkSY7mM0 for ; Wed, 24 Feb 2016 07:44:57 -0800 (PST) Received: from nordpol.dnb.de (nordpol.dnb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0B31B373B for ; Wed, 24 Feb 2016 07:44:57 -0800 (PST) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by nordpol.dnb.de (Postfix) with ESMTP id 3D5908B8F6; Wed, 24 Feb 2016 16:44:56 +0100 (CET) X-AuditID: 0a453fe7-41f6270000002a85-0b-56cdcff761e6 Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by (DNB Symantec Messaging Gateway) with SMTP id FC.DA.10885.7FFCDC65; Wed, 24 Feb 2016 16:44:56 +0100 (CET) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0224.002; Wed, 24 Feb 2016 16:44:55 +0100 From: "Svensson, Lars" To: John C Klensin , "urn@ietf.org" Thread-Topic: [urn] ReL draft-ietf-urnbis-rfc2141bis-urn-15 Thread-Index: AQHRZm3XZ+ia0Rkt8k6qnxf1jXS5Zp87Y9Tg Date: Wed, 24 Feb 2016 15:44:55 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D262D48@dnbf-ex1.AD.DDB.DE> References: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> In-Reply-To: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.69.12.186] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLsWRmVeSWpSXmKPExsXC5Wr/VffH+bNhBtfvsVq0XvrDZjG1+QOT A5PHkiU/mTwur3zNHMAUxWWTkpqTWZZapG+XwJWx5NcP5oK3UhW3pr1jbGBcJ9rFyMkhIWAi cXH1G+YuRi4OIYGtjBIz/x5hgnC2M0qsvwDisHOwCWhJvM8AqRcRcJWY1LOSDcQWFrCSeD7n A3sXIwdQ3Fri2OVIiBIjiWeHTjGB2CwCqhIf/k5mBLF5BbwlFq69zgxiCwlYSsxZ+ZcJpJUT aMyX96EgYUYBWYkNG86DlTALiEtsevadFeJKAYkleyDiEgKiEi8f/4OKK0hMOnWZHaLeQOL9 uflQvdoSyxa+ZoZYKyhxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYuQrzk031EtM0UtJSdJL Sd3ECAn95zsY+y65HGIU4GBU4uHdsv5MmBBrYllxZe4hRn8OJiVR3v3nzoYJ8SXlp1RmJBZn xBeV5qQWK4nwNp0GCvPChZNKc7KV5HgVMoCi4nDR4tLigszkzPzS4vjSopxDjBIczECtpQdA WlMSK6tSi/IhBh5ilOZgURLnnbi7MURIID2xJDU7NbUgtQgmG8HBoSTByw1MJ0KCRanpqRVp mTklMGmgvhaQIwWQZcAOUuT9BHKQFLIEupuYODgPMfpw8AAdZgAyn7e4IDG3ODMdarYwr94Z oCgPTBRsrixvLshcMZggqpmnGIOlxHlvgZ0EUpFRmgd3q5QY79EjwDDmR5IAGSmlwHufCygu iSSOauorRk9gFAnzyoMcyQPMQwg3CvHOAlnGDRUEO1GGtwvkRFGoGLpZPsC4FeG9ve0UyMMl iSXIHtbnPgPyMFQU6mEdkKAYTBDVOKkGxtm5Qr+1nhyfqxiRe672w+0fxvf3ZDs25dasXnMv Xqvn55wfgTtfHDeYEPTy6tEvbUnf199R4Prjac25p/el2+ftu/8e4N+/Zjd7QgKDsvWp2nNm 91s75fhc5W/vVJwQwJMX7lXMPW9a+Uwn4SuFr96GNYTzTJtUJveyZdsh06lv5DV+qz/9raTE UpyRaKjFXFScCAB5DUKcZgQAAA== Archived-At: Subject: Re: [urn] ReL draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:44:59 -0000 John, all, On Saturday, February 13, 2016 3:50 PM, urn wrote: [...] > I hope, although I'm afraid to assume, that the silence means > that -15 reflects agreement on the basic technical, protocol, > and procedural issues and how to handle them and an acceptable > and reasonably balanced way of dealing with the issues we > clearly are not ready to handle and reach consensus about. > There is a lot of new text (compared to -13 and -14) in the > document but I believe we've discussed enough of the issues > on-list that none of it should be a surprise. This is a brief comment on -15, not really a thorough review... For answers= to John's specific questions, see below. =A75 URN Namespaces, paragraph 3 ("With regard to ..."). The example of a publication having both an ISBN and an ISSN is not quite c= orrect, since the ISSN is not identifying a single publication but a series= of publications. It might be better to use ISBN and NBN instead. Suggested= text: [[ For example, if a publisher assigns an ISBN to an electronic publication an= d that publication is later ingested into a digital long term archive opera= ted by a national library, the library might assign the publication a NBN, = resulting in two URNs referring to the same book. ]] > Whether the text correctly and optimally reflects the WG's views > is a separate question, so I'd really appreciate comments on > that question, preferably soon enough that we don't lose > momentum again. In particular, I would hope that people would > pay careful attention to, and comment on: >=20 > (1) Do the registration template and supporting information > still reflect what we want there? They have not been carefully > reviewed, much less revised, in the last few drafts, and we need > to think about other changes and whether they should be > reflected in the NID/ Namespace registration specifications. I find the template accurate. > (2) We've seen two proposals for NID registrations in the last > week or two. Would the registration template and new procedure > adequately reflect whatever we've learned from them? Would we > be happy having them go through under the new procedure? I think so. > (3) Is the ABNF consistent with everyone's expectations, > especially noting the the change in introducers for r-component > and q-component eliminates several problems (including the > controversy about ordering) but may introduce a few others. In > particular, is everyone ok with q-component and r-component > appearing in either order (as the text and ABNF now say) or is > there some reason to require a specific order)? Similarly, the > text contains some words about the implications of "?" followed > by neither (new) delimiter but the ABNF doesn't call the issue > out. Is that ok with everyone? If it is not, please propose > ABNF changes and/or text. Looking at it from the outside, I'd say yes. I should add, however, that I = haven't tried to actually write software to handle those so I cannot say if= the syntax allows ambiguities. > (4) Is the spec now clear enough? Are there places that need > work? If so, please at least identify the places and the issues > and, if possible, propose text. I think the spec is clear enough. But as said, I haven't tried to write sof= tware to handle 2141bis URNs... Thanks for all the hard work! Best, Lars From nobody Wed Feb 24 12:08:05 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2393A1ACEBB for ; Wed, 24 Feb 2016 12:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Mw3tqv532RNl for ; Wed, 24 Feb 2016 12:08:00 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 E3F5D1A8BB7 for ; Wed, 24 Feb 2016 12:07:59 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u1OK7vwJ007040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 24 Feb 2016 15:07:57 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDAEABF3-F5D7-4D40-A260-08B8EDFD6F17" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Catherine Meadows In-Reply-To: <95A17F65C12FBC66101671D6@JcK-HP8200.jck.com> Date: Wed, 24 Feb 2016 15:07:57 -0500 Message-Id: <9FADC843-1BD1-461B-8739-1656B65C6F6A@nrl.navy.mil> References: <76C59DBD-5B5E-4976-B574-97ED20287E12@nrl.navy.mil> <95A17F65C12FBC66101671D6@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.3112) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Cc: urn@ietf.org, Catherine Meadows , Barry Leiba , Alexey Melnikov Subject: Re: [urn] secdir review of draft-martin-urn-globus-02 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:08:04 -0000 --Apple-Mail=_CDAEABF3-F5D7-4D40-A260-08B8EDFD6F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi John: I=E2=80=99ve looked through 2141bis, and and several of the documents it = cites, in particular, RFC 6943, =E2=80=9CIssues in Identifier = Comparisons for Security Purposes=E2=80=9D and RFC 6793, "Privacy = Considerations for Internet Protocols=E2=80=9D. The following is a list of the information I think should be in the Security Considerations Section of = that document, based on my understanding of 2141bis and URN=E2=80=99s in = general. That understanding is imperfect, so I welcome your feedback. Please let me know if any of the = assumptions I made are incorrect, or if I am missing anything. Cathy As I understand it, URNs are similar to URLs except: 1) they don=E2=80=99t= give necessarily give any information on how to access a resource 2) = they are assigned in separate =E2=80=9Cnamespaces=E2=80=9D, where a = namespace is identified by a unique prefix, and 3) they are persistent, = even when the object being identified is no longer present. Also, there = may be tighter controls on the issuing of URN=E2=80=99s than URL=E2=80=99s= . For example, URNs in a given namespace could be generated and assigned by a central authority, or a central = authority and some trusted partners. Since URNs are similar to URLs, they present many of the same security = challenges. On the other hand, some of the features unique to URNs can = provide mitigation against security problems, and in some cases prevent them altogether. So I think it = would be very useful for the Security Considerations Section to list the = major security issues and mitigations. The security issues may be not be unique to URNs, but the mitigations may be. As far as I can tell, there are two main security issues that can arise = when using URNs. One is if URNs are used for security decisions. For = example, an entity contacting a resource identified by an URN might be willing to give certain information to it based on the URN = used to identify it. In this case, URNs should be authenticated, but = even this will not be sufficient unless other issues are taken into account, in particular: 1. False positives or negatives when determining whether URNs are equal = to could lead, e.g. to an elevation of privileges attack in which in = which an attacker uses a low-privilege URN which is confused with a high = privilege URN. Such a vulnerability is particularly probmatic when the = attacker himself can choose the URN, and intentionally chooses an URN = that can be confused with a high-privileged URN. An example in which an attacker takes advantage of inconsistent canonicalizers at = two different organizations is given in Section 2.2 of RFC6943. = rfc2141bis, in section 6.4, talks about the security and privacy = template and gives the consequence of producing false negatives and false positives = as one of the possible issues. But nothing is said about this in the = Security Considerations Section about this issue, beyond a reference to 6.4. However, I believe that it would be appropriate to have more = discussion in the Security Considerations section about the measures = that could be taken to mitigate against this, e.g. having URNs within a = namespace generated and assigned by a central authority, so that an = attacker could not deliberately choose an ambiguous URN, equivalence = checking algorithms that minimize false positives and negatives, etc. = BTW, I notice that 2141bis recommends the minimization of false negatives, but not false = positives (as far as I can tell, this is not discussed in a security = context, however). Can you tell me what the reason for this is? 2. There is a similar attack, also mentioned in RFC=20 6943, in which an attacker chooses a resource identifier that is not = ambiguous to an equivalence checker but is to a human looking at it in a = human-readable format. This can (and has ) for example been used to = gather password information from users. It is mentioned in rfc2141bis, = in Section 3.2, when it is noted that symbols in different fonts, = although they may be clearly distinguishable to a machine equivalence = checker, may be easily confused when displayed in human-readable form. = Again, this is something I think should be mentioned in the Security = Considerations section, again with suggestions for possible mitigations: = central generation of and assignment of URNs within a namespace, rules = preventing URNs that are easily confused when in human readable form = (e.g. rules governing the use and placement of non-ASCII characters), = etc. 3. Another problem mentioned in RFC 6943 is security problems arising = from expired identifiers that are reassigned. If there are portions of = the network that have not gotten the news yet, this could result in elevation of = privileges of the current resource identified by the URN. Since URNs = are intended to be persistent, that is not a problem for them. It might be worth = mentioning that this should not be an issue for URNs because URNs = can=E2=80=99t be reassigned. The second issue is privacy issues involving URNs. For example, if an = URN can be used to assist in contacting a resource, this may raise = privacy issues. In some cases, simply being careful about distributing URNs may not = itself be enough, and issues such as potential vulnerability to, e.g., = directory harvesting of URNs should also be addressed. I don=E2=80=99t have any specific. RFC 6943 also raises the issue of denial of service that could result = from inconsistent canonicalization of URI=E2=80=99s. It=E2=80=99s not = clear to me how an attacker would take effective advantage of this = however (or maybe it=E2=80=99s just that there are so many more effective ways = of achieving denial of service. I also think the Security Considerations Section should reference = RFC=E2=80=99s 6943 and 6793, but should not stop there; it should also = discuss how they apply to URN=E2=80=99s and what the mitigations are. and mitigations described above. WRT RFC 1737: that Security Considerations Section reads Applications that require translation from names to locations, and the resources themselves may require the resources to be authenticated. It seems generally that the information about the authentication of either the name or the resource to which it refers should be carried by separate information passed along with the URN rather than in the URN itself. That recommendation is still relevant, but stops short of addressing the = other issues described above. Also, as noted above, RFC=E2=80=99s 6943 and = 6793, which were not available when RFC 1737 was written, give useful = information on this topic and should be cited. =20 Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = > On Feb 18, 2016, at 2:01 PM, John C Klensin wrote: >=20 >=20 >=20 > --On Thursday, February 18, 2016 11:33 -0500 Catherine Meadows > wrote: >=20 >> Sure, John, I'll be happy to take a look at 2141bis and get >> back to you all. If I get an opinion to you by sometime next >> week, is that soon enough? >=20 > Yes, sometime next week would be great. I wish the volume of > comments on the WG list were such that I could make an argument > for tomorrow (or yesterday), but it hasn't been. >=20 > thanks, > john >=20 >=20 >=20 --Apple-Mail=_CDAEABF3-F5D7-4D40-A260-08B8EDFD6F17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi John:

I=E2=80=99ve looked = through 2141bis, and and several of the documents it cites, in = particular, RFC 6943, =E2=80=9CIssues in Identifier Comparisons for = Security Purposes=E2=80=9D and RFC 6793, "Privacy Considerations for = Internet Protocols=E2=80=9D.
The following is a list of = the
information I think should be in the Security = Considerations Section of that document, based on my understanding of = 2141bis and URN=E2=80=99s in general.  That understanding is = imperfect,
so I welcome your feedback.  Please = let me know if any of the assumptions I made are incorrect, or if I am = missing anything.

Cathy


As I understand = it, URNs are similar to URLs except: 1) they don=E2=80=99t give = necessarily give any information on how to access a resource 2) they are = assigned in separate =E2=80=9Cnamespaces=E2=80=9D, where a namespace is = identified by a unique prefix, and 3) they are persistent, even when the = object being identified is no longer present. Also, there may be tighter = controls on the issuing of URN=E2=80=99s than URL=E2=80=99s.  For = example, URNs in a given namespace
could be = generated and assigned by a central authority, or a central authority = and some trusted partners.

Since URNs are similar to URLs, they present many of the same = security challenges.  On the other hand, some of the features = unique to URNs can provide mitigation against security
problems, and in some cases prevent them altogether.  So = I think it would be very useful for the Security Considerations Section = to list the major security issues and mitigations.  The = security
issues may be not be unique to URNs, but = the mitigations may be.

As far as I can tell, there are two main security issues that = can arise when using URNs.  One is if URNs are used for security = decisions.  For example, an entity contacting a resource identified = by an
URN might be willing to give certain = information to it based on the URN used to identify it.  In this = case, URNs should be authenticated, but even this will not be sufficient = unless other issues are taken into
account, in = particular:

1. =  False positives or negatives when determining whether URNs are = equal to could lead, e.g. to an elevation of privileges attack in which = in which an attacker uses a low-privilege URN which is confused with a = high privilege URN. Such a vulnerability is particularly probmatic = when the attacker himself can choose the URN, and intentionally chooses = an URN that can be confused with a high-privileged URN. An = example
in which an attacker takes advantage of = inconsistent canonicalizers at two different organizations is given in = Section 2.2 of RFC6943.   rfc2141bis, in section 6.4, talks about = the security and privacy template and
gives the = consequence of producing false negatives and false positives as one of = the possible issues.   But nothing  is said about this in the = Security Considerations Section about this issue, beyond a reference = to
6.4.   However, I believe that it would = be appropriate to have more discussion in the Security = Considerations section about the measures that  could be taken to = mitigate against this, e.g. having URNs within a namespace generated and = assigned by a central authority, so that an attacker could not = deliberately choose an ambiguous URN, equivalence checking algorithms = that minimize false positives and negatives, etc.  BTW, I notice = that
2141bis recommends the minimization of false = negatives, but not false positives (as far as I can tell, this is not = discussed in a security context, however).  Can you tell me what = the reason for this is?

2.  There is a similar attack, also mentioned in = RFC 
6943,  in which an attacker chooses = a resource identifier that is not ambiguous to an equivalence checker = but is to a human looking at it in a human-readable format.  This = can (and has ) for example been used to gather password information = from users.   It is mentioned in rfc2141bis, in Section 3.2, when = it is noted that symbols in different fonts, although they may be = clearly distinguishable to a machine equivalence checker, may be easily = confused when displayed in human-readable form. Again, this is something = I think should be mentioned in the Security Considerations section, = again with suggestions for possible mitigations:  central = generation of and assignment of URNs within a namespace, rules = preventing URNs that are easily confused when in human readable form = (e.g. rules governing the use and placement of non-ASCII = characters), etc.

3. Another problem  mentioned in RFC 6943 is security = problems arising from expired identifiers that are reassigned.  If = there are portions of the network
that have not gotten the = news yet, this could result in elevation of privileges of the current = resource identified by the URN.  Since URNs are intended to be
persistent, that is not a problem for them.   It might = be worth mentioning that this should not be an issue for URNs because = URNs can=E2=80=99t be reassigned.



The second issue is privacy issues = involving URNs.  For example, if an URN can be used to assist in = contacting a resource, this may raise privacy issues.
In some cases, simply being careful about distributing URNs = may not itself be enough, and issues such as potential vulnerability to, = e.g., directory harvesting of URNs should also be addressed.
I don=E2=80=99t have any specific.

RFC 6943 also raises the issue of = denial of service that could result from inconsistent canonicalization = of URI=E2=80=99s.  It=E2=80=99s not clear to me how an attacker = would take effective advantage of this however
(or = maybe it=E2=80=99s just that there are so many more effective ways of = achieving denial of service.

I also think the Security = Considerations Section should reference RFC=E2=80=99s 6943 and 6793, but = should not stop there; it should also discuss how they apply to URN=E2=80=99= s and what the mitigations are.
and mitigations = described above.





WRT RFC 1737: that Security Considerations Section = reads

Applications that require translation from names to = locations, and
   the resources = themselves may require the resources to be
  =  authenticated. It seems generally that the information about = the
   authentication of either the name = or the resource to which it refers
  =  should be carried by separate information passed along with the = URN
   rather than in the URN = itself.

That recommendation is still relevant, but stops short of = addressing the other
issues described above. =  Also, as noted above, RFC=E2=80=99s 6943 and 6793, which were not = available when RFC 1737 was written, give useful information
on this topic and should be cited.  






Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

On Feb 18, 2016, at 2:01 PM, John C Klensin <john-ietf@jck.com> = wrote:



--On Thursday, February 18, = 2016 11:33 -0500 Catherine Meadows
<catherine.meadows@nrl.navy.mil> wrote:
Sure, John, I'll be = happy to take a look at 2141bis and get
back to you all. =  If I get an opinion to you by sometime next
week, is = that soon enough?

Yes, = sometime next week would be great.  I wish the volume of
comments on the WG list were such that I could make an = argument
for tomorrow (or yesterday), but it hasn't = been.

thanks,
=   john




= --Apple-Mail=_CDAEABF3-F5D7-4D40-A260-08B8EDFD6F17-- From nobody Wed Feb 24 12:56:45 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3045F1B2E0A for ; Wed, 24 Feb 2016 12:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 LUCWIBVeNnnS for ; Wed, 24 Feb 2016 12:56: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 D709D1B2E01 for ; Wed, 24 Feb 2016 12:56:42 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aYgUD-000DQw-9f; Wed, 24 Feb 2016 15:56:41 -0500 Date: Wed, 24 Feb 2016 15:56:36 -0500 From: John C Klensin To: "Svensson, Lars" , urn@ietf.org Message-ID: <02E9314E1C6B11009417B867@JcK-HP8200.jck.com> In-Reply-To: <24637769D123E644A105A0AF0E1F92EF010D262D48@dnbf-ex1.AD.DDB.DE> References: <60695B0A70C0B1770A5794F1@JcK-HP8200.jck.com> <24637769D123E644A105A0AF0E1F92EF010D262D48@dnbf-ex1.AD.DDB.DE> 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] ReL draft-ietf-urnbis-rfc2141bis-urn-15 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 20:56:44 -0000 --On Wednesday, February 24, 2016 15:44 +0000 "Svensson, Lars" wrote: >... > This is a brief comment on -15, not really a thorough > review... For answers to John's specific questions, see below. >=20 > =C2=A75 URN Namespaces, paragraph 3 ("With regard to ..."). > The example of a publication having both an ISBN and an ISSN > is not quite correct, since the ISSN is not identifying a > single publication but a series of publications. It might be > better to use ISBN and NBN instead. Suggested text: >=20 > [[ > For example, if a publisher assigns an ISBN to an electronic > publication and that publication is later ingested into a > digital long term archive operated by a national library, the > library might assign the publication a NBN, resulting in two > URNs referring to the same book. ]] I think, given "monograph series" and "referring to", the draft is strictly correct, but your suggestion is probably an improvement and definitely less confusing. Changed in working copy. Thanks for checking on the other questions and for the read-through in general. john