> > According to Daniel W. Connolly:
> > >
> > > A nice, clear, complete proposal. As you say, this could be done as a
> > > server-private mechanism, but there's no reason why everybody
> > > shouldn't do it the same way.
> > >
> > > A couple nits:
> > >
> > > > * The first byte in file is byte number 1.
> > >
> > > Blech. I'd rather it were 0. No biggie.
> > >
> >
> > Base 0 is fine for bytes but would be problematic for other ranges.
> > E.g.
> >
> > http://host/book;chapterrange=3-5
> >
> > would mean chapters 4 to 6 if base 0 is used. This would be just too
> > confusing. We thought it better to be consistent and use the same
> > base for everything.
>
> I don't think this is relevant: http should be kept simple and data-type
> independent, leave out the higher level semantics. Then 0 based
> addressing is the most sensible. Even for chapters, the argument is
> weak: what chapter number is the title page? What chapter number
> applies to appendicies? Does the number then need to be a string that
> names a sub-entity? This is a Pandora's Box that should stay closed.
As long as that sort of query at the _user level_ maps exactly, this is
fine with me. (I think that something akin to the above "chapterrange=3-5"
should actually mean what it seems to, at that level.)
>
> Any thought on how this should interect with dynamic computed documents
> (CGI-bin scripts)? Supporting range addressing of computed documents
> would require either re-computation on each fetch, or caching. If
> re-computed, how do you guarantee consistancy? Imagine fetching a
> document one byte at a time that contains the server's load average.
Steve Richardson/Merit