proposed mods to draft-decroy-http-progress-00.txt

I'm proposing a few changes to this ID.  Just thought I'd run them by
people here before writing up the ID itself.

Thanks all for insight and comments received so far.

1. Remove flow control discussion / proposed new status code from the draft.

As raised by people on this list, pre-negotiation of transfer of message
body would need a radical change to semantics of messages, and is
therefore I believe not worth pursuing in this ID.  I still believe it's
a problem worth solving, but I think would require another HTTP verb -
well beyond current scope.

The ID would then be reduced to a discussion of progress messages for
human users of HTTP client software, something which I still feel would
be very useful to many people.

2. Remove language tag from Progress request header - the user preferred
language is already adequately specified by other headers (i.e.
Accept-Language).  Since the text portion of the response is purely
informational and doesn't affect protocol nor resource content, it is
proposed to make it non mandatory for the agent generating the text to
comply with the language wishes of the UA which made the request.

3. Clarify use of 1xx messages to convey these progress response headers
(messages).

I think the best code to use for this is 102 as per RFC 2518 (WebDAV)

RFC2518 s 10.1 isn't clear about whether 102 may be sent multiple times,
but RFC 2616 s 10.1 para 2 explicitly requires clients to handle receipt
of one or more 1xx responses.  Potentially many 102 interim responses
will be sent in scenarios anticipated by the draft.

4. Add an option for a non-client-defined interval.

If the UA submits an interval of 0 (e.g. tag is "Progress: 0") then it
is left up to the next-hop to decide how often to send or forward
updates.  This would likely be on any of

a) significant portions of work being done in any particular phase of
processing (i.e. every 10% downloaded)
b) any change of phase (e.g. connecting->requesting->downloading ->
scanning)
c) a fixed arbitrary interval.
d) any combination of the above

It is to be noted that this information is intended to be presented to a
human, so designers of web applications may have other valid reasons to
send status messages to users during processing that can't be
anticipated by this draft.  I believe a certain amount of freedom should
be allowed in terms of frequency and content.  Since a rogue proxy or
server could easily violate any requirement of the draft on maximum
frequency anyway, a UA implementing this would need to take steps to
prevent abuse of this messaging channel.

Regards

Adrien de Croy

Received on Tuesday, 20 March 2007 12:49:34 UTC