Re: temporal URI fragments

At 02:54 AM 2003-06-19, Silvia.Pfeiffer@csiro.au wrote:
>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.

In principle, what you want is the right thing to do.  The definition of 
#fragment in the generic semantics should define the order of application 
of this information relative to
other _transformation_ steps in the recovery of the resource [-slice or 
-fragment] but in
a way which is orthogonal, purely agnostic, concerning order relative to 
_transportation_
steps in the process.  Passing of data between network nodes or control 
between actors is
not something that should be visible in the definition of "when to apply 
the #fragment
to the elaboration of the citation."  In principle.

On the other hand, getting clients to actually forward the #fragment, once 
they have the
permission, is something that may have a high quantum barrier associated 
with it.

What can be done with SIP in this regard?

Is there a RTCP?  Could it be used?

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

The need to express a stopTime as well as a startTime in the media object 
[slice]
is one that is obvious already at this time.  I do not yet understand that
the current candidate syntax from CSIRO would afford this functionality.

Alternate syntax with more capability would be to use XPointer syntax (which
will be showing up in #fragments pertaining to resources whose recovery yields
an XML document as a representation) to reference a virtual smil:ref element
and use the slicing capability as for that element type.  In other words, take
smil:ref, map it to XQuery/XPath, and embed in #fragment using the conventions
for using XPointer in #fragment.

The object class that smil:ref provides syntax for has all the capability that
we seek for defining a time-slice as a derived object from an arbitrary 
temporal-media object (including an open-ended stream).

There may well be a well-annealed concept set for what you are trying to do
available from the HyTime community.  I am only starting from SMIL because
I have some familiarity with it.

Al

>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 Wednesday, 25 June 2003 11:10:59 UTC