Proposal for checkpoint 9.4 (transfer) [Was: Re: Tim's work items]

Hi Tim,

Thanks for sending in these comments so quickly. My comments
below preceded by IJ:


Tim wrote:
> 0.  Undocumented Bonus Work Item:  HTTP:HEAD
[snip]
  
> 1.  Possible error codes
[snip]

> A note on errors:  I haven't read the RFC in it's entirety, but it is my
> understanding that any/all HTTP errors have the same recovery mode: try it
> again, which is to say, there isn't a recovery mode.

IJ: This is a key piece of information. I spoke with Henrik (co-author
of HTTP/1.1 about this and he said that the UA should not report error
codes to the user. Instead, the server should return a message body
with any information the server manager deems important. Of course,
these pages need to be accessible. But is should not be the
responsibility to report server error codes through other mechanisms.

> 2.  From the archives:
>  
> 9.4 When transferring content (e.g., a document, image, audio, video, etc.)
> indicate what percentage of the content has been transferred and whether the
> transfer has stalled.
>  
> Proposed:
> 
> 
> 9.4 When transferring content (e.g., a document, image, audio, video, etc.)
> indicate what percentage of the content has been transferred and whether the
> transfer has been interrupted.
>  
> Reasoning:  "Stalled" implies that a process can be "UnStalled", which in
> the case of an HTTP transfer, is not possible once the timeout has expired.
> To me, "interrupted" doesn't have as strong an implication.  I originally
> thought "failed" would be good, but we then have the case that an FTP
> transfer *can* be un-stalled.  Sigh.
>  
> This also doesn't address the exception for streaming content, which has no
> 'size'.

IJ: So here are comments based on talking with a number of people
    about this topic;

1) There's no way to be 100% sure that a transfer has stalled. For
   instance, how does the UA tell the difference between a slow site
   (e.g., across the ocean) on a good day and a fast site on a bad day? 

   I think that "interrupted" suggests that it's either interrupted by 
   the server or the client, and while some HTTP codes may convey that 
   info (500 codes?), that is different from "it's been a long time 
   and nothing happens". If you get a complete response from the 
   server, you just process it according to the HTTP spec.

2) Not all content has a known Content-Length (e.g., content generated
   on the fly, streamed media, etc.). Therefore, the "proportion" 
   requirement is subject to applicability.

3) Since the amount of content and the rate of exchange continues to
   chagne, what is an acceptable user interface for conveying that
   information? When I look at the status bar and numbers change very
   quickly from 0% to 100%, that is not really useful to me. It's most
   useful when the transfer is slow or when there's a lot of content
   being transferred and I can tell that I've got to wait a lot longer.
   It's probably best for the UA developer and the user to not have
   to think about special cases. The UA should always provide
information
   and the user should always be able to use it as they wish and to the
   best of their ability. If quickly changing numbers aren't helpful
   when spoken, then that's ok since that means the page is downloading
   quickly. (I don't know how ATs handle rapid changes in a status bar,
   however. Comments welcome on techniques for ATs in this case.)

Proposal:

<IJ9.4>
9.4 When receiving content as the result of a request for a Web
    resource, indicate the proportion of content received and 
    the temporal progress of the transfer.

   Note: Proportion is subject to applicability since the user
   agent may not receive information about the total content
   size from the server. User agents may indicate temporal progress
   in a number of ways, including time since information was
   last received, an approximate data transfer rate, etc. 
</IJ9.4>

Notes:

1) I removed the parenthetical example from the checkpoint since
the word "content" links to a definition.

2) I changed "transfer" to "receive" for the initial clause
  since I think this checkpoint only applies to the UA when
  receiving content.

3) The techiniques document will offer more information about
   both "number of bytes" progress and "time of transfer" progress.
   In particular, the techniques should warn developers that very
   slow progress doesn't always imply stalled transfer.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Wednesday, 9 August 2000 16:43:20 UTC