Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

John C Klensin <john-ietf@jck.com> Fri, 25 April 2014 17:51 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 24C131A02F2 for <urn@ietfa.amsl.com>; Fri, 25 Apr 2014 10:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.872
X-Spam-Level:
X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 jx2Fz44O1jcM for <urn@ietfa.amsl.com>; Fri, 25 Apr 2014 10:51:21 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 676041A026A for <urn@ietf.org>; Fri, 25 Apr 2014 10:51:21 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1WdkHD-0001H5-4O; Fri, 25 Apr 2014 13:51:07 -0400
Date: Fri, 25 Apr 2014 13:51:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Edward Summers <ehs@pobox.com>, Mark Nottingham <mnot@mnot.net>
Message-ID: <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com>
In-Reply-To: <FAB32F8D-4BE4-4E49-AE8E-022D322C3BCC@pobox.com>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <FAB32F8D-4BE4-4E49-AE8E-022D322C3BCC@pobox.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.115
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/zVz8DaL-p7cL_TC4pAmnqYZ1OFM
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, urn@ietf.org, Graham Klyne <GK@ninebynine.org>
Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
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: Fri, 25 Apr 2014 17:51:25 -0000

(apps-discuss removed)

--On Friday, April 25, 2014 04:45 -0400 Edward Summers
<ehs@pobox.com> wrote:

>> While people don't want to consider it in-scope for this
>> discussion, I also think that doing so will make the
>> situation with WHATWG and W3C more manageable.
> 
> I agree that, as distasteful as it might seem, it's quite
> important to discuss the organizational (and personal)
> politics involved, to the best of our ability, in a respectful
> and constructive way. Pushing them off the table is just a way
> of making them an implicit part of any work that we do, which
> can result in difficulty in interpreting decisions later
> on...which can be expressed as angels dancing on pins. If
> possible I would like to hear how the proposed changes could
> help make the WHATWG/W3C situation more manageable.

Let me try to respond to this issue only, at least for the
moment.  I will do so in as balanced a way as I can, but you
should understand, as you probably do already, that passions run
high in this area.  

There has always [1] been a position that locators, in the form
of URLs, are all that is needed and that, if more persistence is
needed, that is an operational problem, not a conceptual one.
For nearly as long, there have been positions that having a
consistent and unified parsing model for all identifiers, or all
identifiers used with the web, is a really good idea.  Perhaps
as a corollary to the latter, perhaps independently, there have
been efforts to create a Grand Unified Identifier syntax,
sometimes in the very restricted "scheme:<stuff>" form that
Phillip proposed, sometimes with a lot of reserved characters
and associated semantics, and sometimes in between.  Some of
those efforts have involved theorizing about how to solve (or
that assume solutions to) problems that have been with us a very
long time, even if not "always" [2], such as a unified model for
naming.  The tensions among those points of view have led to
different communities talking past each other, sometimes
thinking they agree and later discovering they don't and
sometimes having discussions ended by exhaustion of one set of
parties, leaving the others to claim consensus for publishing a
document that more or less reflects their views.

There is a separate, almost orthogonal, debate among views of
what all of this is about.  At one extreme, there is a community
that says "The Internet is moving forward, growing, and reaching
ever-increasing populations.  The web is just part of it,
although, at present, an important part.  If we discover that we
have gotten things wrong, or even severely sub-optimal, then it
is appropriate to go back and get them right for the benefit of
the next two billion, or, including extraplanetary use, the next
hundred billion, uses even if that involves some short-term
pain."  At the other extreme, there is a community that says
"The only part of the Internet that is really important to
anyone is the web; everything else is either obsolescent or
low-level transport technology that could be swapped out.
Stability of the web is important and therefore the only
meaningful standards are set by what people are doing (or have
done) and that has worked.  Speculation or theorizing about
'right' or 'best' ways of doing things is largely meaningless if
it conflicts, or might conflict, with current practice".  

That debate and the tensions it causes are not limited to URIs.
We see much the same patterns when, e.g., we start talking about
internationalization issues, some security issues, and advanced
user interfaces of various sorts.

There are lots of positions between those two; on most issues,
no one takes the most extreme positions.  

One can look at the present situation in at least three ways:

(i) There is a community, perhaps the whole URN-ish community
and perhaps only a subset with many years [3] of experience in
cataloging, object, identification and the issues involved in
talking about conceptual objects, including objects that exist
in multiple copies and whether an object can exist in multiple
media, different languages, etc., that have found the syntax and
semantic constraints unreasonably restrictive given their
perceived needs.   From that perspective, that is the problem;
the debate ought to be able solutions.  Whatever else is going
on with the community, it thinks it is right and cites centuries
of experience to back up that claim.

(ii) There is a community, perhaps closely related to the
community that created RFC 3986 and perhaps not, that is
determined to defend the concepts that underlay that model,
syntax, semantics, and all.  

(iii) There is another community that is very dedicated to
making the web work well and that has adopted some of the "it is
all about the web" view caricatured above.  They are sincere in
their beliefs.  And, while they may agree with the community in
(i) about almost nothing else, they don't find RFC 3986 (and the
boundary between it and 3987) appropriate to their needs.

>From that set of perspectives, the problem that Mark and I have
described in WHATWG/W3C terms (not entirely fair) could have a
partial solution in common -- moving away from 3986/3987 as a an
overarching and constraining identifier definition.  If that
happened, it could be a convenient side-effect.  It is not, at
least for me, a major goal.

best,
   john


[1] Measured in web time, i.e., a decade or two.

[2] Consider archeological time, not web time.

[3] Library/museum time, think many centuries.