Re: Byte ranges -- formal spec proposal

It doesn't look like this mail made it in the first go, sorry if
it pops up again!

Larry wrote:

> Please give a single, specific and realistic example. If you think a
> framemaker document can be retrieved a byte range at a time, what is
> the initial byte range? How do you know?
> 
> Can PDF documents be retrieved partially? A priori? How many bytes
> would you know to ask for in the first place? Is 'the first part of a
> PDF file' still 'application/pdf'?

I can see several applications where this would be a good and
useful idea, for example in audio and video - or as a general approach to
having external links into any compound data format - quite similar to
what HyperG is doing. 

However, I don't like the specific byte count so much as the idea
in general. If we can keep it to a set of logical names as a function
of media type then I would be a lot more happy, for example frame
count etc. Can't we just change the `Misc' part into the main part
of the proposal - this part talks about the logical names - not 
specific byte numbers.

In my opinion, URLs are already quite shaky and if we can avoid having
another update problem in URLs every time a new version of the resource
behind it is generated, if would certainly prefer this!

> > 2. Just regular Web clients where image or document transfer is
> > interrupted before the entire image/document is received, and then
> > later restarted.  So instead of starting all over again you could only
> > transfer the remaining part of it.

This is also one application but I think that the ones above are much more 
frequently.
 
> This is http specific, isn't it? Surely a FTP server won't support
> this. So, does this belong in the URL at all? 

No, you are right :-)


-- cheers --

Henrik Frystyk                                          frystyk@W3.org
World-Wide Web Consortium,                              Tel + 1 617 258 8143
MIT/LCS, NE43-356					Fax + 1 617 258 8682
77 Massachusetts Avenue
Cambridge MA 02154, USA



 


----- End Included Message -----

Received on Thursday, 18 May 1995 22:33:20 UTC