p1: HTTP and TCP name delegation

Mark Nottingham <mnot@mnot.net> Sat, 20 April 2013 04:41 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6375821F8EBF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2013 21:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.491
X-Spam-Level:
X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDGtqjzChc43 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 19 Apr 2013 21:41:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6C21F8EC7 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 19 Apr 2013 21:41:10 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UTP5u-00055g-97 for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Apr 2013 04:08:10 +0000
Resent-Date: Sat, 20 Apr 2013 04:08:10 +0000
Resent-Message-Id: <E1UTP5u-00055g-97@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UTP5i-0004zH-Bm for ietf-http-wg@listhub.w3.org; Sat, 20 Apr 2013 04:07:58 +0000
Received: from mxout-08.mxes.net ([216.86.168.183]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UTP5h-00012T-NC for ietf-http-wg@w3.org; Sat, 20 Apr 2013 04:07:58 +0000
Received: from mnot-mini.mnot.net (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D6E3950A85 for <ietf-http-wg@w3.org>; Sat, 20 Apr 2013 00:07:29 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B626010-D681-4109-BDA5-807BCAE72012@mnot.net>
Date: Sat, 20 Apr 2013 14:07:29 +1000
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.183; envelope-from=mnot@mnot.net; helo=mxout-08.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-3.347, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UTP5h-00012T-NC 37ff06890ea90a6818f57e9c812de90b
X-Original-To: ietf-http-wg@w3.org
Subject: p1: HTTP and TCP name delegation
Archived-At: <http://www.w3.org/mid/7B626010-D681-4109-BDA5-807BCAE72012@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17375
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

p1 2.7.1 says:

> Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources — it is only the authoritative interface used for mapping the namespace that is specific to TCP.

I made a previous editorial comment that this should be clarified as follows:

"...because the name delegation process depends on the TCP port for establishing authority."   (note "port")

However, that wasn't integrated. Is that incorrect, or was there another reason?

Also, no such statement is made in the definition of the HTTPS URI scheme (2.7.2); it should be.


--
Mark Nottingham   http://www.mnot.net/