RE: Straw-man charter for http-bis -- call for errata/clarifications to 2617

Henrik Nordstrom <henrik@henriknordstrom.net> Fri, 01 June 2007 13:06 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006bc-Bc; Fri, 01 Jun 2007 09:06:58 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htskk-0005gc-9B for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:04:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htskj-0005gU-VR for discuss@apps.ietf.org; Thu, 31 May 2007 18:04:17 -0400
Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htski-0007n0-Hh for discuss@apps.ietf.org; Thu, 31 May 2007 18:04:17 -0400
Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id DEEEF38755; Fri, 1 Jun 2007 00:04:14 +0200 (CEST)
Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C3A1B37F9F; Fri, 1 Jun 2007 00:04:14 +0200 (CEST)
Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 255BA37E46; Fri, 1 Jun 2007 00:04:10 +0200 (CEST)
Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VM49UT019114; Fri, 1 Jun 2007 00:04:09 +0200
Subject: RE: Straw-man charter for http-bis -- call for errata/clarifications to 2617
From: Henrik Nordstrom <henrik@henriknordstrom.net>
To: Eric Lawrence <ericlaw@exchange.microsoft.com>
In-Reply-To: <8301DE7F96C0074C8DA98484623D7E51157CAB5862@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
References: <BA772834-227A-4C1B-9534-070C50DF05B3@mnot.net> <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <p06240843c2833f4d7f2f@10.20.30.108> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <C1E6F3CB-49C6-4C0F-955A-3D69D26987C6@mnot.net> <000c01c7a318$7bc243e0$7346cba0$@org> <E21FCD3A-D51A-4C06-B46D-3EA3ED54592B@mnot.net> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <AF50DDD797FD9753B3C31D92@ninevah.local> <1180637848.4471.11.camel@henriknordstrom.net> <BE9343000CA9252766BBCA03@caldav.corp.apple.com> <8301DE7F96C0074C8DA98484623D7E51157CAB5862@DF-MASTIFF-MSG.exchange.corp.microsoft.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CSxoylVC4AEKYMXbb2fM"
Date: Fri, 01 Jun 2007 00:04:09 +0200
Message-Id: <1180649049.5423.31.camel@henriknordstrom.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6)
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400
Cc: Eliot Lear <lear@cisco.com>, Larry Masinter <LMM@acm.org>, Robert Sayre <sayrer@gmail.com>, Apps Discuss <discuss@apps.ietf.org>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Paul Hoffman <phoffman@imc.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

tor 2007-05-31 klockan 14:28 -0700 skrev Eric Lawrence:

> You're right, but Henrik's point still stands.  The existing
> implementation of Negotiate/NTLM is significantly different than the
> conventional HTTP authentication "per-message" model.  It may be
> difficult (or undesirable) to roll this into RFC2616.

I would undesirable. It requires a far too big change in the transport &
message model of HTTP, and in it's current form has some serious (but
partially documented) security implications when using proxies.

HTTP is explicitly designed as a transport-independent message oriented
protocol where each message is self-contained and not dependent on being
sent on a specific transport connection.

RFC4559 is completely connection oriented, with messages far from
self-contained and very dependent of which transport connection is being
used.

Regards
Henrik