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

Cyrus Daboo <cyrus@daboo.name> Thu, 31 May 2007 13:42 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 1HtkvI-0002Zs-Sd; Thu, 31 May 2007 09:42:40 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtkvH-0002WL-6x for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:42:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkvG-0002Ug-T0 for discuss@apps.ietf.org; Thu, 31 May 2007 09:42:38 -0400
Received: from piper.mulberrymail.com ([151.201.22.177] helo=mulberrymail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtkvF-0006Vs-HI for discuss@apps.ietf.org; Thu, 31 May 2007 09:42:38 -0400
Received: from [17.101.35.92] ([17.101.35.92]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l4VDgSew025020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 09:42:31 -0400
Date: Thu, 31 May 2007 09:42:22 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Robert Sayre <sayrer@gmail.com>, Mark Nottingham <mnot@mnot.net>
Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617
Message-ID: <AF50DDD797FD9753B3C31D92@ninevah.local>
In-Reply-To: <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.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>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on piper.mulberrymail.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Eliot Lear <lear@cisco.com>, Larry Masinter <LMM@acm.org>, Apps Discuss <discuss@apps.ietf.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

Hi Robert,

--On May 31, 2007 1:28:39 AM -0400 Robert Sayre <sayrer@gmail.com> wrote:

> My feeling is that the current schemes can be updated by documenting
> the internationalization behavior of popular implementations, but
> nothing else is worth doing.

I disagree. I think we need to go a lot further. My suggestion would be to 
throw away 2617 as-is, and instead do something more akin to the SASL 
document set, i.e. a "framework" document describing the general issues of 
http authentication that lays out the ground-work for the existing 
http-based auth schemes, plus documents other auth schemes in use 
(form-based, cookie-based etc). We then have separate documents for each of 
the http-based schemes basic and digest - and we should add Kerberos/SPNEGO 
to that too. Having those as separate documents will make updates in the 
future an easier process. If we want to document other types in more detail 
(as proposed or informational) that could be done too.

I would also like to see the "webmail" (proxying credentials though a 
web-app to some back end service) issue dealt with too - ideally with the 
Kerberos mechanism as a basis (and others too that make sense).

I think all that is a lot more work than just a quick rev of 2617. Given 
that it involves a lot of security there will be a need to have the direct 
participation of the Security area folks. They are less likely to be 
interested in the minutiae of 2616bis though. So I think separate working 
groups would be better because of the different cross-area participation 
requirements.

-- 
Cyrus Daboo