- From: Bill Simpson-Young <bill@syd.dit.csiro.au>
- Date: Tue, 15 Jul 1997 13:44:24 +1000
- To: Rob Lanphier <robla@prognet.com>
- cc: www-talk@w3.org, uri@bunyip.com, confctrl@isi.edu
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:56 UTC