Re: Comments please on agenda for HTTP working group BOF

Thanks for initiating this! My comments to this proposal are:

> 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.

It is not only GET - we also need a way to have multiple POST (and
PUT). The reason for this is that a message is often to be posted to
one or more mailing lists, one or more news groups and maybe a remote
HTTP server. I have described how I would like the client interface to
the Library of Common Code when building what I call a POST-Web at

   http://info.cern.ch/hypertext/WWW/Library/User/Features/ClientPost.html

If the client is capable of talking directly to all the remote servers
then this causes no problem for the HTTP protocol. However, if the POST
request is going through a Proxy server, the current POST concept is
inadequate. I think that MIME is an obvious tool to be considered to
extend the HTTP protocol.

>     -   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.

I am currently testing my implementation of the multi-threaded version
of the HTTP client in the Library of Common Code (The implementation is
*platform independent* and does not require threads)

When this is working then clients have a far more powerful tool to keep
connection alive, not only for inlined images but also for HTTP
sessions, video etc.

>     -   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?

In my opinion TTCP is a very nice way of enhancing TCP - I think we
need something that is backwards compatible with TCP for a long time to
come.

>     -   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.

YEP - why not use MIME types without sub-types?

>     -   consideration of an ASN.1 based format
> 
> We need to look at the advantages of switching to a binary encoded format
> for protocol headers.

What is ASN.1??? - I agree that the protocol must turn into binary mode
but I am not sure that this is the right time to do it. Maybe we can
have an extension to the HTTP as TTCP is to the TCP - that is start
binary - if failure then fall back to the text based HTTP?


> 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.

The workplan is _very_ ambitious - I think it is the right way to do it
- so let's start :-) I am very interested in having an active role in
the work!


-- cheers --

Henrik Frystyk
frystyk@dxcern.cern.ch
+ 41 22 767 8265
World-Wide Web Project,
CERN, CH-1211 Geneva 23,
Switzerland

Received on Friday, 7 October 1994 16:01:03 UTC