- From: Dave Raggett <dsr@dragget.hpl.hp.com>
- Date: Tue, 4 Oct 94 15:28:17 BST
- To: http-wg@cuckoo.hpl.hp.com
To get things moving for the proposed HTTP working group, I have
set up a new mailing list (http-wg@cuckoo.hpl.hp.com) and added a
few people (including yourself) who have shown interest in the working
group. To unsubscribe send an e-mail messsage to:
http-wg-request@cuckoo.hpl.hp.com
I am writing to you to get your input on the proposed charter and
workplan to be discussed at the HTTP Working Group BOF at WWWF'94 in
Chicago. Early input will help to ensure that the BOF makes the best
use of our limited time together, and I would like us to be able to get
names against actions to start things rolling along. Our next chance to
get together, after WWWF'94, will be the December IETF meeting in San Jose.
Please email your comments on the proposal and thoughts as to how to get
the best out of the WWWF'94 BOF to <http-wg@cuckoo.hpl.hp.com> or to me
personally at <dsr@hplb.hpl.hp.com>
Many thanks,
Dave Raggett <dsr@hplb.hpl.hp.com> +44 272 228046 (United Kindom)
----
Proposed Charter for the IETF Hypertext Transfer Protocol Working Group
-----------------------------------------------------------------------
Right now HTTP is in a mess. The internet draft has expired and needs
updating to bring into line with current practice. The performance is
widely perceived to be poor, particularly for modem users, and various
groups are working on disparate approaches for adding security and payment
mechanisms.
Left to itself, we will get fragmented de facto standards that inhibit
interoperability. Even if one company wins out as the dominant supplier
of servers and clients, it will act as a bottleneck for change with
negative effects for end-users and value-adding niche suppliers.
The role of W3O and the IETF should be to facilitate the development of
open standards in which everyone can gain. To achieve this we will need
to take advantage of the best work whether it is done at academic research
centers or by commercial developers.
Internet drafts and RFCs offer a route for nailing down an open framework for
the protocol and for standard APIs for plug-in modules. This will facilitate
interoperability by encouraging re-use of security modules rather than, for
example, forcing every developer to separately negotiate with RSA for rights
to use public key algorithms, or with the Department of Commerce for export
licenses. Acting together, we can get better deals.
Our suggested focus is on the short term. In particular, we want:
a) to tap into the 30% of US homes with PCs/Macs and provide
the incentives for them to connect to the Web
b) to make it easy to pay for goods and services on the Web
c) to protect the copyright interests of information providers
To meet these objectives, we need to build on existing work and scale
our action plan to what is feasible in the short term.
Security and Electronic Payments
--------------------------------
The suggested timetable for this is to first concentrate on what is needed
to securely send order details and receipts. Credit card payments can be
authenticated offline by the credit card companies, but the next step is
to provide support for authenticating servers, and subsequently clients.
Basic authentication is possible using the IP address. Other mechanisms
include Kerberos, and public key certificates. We shouldn't overlook
encryption of arbitrary HTTP requests and responses.
Smart cards have a bright future for payments based on credit/debit models
and digital cash. In the short term, no one has card readers and we need
to consider how to get things off the ground. In transitioning from here
to there, we need to make it very simple for end-users and financial
institutions. Some of the issues this raises include: how users register
with an authentication server; if public key mechanisms are used, who
generates the public key/secret key pairs and certificates; do the credit
card companies store the certificate information as well; and are the
transactions themselves are protected for both secrecy and integrity?
Mosaic Communications, EIT, Spyglass and CERN all have different approaches
to this! The working group will need to come up with an open framework that
supports a range of different approaches. Could we agree on using a standard
header to indicate which approach is in use, and to indicate acceptable
alternatives? Can we agree on a high level set of security mechanisms and an
API for implementing them with a range of cryptographic techniques? Is there
any role here for the GSS API?
Improved Performance
--------------------
It may prove worthwhile to extend MIME for use with an improved HTTP.
Switching to a binary encoding of the protocol headers will not of its
own give us the performance we desire, but many of the weak spots in the
current protocol have been repeatedly discussed on the mailing lists.
We would like to see one or more Internet Drafts covering:
- MGET and multipart messages
The ability to request several objects in the same request. The
objects are then returned as a multipart message.
- keep-alive and segmented transfers
This gives us the ability to get an HTML file and then request the
inlined images reusing the same connection.
- encouraging deployment of transaction TCP
Recent proposals cut out the slow start up times of conventional
TCP protocol stacks. Can we coordinate our efforts to promote the
widespread adoption of these extensions to TCP?
- ways to avoid long lists of Accept headers
and to better specify client capabilities
Right now Mosaic sends out long lists of Accept headers which could easily
be replaced by more compact identifiers for standard configurations. For
home users with standard VGA and slow modems, it would be great if servers
could take advantage of this to send more compact images.
- consideration of an ASN.1 based format
We need to look at the advantages of switching to a binary encoded format
for protocol headers.
Suggested Workplan
------------------
October '94:
We meet in Chicago and seek agreement that a common
framework is needed for security and payment mechanisms,
as well as brainstorming the problems/issues that the
framework should address. We agree a numbering scheme
for subsequent HTTP releases, and get interested people
to sign-up to take an active role.
November '94:
Work starts on a revised Internet Draft covering HTTP as in
current use. The http-wg mailing list may be appropriate for
exchanging detailed comments on this document as it is written.
We use the www-security mailing list to continue brainstorming
ideas on the common security framework. One or more people
nominated at the October BOF write this up as an initial draft.
The objective for November is to finalize the charter and initial
workplan for the IETF working group. The group uses the http-wg
mailing list to work together on this document.
December '94:
IETF HTTP WG BOF - we present the charter and workplan. This meeting
should be used to build the consensus and to look forward to the next
set of actions and milestones. The work group is formally established,
and people are signed up to write particular Internet Drafts.
Spring '95:
We present Internet Drafts for the revamped HTTP spec describing
current practice; the framework for security; and for improved
performance. This will coincide with the Internet Draft for HTML 3.0.
WWW'95:
Demonstrations of working implementations of these Internet Drafts.
The HTTP working group starts looking at new issues such as the
framework needed for digital cash, collaborative hypermedia, and
scaling issues for information access and the implications for HTTP.
IETF HTTP BOF in December
-------------------------
I have reserved a slot at the December meeting of the IETF in San Jose.
The Hypertext Transfer Protocol (http) BOF will be held on Tuesday,
December 6: 1330-1530. Further info on IETF meetings is available from:
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link for
"meetings" and you should find an entry for the San Jose meeting.
Dave Raggett - 2nd October 1994
Received on Tuesday, 4 October 1994 15:31:47 UTC