Re: temporal URI fragments

Larry,

Larry Masinter wrote:
> I'm still bothered by putting 'extensibility' into the
> fragment identifiers.  You can get away with having
> extensibility in a _protocol_ where, if one side doesn't
> understand the vocabulary, you can revert to a different
> vocabulary. But there is often not very much negotiation
> possible between the generator of the URI and the URI
> interpreter. Having lots of "options" isn't a good idea
> in such situations.

There is not much negotiation necessary: either the server understands 
the fragment and can return the requested data or it cannot in which 
case it returns an error (http: 404 not found).


> For interoperability in the presence of options and
> without negotiation, everything that is optional for
> a sender must be mandatory for a receiver. ("without
> negotiation" = the receiver can't throttle back the
> options that a sender will communicate.
> 
> When you send me a URL embedded in something, I generally
> don't have any control over the scheme you use or any
> of the features you might use in a fragment identifier.
> 
> So having lots of SMTP options in the fragment identifier
> would mean that every receiver would have to implement
> them all.

Yes, I agree. But why should that be a problem? The only difference 
between the SMPTE timestamp formats is their temporal resolution for the 
frames. Therefore, all the server has to know is what scheme has what 
temporal resolution. The server implements one function to parse a smpte 
with a framerate parameter
[ala: "double parse_smpte(const char *str, double framerate)"] and when 
parsing the time schemes it checks the scheme and calls the function 
with the correct framerate [ala:

   if (strncmp(s, "smpte-24", i) == 0) {
     return parse_smpte(s+i+1, 24.0);
   } else if (strncmp(s, "smpte-24-drop", i) == 0) {
     return parse_smpte(s+i+1, 23.976);
   } else if (strncmp(s, "smpte-25", i) == 0) {
     return parse_smpte(s+i+1, 25.0);
   } else if (strncmp(s, "smpte-30", i) == 0) {
     return parse_smpte(s+i+1, 30.0);
   } else if (strncmp(s, "smpte-30-drop", i) == 0) {
     return parse_smpte(s+i+1, 29.97);
   } else if (strncmp(s, "smpte-50", i) == 0) {
     return parse_smpte(s+i+1, 50.0);
   } else if (strncmp(s, "smpte-60", i) == 0) {
     return parse_smpte(s+i+1, 60.0);
   } else if (strncmp(s, "smpte-60-drop", i) == 0) {
     return parse_smpte(s+i+1, 59.94);
   }
]
I don't think that this is asking for much from a server.

Again, I'd like to point out the similarity to the mime types: the more 
time schemes get accepted as standards, the more get supported by the 
servers. At first, one cannot expect all installations of servers to 
support all new mime types that come out. If a server doesn't support 
one that is being asked for, it returns an error and the client has to 
deal with it.


> We've established that whether or not a URI interpreter
> must interpret the time fragment locally or can send
> it to the server for interpretation will depend not
> only on the scheme, but also on the implementation of
> the scheme.
> 
> So putting in all of these SMTPE options puts a
> large burden on the implementations of URI interpreters
> and RTSP servers.

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 agree, at this stage, we cannot expect all servers to implement the 
temporal URI fragments. That's why I've put this suggestion into a 
different I-D to be used as a guide for technologies that want to 
provide this kind of addressing (such as MPEG-21 and our ANNODEX). This 
should help in getting consistent and interoperable temporal URI 
fragment usage instead of having many different and non-interoperable 
schemes. Once this temporal addressing scheme has established itself as 
the most useful way of addressing temporal resources, we can pursue the 
I-D (or a further worked out version of it) to a standards level.


>>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.
> 
> 
> This seems like really fragile design. I don't understand
> the use case for all of this 'time addressing' flexibility.
> What is the roll-out strategy for a new scheme?

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.

Regards,

Silvia.

Received on Thursday, 19 June 2003 02:53:58 UTC