Re: Format of RTSP URLs

Rob,

> 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 

<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

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.


Bill

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