Re: [MMUSIC] On RFC2326-biz

[Magnus Westerlund <[e-mail]>]

Hi Julius,

Dropping AVTCORE WG as they are not the relevant WG for this.

I am just back from a quite long parental leave. I have not yet anywhere
near to catch up on my email. Thus, I have not read more than some few
of your emails.

First of all, I see just from the volume that you appreciate how broken
the specification text of RFC 2326 is. That is why we started back in
2003 to produce an updated version. That work has finally in principal
concluded by the approval for publication of
draft-ietf-mmusic-rfc2326bis. The only thing preventing this document
from being published as an RFC is a missing normative reference.

Thus, we are currently in a state where it is difficult to make any
significant changes to the text. Wording corrections would still be
possible to fix. Also if you find anything that is so significant that
it must be corrected then we

Filing Errata on RFC 2326 is also not particular useful.

Having said that I will attempt to answer your issue below.


On 2015-01-08 19:36, Julius Friedman wrote:
> Reading further into the new draft I had some more feedback and 
> questions which I feel should be addressed.
> 
> I see that the re-transmission text has been moved elsewhere and
> that various nomenclature regarding 're-transmission' has been either
> removed or it's location and context has changed to totally oppose
> the previous concepts put forth... It seems that re-transmission is
> now only acceptable under UDP which the standard goes to remove
> support for?

Yes, that is a fair summary. And this is well motivated.

> 
> What about TCP? How should a RTSP 2 system deal with legacy RTSP 1 
> connection with that regard? I think there are several other places
> this mistake was made also.

This was not a mistake. The reason is that in RTSP 2.0 the RTSP client
is not to retransmit any RTSP requests. It relies on TCP for the
requests to be delivered to the next hop RTSP agent. TCP will perform
any necessary retransmission. This way the receiving agent will not be
forced to deal with multiple duplicated of requests.

This is of course not possible if one would use UDP. However, due to
lack of interest in UDP transport of RTSP messages this has not be
specified for RTSP 2.0.

When it comes to a RTSP 2.0 agents handling of RTSP 1.0 messages, that
have to be implemented as best can according to RFC 2326. This will mean
duplication handling.

The main point is that the messages are clearly indicating RTSP version,
and thus an RTSP 2.0 message and its protocol interactions can be held
to the tighter and more well defined behaviour of the new specification.
It is difficult to define how to correctly handle something that is
underspecified.


Looking at the below comments, I think you misinterpreted the reason for
Appendix G. It is not to provide anything that one can implement a
working and interoperable solution from this section. It is intended as
a starting point for someone that needs to write a specification for
unreliable transport of RTSP messages.

One thing I do need to remark on. The registration of the RTSPU URI
scheme. This does not fully belong here, however it is included to clean
up the paper-trail for the RTSP URIs. Better to have a proper
registration, if only to make it clear that it is only defined in RFC 2326.

Cheers


Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------