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

Re: temporal URI fragments

From: <Silvia.Pfeiffer@csiro.au>
Date: Wed, 11 Jun 2003 15:50:43 +1000
To: LMM@acm.org
Cc: uri@w3.org, Conrad.Parker@csiro.au
Message-ID: <3EE6C333.6010908@csiro.au>

Dear Larry,

many thanks for taking the time to read through the document.

Larry Masinter wrote:
> Your long message seems to mainly focus on the argument
> about why _some_ standard is needed, 

Indeed, my main point was that we need _some_ standard. I'm not really 
too fuzzed about which way we do it, but our proposal seems the most 
advanced of all the ones I have seen. I've also discussed it with others 
such as people in MPEG-21, people at Apple, and SMPTE people and our 
proposal seemed to make sense to them, too.


> but I'm not sure
> you've addressed the objections raised about _this particular_
> formulation.

As you correctly point out, I have not addressed some of the objections 
about _this particular_ formulation, because I have already incorporated 
them into the document (namely: need for more SMPTE schemes, need for 
registration for other schemes, need for addressing of temporal 
intervals as well as time points). The main objection on this list was 
however that we should not go for "fragments" but rather for "queries". 
That's the main point I tried to address. Sorry for being unclear.

> I have no trouble with individual media types
> defining temporal fragments. I think it would even
> be interesting to consider whether we might establish
> a policy (BCP) that audio/* and video/* media types
> should adopt such a temporal fragment. And I would
> imagine that one could point out that some protocols
> (and thus URI schemes) might have specific support
> for temporal fragments, while others (http, ftp, smb, nfs)
> might only support byte range (or offset) retrieval,
> leaving it up to the client to interpret the temporal
> fragments.

Great!

> But I don't think you can assume that these fragments
> can be implemented in general, without any other
> caveats, and get the expected behavior.

Hmmm...

> I'm also dismayed by the complexity of all of the
> different smtpe time codes, which seems to make
> an unnecessary dependence on another complex
> external standard.  RTSP (rfc 2326) section 3.6
> seems to get by with a very simple time start
> and offset. 

Our proposal was actually based on the RTSP standard that you're 
pointing out (rfc2326). RTSP uses all three classes that we provide for, 
too. The section you're pointing out describes the npt way of 
addressing. The smpte way of addressing is in section 3.5 and the utc 
way of addressing in section 3.7. After feedback from SMPTE, we've just 
made the SMPTE list more current. With registering schemes through IANA 
it is possible to extend it at any time. I fear it's a little like the 
MIME types registration. We just cannot foresee all required time 
addressing schemes right now. E.g. there may be some scheme for 
addressing pico-second resolutions in data of physics experiments. 
Therefore, I believe we need to be extensible.

> Since the most widely used URI schemes will
> be 'rtsp', 'http' and (probably 'file'), and there's
> some question about the implementability of your
> proposal, perhaps you could point to some experience
> with an implementation of this specification?

That's actually one of the reasons I've been quiet for a while. We have 
implemented a system that demonstrates the use of the temporal URI 
schemes. We've put descriptions up at http://www.annodex.net/ . There is 
no code yet, but the libraries are coming within the next week. An 
application should be up within 2 weeks.

Silvia.
Received on Wednesday, 11 June 2003 01:54:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT