shopping baskets w/o dynamic documents (proposal)

In message <> 13 Jun 1996 16:26:36, wrote:

> Once upon a time Daniel Glazman shaped the electrons to say...
> >Sorry to disturb but is it the right place to submit a proposal
> >of HTML and HTTP extension about WWW shopping baskets management ?
> Pretty much here or www-talk

Ok, so let's go. Please apologize 1) the cheek 2) the poor quality
of my english 3) the general state of the document, it's only the
first (and maybe the last) sketch of the first draft of an idea ;-)))

The proposal is about a **very** cheap way of implementing shopping baskets
__without__ cgi-bins bulding dynamic documents. I guess everyone can
immediately see the impact on the server's load. The proposal does not
deal with "identification" but only "ID attribution".

A W3C draft has been issued quite on the same subject in february (see
document's references) but does not seem to generate a lot of discussions.
The contents of my proposal is a bit different because it leaves to HTML
the full control of ID attribution and is based on a new HTTP method.

If implemented, we'll (EDF) surely be the first to use it !!! We're a bit tired
of dynamic shopping basket management.

Hardly waiting for your comments....

Best regards from a sunny Paris, France.

</D.Glazman>, webmaster @ Electricité de France, R&D Division


		A simple mechanism of HTML and HTTP extension
		    for WWW commercial applications using
			    shopping baskets.

			     Daniel Glazman
		   Electricité de France, R&D Division

			     13 June 1996

	Many applications on the World Wide Web absolutely need
	that an ID is attributed to each visitor. The most frequent
	case is the "shopping basket" which actually implies strong
	use of cgi-bin and dynamic documents.
	This document proposes a new technical solution to this problem
	based on a new HTML element, one new HTTP method and two new
	HTTP fields.

1. Context

	Since the explosion of the World Wide Web at the end of 1994 and
	the emergence of commercial activities on the Internet, no
	mechanism has been designed to fill the gap of ID attribution
	even if the HTTP protocol contains authorization schemes.

	ID attribution means that a server is able to give an unique
	ID to each visitor, the client's browser is able to retrieve
	this unique ID from the server and use it while navigating in
	server's contents.

	This document contains a simple proposal for HTTP ID attribution
	based on a HTML extension and a HTTP extension. This proposal
	differs from [Session-ID] W3C working Draft because the mechanism
	described in W3C draft mixes authentication and ID attribution.
	The present document keeps these two concepts unlinked.
	Furthermore, it gives the control of ID attribution to HTML and
	client's human manipulator.

2. HTML extension

	It is proposed to add the new element REQID to the contents
	of HEAD element in current HTML 3.2 draft.

	This element holds the following attribute :



	This element, when parsed by a browser after a real net
	connection, means that the browser should issue a HTTP
	request asking an ID to the remote server.

	NAME attribute contains a name associated to the to-be-
	requested ID.
	SHOWN attribute when present indicates that the ID attributed
	by server should be shown to the human being manipulating the
	client, using for instance a popup window. The message could
	then use the value of NAME to make it more readable.

	This ID will be used for all following HTTP requests provided
	the new header field SolicitorID.

3. HTTP extension

	When a browser parses a HTML document containing a REQID element
	in its HEAD, it should issue a HTTP request to the document's
	URL using the RQID method.

	Example: the client has requested the document and this document contains a REQID
	element. The browser should then issue a HTTP/1.1 request :

		User-Agent: my best browser v12

	No Entity-body should be provided in these RQID requests.

	The server's HTTP response to these requests introduces new
	answer codes :

	* 207 ID attributed

	  The server has attributed a new unique ID to visitor in response
	  to client's request. The value of the new HTTP field SolicitedID
	  contains this ID.

	* 506 no ID available

	  The server is unable to answer to client's demand and attribute
	  an ID.

	Server's response to RQID request may contain a informational

	When obtaining an ID from the server, a client should integrate
	a new field SolicitorID in all its HTTP requests to this server
	whatever is the HTTP method.

	For instance :

	 client's request
		RQID http://www.shoppingmall.xx/ HTTP/1.1

	 server's response
		HTTP/1.1 207 ID attributed

	 following client's requests
		<method> <URL> HTTP/1.1

	A new error status code is then needed :

	* 416 improper ID

	  The SolicitorID value contained in the request is not
	  recignized by the server. Client should issue a new RQID
	  request and obtain a new ID.

	ID values could be formed using the syntax described in
	[Session-ID] or remain strictly site-dependant.

4. Common Gateway Interface

	It is suggested that a new variable HTTP_SOLICITOR_ID be
	provided to CGI/1.1 compliant applications, containing
	the value of the HTTP request's field SolicitorID, if provided.

	This value would be mainly used when filling the shopping
	basket with a new item and when issuing the order.

5. Conclusion

	The mechanism described above, if implemented in HTTP servers
	and browsers, makes the implementation of commercial activities
	using shopping baskets possible at a very low cost. Because
	no cgi-bin building dynamic documents is needed in such a technical
	solution, the server's and traffic's load should also descrease
	in a significant way.

6. Author

	Daniel Glazman

	Research Engineer, Webmaster

	Electricité de France, Research & Developement Division
	1 avenue du Général de Gaulle

	Phone: +33 1 47 65 35 70
	Fax:   +33 1 47 65 35 23


7. References

	Phillip M. Hallam-Baker, Dan Connolly
	"Session Identification URI"
	W3C Working Draft WD-session-id-960221

	R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee
	"Hypertext Transfer Protocol -- HTTP/1.1"
	Internet-Draft <draft-ietf-http-v11-spec-05>

Received on Friday, 14 June 1996 04:22:21 UTC