W3C home > Mailing lists > Public > uri@w3.org > June 2003

RE: temporal URI fragments

From: Larry Masinter <LMM@acm.org>
Date: Tue, 24 Jun 2003 18:20:24 -0700
To: <Silvia.Pfeiffer@csiro.au>
Cc: <uri@w3.org>, <Conrad.Parker@csiro.au>
Message-ID: <005101c33ab7$f43b0280$8d422099@MASINTERPAD>

> 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

> 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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:06 UTC