Subject: [MMUSIC] On RFC2326

From: Julius Friedman <[email-masked]>
Date: Sun, 18 Jan 2015 14:33:30 -0500

Unfortunately I have more information which I have found to be
contradictory and possibly erratum.

Quite Succinctly,

"

10.7 <https://tools.ietf.org/html/rfc2326#section-10.7> TEARDOWN

   The TEARDOWN request stops the stream delivery for the given URI,
   freeing the resources associated with it. If the URI is the
   presentation URI for this presentation, any RTSP session identifier
   associated with the session is no longer valid. Unless all transport
   parameters are defined by the session description, a SETUP request
   has to be issued before the session can be played again.

"

However earlier in the document.

"

10.4 <https://tools.ietf.org/html/rfc2326#section-10.4> SETUP

....

The server generates session identifiers in response to SETUP
   requests. If a SETUP request to a server includes a session
   identifier, the server MUST bundle this setup request into the

   existing session or return error "459 Aggregate Operation Not
   Allowed" (see Section 11.3.10
<https://tools.ietf.org/html/rfc2326#section-11.3.10>).

"

If a users obtains a session Id related to an aggregate controlled
media and only one of the sub sessions received a "TEARDOWN" then the
RFC makes the server incorrectly remove the SessionId which is still
being used for the other sub-sessions.

The draft doesn't do any better in making this clearer IMHO.

Please advise,

I will also probably be filling more errata unless I can be directed
on how to properly convey the information without filling it.

