Subject: RE: [MMUSIC] a=control in SDP

From: Ralph Neff <[email-masked]>
Date: Fri, 13 Sep 2002 13:33:20 -0700

Dear Magnus and all,

-- Magnus Westerlund wrote: --
>I guess that the 3GPP Interop your referring to is IMTC's PSS interop. I 
>would be much more pleased of this group if they had the decency to 
>report any found inconsistencies to MMUSIC. I would also like you to 
>inform MMUSIC about your proposal to fix the bugs. I know that I is easy 
>to get involved in details. But to make RTSP a useful protocol in the 
>future a certain level of afterthought must be made when suggesting 
>restrictions and resolutions.
-- End snippet --

As a participant in IMTC PSS-AG, I can comment a bit on this.
You are quite right that PSS-AG (and other interop groups) should
communicate with MMUSIC (and other standards-making groups) when
inconsistencies are revealed in the tests.  We have done this in
the past with 3GPP SA4, and I think we can take this as an invitation
to participate in such discussions in IETF as well.  Such interaction
will benefit everyone involved.  In order to encourage this, we
may want to have a default person to act as an informal liaison
between the groups.

Magnus, I would also like to thank you for your recent input to the
PSS-AG discussion on Redirection.  It was quite helpful to get your
perspective and an update on the new spec.  We may provide some input
on this issue, particularly if we are able to include redirection
in our tests.

Regarding URL resolution and the 'trailing slash' issue.  This did
come up within PSS-AG, but only because some of the tested implementations 
did not seem to be performing URL resolution correctly according
to RFC 2396.  This caused us to examine the issue, and our conclusion
was that if you include the trailing slash in, say, the Content-base URL,
then the URL resolution process (as described in RTSP, referencing
1808/2396) works as expected.  We didn't find any problem that would
require a change to the specs, and so no communication was considered
necessary.  In fact, most of the tested implementations were doing
this already.

(If you don't include the trailing slash, nothing is broken, but your
URL is probably shorter than desired after the resolution process :)

I do appreciate your desire to improve the next generation of the RTSP
specification.  However, Thomas is correct in that backwards compatibility 
should be considered during this process.  If an existing client 
receives SDP containing the new 'a=control:*/', it will not be able to
resolve the URL's correctly.

-Ralph

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Sep 2002 08:52:30 +0200

Hi,

If I understand the comments about this topic correctly the conclusion 
is: Most people find the backwards compatibility issue to big, compared 
to the gain of making something looking nice and consistent.

I can understand this as it is possible to solve the problem in two ways.

1. Use "Content-Base" header with an extra trailing slash. Requires 
server implementations to handle the trailing slash as an aggregated 
control URL.

2. Server alters the SDP so that the actual filename is in the relative 
control URLs.

The important thing about this discussion is that the normal URL 
processing rules from RFC 2396 apply to a=control URLs. The only 
extension from these rules are that a relative URL with only a * is 
equal to the base URL.

Regards

Magnus

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Tom Marshall <[email-masked]>
Date: Sat, 21 Sep 2002 11:01:20 -0700

I think using a "*" as a replacement for content-base is a bad idea.  The
"*" character is a valid pathname character according to [H3.2.1].  Doesn't
this introduce ambiguities in the BNF?

I think it would be much easier to just define Content-Base as either having
or not having a trailing slash, and requiring the client parser to strip or
not strip it from the url when the two parts are concatenated.

-- 
Old timer, n.:
        One who remembers when charity was a virtue and not an organization.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Sep 2002 09:05:27 +0200

Hi Tom,

>this introduce ambiguities in the BNF?
Yes, you are correct that "*" is a valid path name character in generic 
URLs. But for a=control URLs there is a definition in RFC 2326, Appendix 
C that says:

"If this attribute contains only an asterisk (*), then the URL is 
treated as if it were an empty embedded URL, and thus inherits the 
entire base URL."

This additional rule has been in use for many years now. The limitations 
for a URL is very small, in fact only relative URLs which desires to 
replace the last part after a "/" in the base URL with a "*" can't do 
it. And one can in fact get around this by using "./*".

>not strip it from the url when the two parts are concatenated.
I would not like to have such a rule, as this puts restrictions on how 
URLs can be created. The basic rule here is that normal processing rules 
for URLs (RFC 2396) shall be used. Currently we have one special rule 
regarding relative urls with only a "*". This second rule does not 
effect the full freedom of how URL paths may be looking. Having a rule 
saying something about having and not having trailing slashes has bad 
effect on the possible formats of URLs. I think it would create a mess.

I thought my rule that we redefine * from a common path character to 
meaning of base-URL was better with known and controlled implications.

However according to what I see as consensus is that we stick with the 
current rules and don't change anything due to that backwards 
compatibility issue.

Regards

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Mon, 23 Sep 2002 10:05:19 -0700

> it. And one can in fact get around this by using "./*".

Using a "*" a placeholder is not ambiguous.  A single "*" cannot be confused
with an absolute url.  But when you use "*" as a substitution for part of an
absolute url and append an arbitrary path to it, there is ambiguity. 
Consider the following:

Content-Base: rtsp://server.example.com/farm/

...
a=control:*/meeting.avi

With the new proposal, I think this could be parsed as either

rtsp://server.example.com/farm//meeting.avi

or

rtsp://server.example.com/farm/*/meeting.avi

> effect on the possible formats of URLs. I think it would create a mess.

Yes, I think you are correct.  Going back to your original email, you
referenced container files:

> For a container file that has the URL: rtsp://example.com/donald.mp4
> On session level:
> a=control:*
> On media level
> a=control:donald.mp4/trackID=2

I would say that, being a container file, perhaps it should look like a
directory.  Perhaps the url should be "rtsp://example.com/donald.mp4/" and
the control attribute should be "a=control:trackID=2"?

It is helpful for me to think of it in terms of a tar file or a loopback
mount point.  The filename becomes a part of the path when it is served as
an url.  Here is another example:

rtsp://example.com/archives/20020923.tar/commentary/mmusic.avi

20020923.tar would be a file on the server's filesystem, but when used in an
url, it becomes another component of the pathname.

-- 
Corporation, n.: an ingenious device for obtaining individual profit without
individual responsibility.
        -- Ambrose Bierce
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Sep 2002 08:40:31 +0200

Hi Tom,

Yes, you are correct that having * being possible to use anywhere in the 
URL creates a problem. If we would be going forward with my proposal it 
would perhaps be good to restrict "*"=base-URL to only work in the 
beginning of URLs. However as people are concerned that any of these 
changes has backwards compatibility problems the proposal is killed for 
now.

I do think having this whole discussion has been good at clarifying 
things about the RTSP url i a=control.

Regards

Magnus

-- 

Magnus Westerlund