Comments on Byte range draft

In the range specification section it says:

* In the case that the second integer is smaller than the first
  one, an empty range is returned.

Since the specification says just above that point that:

* The first integer must always be less than or equal to the second
  one.


I would suggest that in cases where the second integer is smaller than
the first, an error message indicating a malformed header should be
returned (rather than an empty range).  An empty range doesn't tell
the requester what went wrong; an error message might.

In the section on the return of multiple ranges as multipart MIME
messages, the draft says "A server may send also a single byte range
as a multipart message."  Why should a server send a single byte
range in a multipart message, and would that break any clients expecting,
not unreasonably, multiple parts to a multi-part message?

I also note that the draft gives the response Range header as
Range: bytes x-y/z .  Is z in use to handle situations where a
new version has occurred between the clients request of one byte
range and another, and, if so, isn't that already handled by the 
other headers (you note that the if-modified-since works with
this)?  I also assume that the Last-modified header and if-modified
since header will generally be applied to the document as a whole, 
not to the individual byte-ranges, but I'm afraid I didn't find
the draft to be too clear on this point.

				Regards,
					Ted Hardie
					NAIC