I hope all else is well as I STILL haven't heard back from anyone
regarding both the clarifications I made. (Which is pretty ridiculous,
it's been over 2 years I have been asking these questions almost)

-Julius

---

From: Julius Friedman <[email-masked]>
Date: Tue, 20 Jan 2015 17:36:39 -0500

Thanks, at least I know that my emails are being receiving and that I am
being mostly ignored for whatever reason.

I appreciate the little time the committee has given me thus far and all I
can really say is 'Thank you'

It's a shame that one can so quickly be turned away from something which
they have been in support of for so long and in my opinion an unfortunate
reflection of the times and how this committee has failed to adapt to such.

It should be easy to communicate to the committee and if this list is a
hassle for those members than an alternate form of `communicae` should be
presented such that EVERYONE (who's RIGHT) it is to both utilize and
provide important input on these standards in a way that allows for such
dialog to be opened, addressed and resolved in a more appealing and
beneficial manner.

I don't wish to play tug of war for attention or confer with individuals
who who wish to hide behind opinions and intentions in a subject where such
things have no purpose other than fragmentation of the standards which are
developed to prevent such.

Furthermore with all due respect it is the RIGHT of this committee to do so
especially when their documents define what is 'correct' and 'incorrect'
AND more so when it provides appendixes which are incorrect or interpreted
to be so.

Instead what you have displayed via your responses and lack thereof is just
the opposite of that which you ask from others who communicate with you,
why would I even waste any more time? I can easily write my own standard
and submit it for review when I see fit.

Quite frankly I believe that the `owness` is on the committee and it's
members to be able to address these issues based on the fact they they
voted and approved these documents which convey public information to
parties who utilize and RELY upon them to communicate in heterogeneous
networks where their conformance can effect application security and
implementation compatibility;especially in such cases where applications
claim conformance to such standards.

I did my homework, I made my inquiries and I was ignored.

When I was wrong about terminology or reference I deferred and did not
respond in any way other than to further explain the core issue with a
succinct explanation, which was only met with hostility for what I can only
assume is because it's apparent that this committee has lost it's ability
to address issues and take responsibility when required to do so.

I used to believe that membership existed to provide the most beneficial
technology to everyone and anyone, instead I can see that it's now a
cesspool which is used to create standards and update existing standards
where it is beneficial for whatever corporate interest require the control
of such information.

Your responses which tangent into response furthermore the lack of ability
to understand both the nature of the errors and their proposed resolution
also indicates this; quite simply you would rather argue about terminology
and formatting or punctuation and dismiss ideas you can't easily understand.

If your the world's leading experts then I suppose that makes me the
world's leading expertise seeker among quite a few other things until this
point...

If I can be of any further `service` to the committee or respond in any way
which can actually be beneficial to both the proper development of internet
standards as they are required then please let me know, otherwise `ceterus
paribus` you will probably only hear from me when I file erratum for that
which I am ignored for including but not limited to existing issues which
have been reported numerous times.

I am only doing my duty when filling such erratum and if the committee
would respond and settle any debate intelligently and accurately without
deferring to ambiguous possibilities about courses of action then one would
oblige to such. Quite simply I provided everything I needed to and I even
went further to address why certain 'new' standards were required when
their functionality was encompassed via possibly an implementation of
alternate interpretation of existing mechanisms in existing standards.

In fact, the only ones demanding anything are certain members here:

"Follow this process", "Don't address this", "This is why this IS needed"

When in almost all of the cases including my favorite "Rtp has worked for
the last 20 years" crap... it just goes to show you that you have become
unable to function in the most simply capacity.

What I am to come away with from this experience is simply that the
committee doesn't handle questions very well and that asking questions is
trolling and that regardless if your are right or not the committee will
ignore you and move to mask your input as spam.

I wish I would have been able to start over and write in differently but
then I remember, I tried this for months and I am only human and I have my
own constraints with time and energy I must meet them before helping
everyone else especially when I am met with such resistance for no apparent
reason.

I apologize for anything I may have done and gracefully bow out.

With all due respect,
Julius Richard Friedman

On Mon, Jan 19, 2015 at 3:12 AM, Schwarz, Albrecht (Albrecht) <
[email-masked]> wrote:

>  Don’t waste any time anymore on RFC 2326:
>
>
>
> => IF, THEN argue against 2326bis:
>
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-40
>
> RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326
> <https://tools.ietf.org/html/rfc2326>.
>
>
>
>
>
>
>
> *From:* avt [mailto:[email-masked]] *On Behalf Of *Julius Friedman
> *Sent:* Sonntag, 18. Januar 2015 20:34
> *To:* [email-masked]; [email-masked]
> *Subject:* [AVTCORE] On RFC2326
>
>
>
> 10.4 <https://tools.ietf.org/html/rfc2326#section-10.4> SETUP ....
>
>    Allowed" (see Section 11.3.10 <https://tools.ietf.org/html/rfc2326#section-11.3.10>).
>
> "
>
>
>
> If a users obtains a session Id related to an aggregate controlled media and only one of the sub sessions received a "TEARDOWN" then the RFC makes the server incorrectly remove the SessionId which is still being used for the other sub-sessions.
>
>
>
>
>
> I will also probably be filling more errata unless I can be directed on how to properly convey the information without filling it.
>
>
>
> I hope all else is well as I STILL haven't heard back from anyone regarding both the clarifications I made. (Which is pretty ridiculous, it's been over 2 years I have been asking these questions almost)
>
>
>
> -Julius
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Jan 2015 11:50:22 +0100

Julius,

In attempt to set things straight. There are more than 10 years of
history in attempting to update RTSP. IETF has its processes and rules.
One of these are that RFCs are immutable. We can't go back and edit
them. The Errata process is not really a tool for handling changes. Not
even corrections. They are more along the line of "Please Note" there
are issues here.

The way of fixing things are making new internet drafts. Have them
published to replace the existing RFC.

In this case of RTSP 1.0 that work started back in 2003. A lot of
clarifications and corrections to RFC 2326 was encoded in the internet
drafts. These also went into the implementations. During that process we
realized that the rules for RTSP versions in RFC 2326 forced us to go to
RTSP 2.0. This did cause grief and is major reason why the work failed
to complete in a timely manner in around the 2006-2007 time frame. Since
then work has slowly progressed but on a real background priority. We
are finally at a stage where it is approved. And if wasn't for a
reference it would have been published as new RFC.

Your comments and feedback shows up at a stage where there is little
energy and also significant hurdle to make any changes. Almost all the
people with any interest in RTSP has moved on.

As I said privately I will look through the issues you submitted and
check them against RTSP 2.0. I will provide my view on if there needed
to be addressed or not.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Jan 2015 14:37:52 +0100

> The draft doesn't do any better in making this clearer IMHO.

What I can see
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ in
Section 13.7.1 is clear on this. If you are disagreeing that this issue
is resolved. Please be explicit in what way it isn't resolved.

cheers

Magnus Westerlund