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

Noah Mendelsohn <nrm@arcanedomain.com> Mon, 31 July 2017 04:17 UTC

Return-Path: <nrm@arcanedomain.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6E131DA1; Sun, 30 Jul 2017 21:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=arcanedomain.com
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 HcAYwbginZuo; Sun, 30 Jul 2017 21:17:53 -0700 (PDT)
Received: from homiemail-a9.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D505D131D7F; Sun, 30 Jul 2017 21:17:53 -0700 (PDT)
Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 36B4A5BE06D; Sun, 30 Jul 2017 21:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=arcanedomain.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= arcanedomain.com; bh=QodkO/7zh0jVZN3+4PRJtfsJVT0=; b=kfahYwjBwW0 QoW8ou19yOvPz6Lq0YDtgY9Icz0ovYC9Zp6MEj8oze2BNOdp3OFdgH2vAEhEg0ks YwxHcRcNC2WqARizOVk80aLJtx1ZcrqzhPAWJAj51aEKmlPBXJysjqicQj7fm9tj 2YLsjcqnXX97DTUU8Uoa2abH1yJyUbPM=
Received: from [192.168.1.101] (216-15-112-214.s4564.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com [216.15.112.214]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: webmaster@arcanedomain.com) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 0C7F65BE06B; Sun, 30 Jul 2017 21:17:51 -0700 (PDT)
To: Mark Nottingham <mnot@mnot.net>, "Henry S. Thompson" <ht@inf.ed.ac.uk>
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>, Daniel Appelquist <dan@torgo.com>, Dan Connolly <dckc@madmode.com>
References: <MWHPR21MB0125E2464E9B3A25E0FB8967A3D50@MWHPR21MB0125.namprd21.prod.outlook.com> <f5b1spsl1mr.fsf@troutbeck.inf.ed.ac.uk> <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net>
From: Noah Mendelsohn <nrm@arcanedomain.com>
Message-ID: <ea7d1dfd-08de-fed6-50c1-b5ccece8037c@arcanedomain.com>
Date: Mon, 31 Jul 2017 00:17:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <2BA6A41C-7933-4405-997D-BE2D0DA69CF5@mnot.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/0gyEWWgi24_OTrxJ22rMnEur700>
Subject: Re: [dispatch] [Uri-review] Internet-Draft: Using URIs With Multiple Transport Stacks
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jul 2017 04:17:55 -0000


On 7/10/2017 5:30 AM, Mark Nottingham wrote:
> Hi Henry,
> 
> Thanks for that. Looping in Noah and Dan (sorry for including you on a list reply!).
> 
> Why was the document left in draft state? Does the current TAG have any interest in progressing a finding like this one?
> 
> Cheers,
> 

A little history on the drafts at:

https://www.w3.org/2001/tag/doc/SchemeProtocols.html

There were two of these drafts, the first one dated 16 June 2005 and the 
second one 21 November 2005. As a newly appointed member of the TAG at the 
time I found the relationship between URIs to be interesting, somewhat 
confusing, and as far as I could tell not completely documented. I did not 
at the time consider myself expert in the nuances, so I decided to write a 
draft (June version) that set out how I assumed things worked. My 
assumption was that the relationship was in fact clear. My hope was to set 
down the rules clearly, and in the process to learn them myself.

Discussion at the subsequent TAG meeting made clear that several members 
had serious concerns with some of what was said, so I wrote the November 
draft to try to get closer to "the truth" and to capture the advice I'd 
received. Discussion of the November draft also resulted in strong concerns 
being expressed, some of which seemed to contradict what I had been advised 
in June. On a break at the meeting I expressed my newcomer's confusion to 
someone (probably Dan Connolly) who said: "well, you know that TAG members 
XXXX, YYYY and ZZZZ famously disagree about this subject?" No, I hadn't 
known. I thought all Web experts must have agreed on something so 
fundamental. One aspect of the disagreement was whether schemes and 
protocols should always be 1-to-1 (modulo incremental versioning of the 
protocol), but there were other disagreements as well.

My perception (not necessarily correct) was that Tim BL preferred that 
there be (nearly) no new schemes introduced, with use of http/https schemes 
encouraged wherever possible. The reason, I believe, was so that resourcews 
could have stable names that wouldn't change even if the protocols used for 
deployment evolved over time. New protocols would be introduced either as 
HTTP X.Y, or activated by retrieval via traditional HTTP of a document that 
would as a consequence of its Content-type and contents lead to further 
interactions using some new protocol. So, video resources would be named 
something like http://example.com/myvideo. If some non-HTTP peer-to-peer 
protocol were to be used, there would be an initial traditional HTTP 
interaction; the video server would return a document of a Content-type 
that could convey the instruction to "start using P2P to get the video".

In any case, the creation of and confusing debate about the draft TAG 
finding convinced me that (1) what I had assumed to be a straightforward 
aspect of the Web that merely needed better documention was in fact subtle 
and a source of disagreement even among the best experts and (2) that I as 
a new TAG member who had not been part of the prior debates was not the 
right person to drive the discussion to consensus.

I therefore abandoned work on the drafts and as I recall the TAG did not 
revisit the topic in its general form during my time in the group. Maybe or 
maybe not there is useful discussion in either of the drafts, but there was 
no TAG consensus on either. Furthermore it's not clear that there was more 
agreement with the 2nd draft than with the first.

I hope this is helpful.

Noah