- From: Larry Masinter <LMM@acm.org>
- Date: Sun, 8 Jun 2003 10:56:06 -0700
- To: <Silvia.Pfeiffer@csiro.au>
- Cc: <uri@w3.org>
Your long message seems to mainly focus on the argument about why _some_ standard is needed, but I'm not sure you've addressed the objections raised about _this particular_ formulation. 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. 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. 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. 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? Larry -- http://larry.masinter.net
Received on Sunday, 8 June 2003 13:56:33 UTC