W3C home > Mailing lists > Public > www-talk@w3.org > July to August 1997

Re: Format of RTSP URLs

From: Bill Simpson-Young <bill@syd.dit.csiro.au>
Date: Tue, 15 Jul 1997 13:44:24 +1000
Message-Id: <199707150344.NAA17324@alba.syd.dit.CSIRO.AU>
To: Rob Lanphier <robla@prognet.com>
cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu

> A promenent proposal for achieving this is as follows:
> Full Container file:
> rtsp://foo.com/example.mov

Ideally, people won't do this but would do rtsp://foo.com/example and 
leave the type up to content negotiation.

> Individual Track within container file:
> rtsp://foo.com/example.mov?track=1
> (the "track=1" portion is file format specific, the "?" is the consistant
> part).

If format-specific info is to be included in a specific RTSP URL, then it 
makes sense to allow an HTTP-style query part for the specification of 
this but the internal syntax of that part should be outside the scope of 
the scheme.  However, I think there is a need for the standardisation of 
some RTSP scheme- dependent semantics for commonly-used properties so that 
it is rarely necessary to resort to format-dependent references.  Eg in 
this case, one should probably use something like "track=audio1" (but this 
wouldn't be in the query part of the URL - see below).

> ...
> The URL scheme, taken from Roy Fielding's draft on the subject
> (draft-fielding-url-syntax-05.txt) is something we'll have to consider very
> seriously in all of this.  The URL syntax there is:
> <scheme>://<site>/<path>?<query>#<fragmentid>
> The problem with that scheme is that "fragmentid" is really "client-side
> fragment id".  What we really need is a server side fragment id as well.
> <scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>

In RFC 1808, the URL syntax is 


where "params   ::= object parameters (e.g., ";type=a" as in
                       Section 3.2.2 of RFC 1738 [2])."

Why not use params which is intended for this purpose?  I know the 
"params" isn't used in the HTTP scheme but the disadvantages of using ? 
and # are great enough that it's better to use params than stay close to 
the HTTP scheme.

> The point here is to make it as simple as possible for a server to add and
> subtract fragments from the server-side fragment portion.  If this is
> buried in the query, it's very difficult.  If it is clearly delimited and
> hanging off of the end, it's really straightforward.

I agree.

Received on Monday, 14 July 1997 23:44:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:22 UTC