Re: [Uri-review] [art] Internet-Draft: Using URIs With Multiple Transport Stacks

Carsten Bormann <cabo@tzi.org> Fri, 14 July 2017 12:44 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B13131678; Fri, 14 Jul 2017 05:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTctepWkXtqx; Fri, 14 Jul 2017 05:44:56 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 29A36128DE5; Fri, 14 Jul 2017 05:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6ECiprN005609; Fri, 14 Jul 2017 14:44:51 +0200 (CEST)
Received: from [10.10.10.206] (unknown [62.214.5.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x8C7l3XXnzDKlr; Fri, 14 Jul 2017 14:44:51 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <f5b1spsl1mr.fsf@troutbeck.inf.ed.ac.uk>
Date: Fri, 14 Jul 2017 14:44:49 +0200
Cc: Dave Thaler <dthaler@microsoft.com>, "art@ietf.org" <art@ietf.org>, "uri-review@ietf.org" <uri-review@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>
X-Mao-Original-Outgoing-Id: 521729089.263934-877c281628a79c5651999f5a11a7df6d
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A71B82F-4A5C-4F09-ADDB-2DD50742D14A@tzi.org>
References: <MWHPR21MB0125E2464E9B3A25E0FB8967A3D50@MWHPR21MB0125.namprd21.prod.outlook.com> <f5b1spsl1mr.fsf@troutbeck.inf.ed.ac.uk>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/BsD5x4-_YfrcOa1zVg5Dm8ZXDqY>
Subject: Re: [Uri-review] [art] Internet-Draft: Using URIs With Multiple Transport Stacks
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jul 2017 12:44:59 -0000

On Jul 7, 2017, at 17:15, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> 
>  https://www.w3.org/2001/tag/doc/SchemeProtocols.html

I think this is an interesting reference, as it confirms what has been my perception of the debate so far:

> Although new protocols have traditionally been associated with new URI schemes, there are also advantages to supporting new protocols using existing schemes. In particular, the URIs of existing resources may be widely known, may have been bookmarked or otherwise recorded, or may have been the subject of semantic web assertions.


It seems to me that the conventional wisdom in this space is shaped by experience with URIs that are intended to be long-term, stable, possibly user-visible. Like https://facebook.com — a *strategic* use of URIs.  The stability of this URI is so important that the additional time and effort to do discovery (here: DNS lookup, possibly Happy Eyeballs) is apparently justified (*).

In CoRE, URIs are quite often the *result* of discovery (e.g., involving a resource directory).  They are meant to be instantly usable.  They are much more likely to contain IP addresses than in the Browser Web, to avoid additional lookups.  They are *tactical* URIs.

I’m not sure we should be applying the wisdom we have for strategic URIs to tactical URIs without checking whether the underlying assumptions still apply.

Maybe using the URI concept for tactical purposes is the wrong approach.  URIs were the one part of the three pillars of the Web we thought we could use unmodified, but that caused some trade-offs.  There are multiple proposals to define a URI-like data structure for the purpose that I called “tactical” above.  Doing that would also enable us to solve the rather limited support for security that URIs have; right now URIs often need to be packaged with security information in a larger structure, so we might want to unpack the URI into that.

But for now, URIs are in wide use, and it would be good if we could use them for tactical purposes without getting stuck with all the baggage of strategic use.

Grüße, Carsten

(*) And yet, it only recently replaced http://facebook.com...