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

RE: temporal URI fragments

From: Larry Masinter <LMM@acm.org>
Date: Wed, 11 Jun 2003 23:07:42 -0700
To: <Silvia.Pfeiffer@csiro.au>
Cc: <uri@w3.org>, <Conrad.Parker@csiro.au>
Message-ID: <004b01c330a8$effb7920$6ace8642@MASINTERPAD>

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.

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.

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.

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

It's bad enough that no URI receivers will understand
ANY time scheme right now (and will drop it on the floor),
but what's the long-term deployment strategy?

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

Perhaps you can address the upgrade/deployment strategy, then?

Received on Thursday, 12 June 2003 02:09:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:06 UTC