Re: [AVTCORE] On RFC2326

[Julius Friedman <[e-mail]>]

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) <
[e-mail]> 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:[e-mail]] *On Behalf Of *Julius Friedman
> *Sent:* Sonntag, 18. Januar 2015 20:34
> *To:* [e-mail]; [e-mail]
> *Subject:* [AVTCORE] On RFC2326
>
>
>
> 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
>
>