RE: temporal URI fragments

> Oh, I'm sorry. I believe there is a misunderstanding. I am not asking to 
> put the temporal URI fragment specification into the Generic URI 
> Specification RFC. All I am asking for is to allow in RFC2396 that 
> fragments can be interpreted at the server side after all other 
> operations have been performed on the resource.
 
I don't understand how this happens. The client gets the URI reference
and is attempting to resolve it. It splits at the "#" and does something
with the two sides. There's no way to guarantee that the client
will send the fragment to the server except in extraordinary
circumstances, though. If the URI is "file:", for example, there's
no server to send it to. If the URI is "http:", there's no protocol
in HTTP to send fragment identifiers.  Maybe if the URI is "rtsp"
and the actual data is temporal, you might be able to get a temporal
fragment?


> Why would that be any more fragile than the mime types?
> For audio and video there are probably no other time schemes that are 
> needed. But there are many other time-continuously sampled data file 
> types which we have no knowledge of, e.g. the above mentioned data of 
> physics experiments. If somebody requires a time scheme that is useful 
> for another type of time-continuous data and that does not exist yet, 
> he/she would write another I-D that explains this time scheme and its 
> resolution and asks for registration with IANA. If it gets accepted, 
> servers will support that scheme over time.

Why not make the fragment identifier independent of the sample
rate? Aren't there situations where you might want to send
different sample rates depending on the bandwidth of the
connection? Or situations where there is timed data that isn't
'sampled'? I'm not sure why 'seconds, in floating point, to
any accuracy desired' isn't a better design as far as interoperability
might go.

Larry

Received on Tuesday, 24 June 2003 21:20:39 UTC