Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg
John C Klensin <john-ietf@jck.com> Sun, 29 March 2015 20:12 UTC
Return-Path: <john-ietf@jck.com>
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 C5C7F1A88BD for <urn@ietfa.amsl.com>; Sun, 29 Mar 2015 13:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 BT7DEWmSDC7o for <urn@ietfa.amsl.com>; Sun, 29 Mar 2015 13:12:48 -0700 (PDT)
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 844661A889D for <urn@ietf.org>; Sun, 29 Mar 2015 13:12:48 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YcJZf-000FyN-DW for urn@ietf.org; Sun, 29 Mar 2015 16:12:47 -0400
Date: Sun, 29 Mar 2015 16:12:42 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <FC54496AC65800171722439E@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.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/tJ-k55uX9BtgDDXC9UVOyK9-ebw>
Subject: Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs draft-ietf-appsawg-uri-scheme-reg
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2015 20:12:50 -0000
Hi. I've avoiding cross-posting, but this just-sent note seems relevant to this WG. People who want to discuss it would probably take it up on apps-discuss and/or with the IESG. Observation: The more steps we need to take along this path, the more I think it may be useful for this WG to reconsider the decision that turned "URNs are not URIs" into "syntax only" and possibly return to the former. Whatever the advantages or disadvantages of that approach, it would clearly take this WG out of arguments (or confine them to discussions about the needs of URNs in isolation) about relative URIs, applicability of various parts of 3986, and URI registration and other documents that are argued to have retroactive effect. john ---------- Forwarded Message ---------- Date: Sunday, March 29, 2015 16:05 -0400 From: John C Klensin <john-ietf@jck.com> To: Alexey Melnikov <alexey.melnikov@isode.com>, Barry Leiba <barryleiba@computer.org> Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt (reposting -- the IETF mail system apparently didn't like the "implicit" copy to apps-discuss) --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov <alexey.melnikov@isode.com> wrote: > On 27/03/2015 19:29, Barry Leiba wrote: >>> I will send email responses to the feedback received with >>> what we did. I may not get those out today though. But I >>> think the doc should be ready for the IESG telechat. >> Thanks. I've issued the ballot; I'll wait to change the >> state until I hear that your co-authors & shepherd are OK >> with it. > This is almost perfect :-). > > A couple of comments: > ... > Here is a real world example of a problem with this text. SIDR > WG decided to use rsync protocol, they needed to use rsync > URIs. rsync URIs are currently provisional, defined in an > Informational RFC. So this text is basically saying that > under the new rule the registration have to be upgraded to > Permanent, allowing the expert reviewer (no disrespect to > Graham or his future replacement) to be a person that blocks > consensus of a WG to use a particular technology. I find this > to be problematic. > > Do people agree that this is problematic? Yes. At the risk of tossing a spanner toward the works, one more issue that seems to me very significant: Larry Masinter has raised several issues in the URNBIS WG in which he claims that draft-ietf-appsawg-uri-scheme-reg constrains what that WG is proposing to do with URNs [1]. I also believe that some of his comments mix up registration of schemes (e.g., "urn:") with registrations of URN namespaces and NIDs I think those issues need to be considered in that WG. However, procedurally, it seems to me that either: (1) Existing registrations are existing registrations and any updates to them are grandfathered, i.e., whatever draft-ietf-appsawg-uri-scheme-reg says is not applicable to the original or updated registration of any URI scheme registered or deployed before it is approved and published. That obviously includes the revised URN registration contemplated by draft-ietf-urnbis-rfc2141bis-urn. (2) We have a mess on our hands in which not only do the mandates of different WGs overlap but in which an area WG that is not noted for very intense reviews can constrain and override the work of more topic-focused (and, therefore, presumably more expert on their own topics) WGs and other efforts. This is particularly problematic in the case of URIs, where parallel (and not entirely consistent) work is going on to further develop specific URI schemes (URNs being only one such example) and groups outside the IETF (including WHATWG and W3C groups) with coordination processes that are still being negotiated and in groups that are heavily dependent on URIs and URI handling (certainly including HTTPbis). If it is applicable to existing registrations and ongoing work in other WGs, this spec is even more problematic because it is heavily dependent on details of RFC 3986, a specification whose exact meaning, implications, and consequences continue to be debated and which is a candidate for preemption or replacement by those other bodies. I suggest that any IESG action on draft-ietf-appsawg-uri-scheme-reg be deferred until which of the above principles applies can be clarified (and clarified in the document) and, if the second option is chosen, that formal reviews and impact assessments be sought from all active WGs that are involved with or use URIs as well as from W3C. Sorry to be raising this so late in the process, but it never occurred to me that anyone would claim that draft-ietf-appsawg-uri-scheme-reg constrained other IETF WGs, standards-track updates to existing registrations that were made as the result of standards actions, etc. Since that claim has now been made, and made by one of the authors of the new draft who presumably understands the intent, a "wait a minute" response seems necessary. john [1] http://www.ietf.org/mail-archive/web/urn/current/msg02873.html ---------- End Forwarded Message ----------
- Re: [urn] draft-ietf-urnbis-rfc2141bis-urn vs dra… John C Klensin