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