Re: Straw-man charter for http-bis

Keith Moore <moore@cs.utk.edu> Sun, 17 June 2007 15:17 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 1HzwUw-0004qt-Gl; Sun, 17 Jun 2007 11:17:02 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HzwUu-0004qm-Qf for discuss-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 11:17:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwUu-0004qe-HC for discuss@apps.ietf.org; Sun, 17 Jun 2007 11:17:00 -0400
Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzwUt-00044S-V7 for discuss@apps.ietf.org; Sun, 17 Jun 2007 11:17:00 -0400
Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 963FC1EE259; Sun, 17 Jun 2007 11:16:54 -0400 (EDT)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orKt4J+1zj4g; Sun, 17 Jun 2007 11:16:52 -0400 (EDT)
Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 5FE151EE251; Sun, 17 Jun 2007 11:16:39 -0400 (EDT)
Message-ID: <46755041.4040401@cs.utk.edu>
Date: Sun, 17 Jun 2007 11:16:17 -0400
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604)
MIME-Version: 1.0
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Subject: Re: Straw-man charter for http-bis
References: <BA772834-227A-4C1B-9534-070C50DF05B3@mnot.net> <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> <1181532224.3389.47.camel@henriknordstrom.net> <466CC26F.90603@cs.utk.edu> <342C5167F40AD28C4ED69C9B@[10.1.110.5]> <1182080252.751.41.camel@henriknordstrom.net>
In-Reply-To: <1182080252.751.41.camel@henriknordstrom.net>
X-Enigmail-Version: 0.95.0
OpenPGP: id=E1473978
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: Apps Discuss <discuss@apps.ietf.org>, Mark Nottingham <mnot@mnot.net>, Chris Newman <Chris.Newman@Sun.COM>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Eliot Lear <lear@cisco.com>
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

>> I would speculate it's because the following mandatory pieces of a complete 
>> DIGEST-based solution were never written down:
>>
>> * Client UI requirements
>>     
>
> Sure, but how much of this is the role of IETF?
>
> Since when do IETF specify client implementation besides what impacts
> the wire protocols?
>   
Traditionally we try to not constrain client design more than necessary,
but that doesn't mean we strictly limit ourselves to defining what
happens on the wire.  And to the extent that we have limited ourselves,
if we're learning that this is not sufficient, that's a good reason for
relaxing that limitation.

> Also don't forget that HTTP has widespread use in many applications
> where there is no UI at all.
>   
IMHO it would be reasonable to define a profile of HTTP for use with
interactive web browsers.
>> * How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support
>>     
>
> As first point above, but server implementation.
>   
I don't see why we shouldn't describe these things if doing so helps
acceptance and interoperability.  Perhaps as informational rather than
normative text, but we should make sure that there's a complete
picture.  These things are important to the success of an authentication
system.  A lot of our failings in the area of authentication have been
due to failure to consider more than just the on-the-wire protocol - we
haven't tried very hard to make our technology accessible to potential
users.

Keith