Subject: [MMUSIC] Transport Header Stipulation

From: Rishi Mathew <[email-masked]>
Date: Tue, 12 Oct 2004 11:29:19 -0700

Magnus/All,

This is regarding the Transport header defined in Chapter 14.43 of the RTSP 
spec. Right now, it says:

    The usage of any parameter that was not defined in RFC 2326 or in an
    extended way requires that request or response contains a Require
    header with the "play.basic" feature tag.

It is claimed that this was done to prevent backwards compatibility 
problems. However, in our field implementation, this parameter has always 
had a different value than what was defined in the original RTSP spec. It 
looks like this:

         Transport: x-real-rdt/udp;client_port=6970;server_port=17738\r\n

This was legal in the original spec. Obviously, any such stipulation is 
going to create more problems than it solves on the field. Our suggestion 
is that you remove this stipulation.

Thanks,
Rishi.

Rishi Mathew
Software Development Engineer
Helix Development Support Group
RealNetworks, Inc.
[email-masked]
206.892.6126
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Oct 2004 11:07:02 +0200

Hi Mathew

See below

Rishi Mathew wrote:

> Magnus/All,
> 
> This is regarding the Transport header defined in Chapter 14.43 of the 
> RTSP spec. Right now, it says:
> 

What I refer to as parameter is the addition of what in the ABNF is 
called parameter, i.e. what comes after the protocol specifier. For 
example a new parameter would be the "new_parm" below:

Transport: x-real-rdt/udp;client_port=6970;server_port=17738; new_parm=XYZ

> problems. However, in our field implementation, this parameter has 
> always had a different value than what was defined in the original RTSP 
> spec. It looks like this:
> 
> going to create more problems than it solves on the field. Our 
> suggestion is that you remove this stipulation.
> 

"x-real-rdt/udp" is protocol specifier. However that you claim that it 
is legal in RFC 2326 is not correct. The ABNF for the transport header 
looks like this:

    Transport           =    "Transport" ":"
                             1\#transport-spec
    transport-spec      =    transport-protocol/profile[/lower-transport]
                             *parameter
    transport-protocol  =    "RTP"
    profile             =    "AVP"
    lower-transport     =    "TCP" | "UDP"

Which means that no extension allowance was made in the ABNF. Thus it is 
unclear that a parser will correctly handle any extension. I do agree 
that the intention was to allow for this. However due to the shortcoming 
of the RFC 2326 it is a dangerous proposition to use extension protocol 
specifiers or parameters. That is the reason the text is present in the 
draft.

If you compare the above ABNF with the new one present in the draft:

Transport       =  "Transport" ":" transport-spec
                       *("," LWS transport-spec)
    transport-spec  =  transport-id *parameter
    transport-id    =  transport-prot "/" profile ["/" lower-transport]
                       ; no LWS is allowed inside transport-id
    transport-prot    =  "RTP" / token
    profile           =  "AVP" / token
    lower-transport   =  "TCP" / "UDP" / token

You see that there now is specified that all these types can be extended.

The draft do also define IANA registries for these points of extension, 
see 20.5.

So I don't think it is appropriate to remove this, as it can't be 
guaranteed that your proprietary extensions would correctly work with 
another implementation following RFC 2326. When clients support the 
updated specification and indicates this correctly, then you can be 
certain that any correct implementation can safely ignore your 
proprietary transport protocol.

So I think I will need to clarify the note to apply to any extensions. I 
also should change the wording to not use the word "require". My 
proposed change is:

"The usage of any parameter or protocol specifier not defined in RFC 
2326 or which is extended, SHALL be indicated by the use of the Require 
header and a feature tag(s) to ensure support by the receiver. This
is to protect against failures with uncertain consequences, as the a 
receiver of a message may do anything between ignoring a parameter, to 
complete refuse the message."

Any Comments?

Cheers

Magnus Westerlund

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