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 ----------