Re: [AVTCORE] Errata 4192 RFC 3550

[Julius Friedman <[e-mail]>]

How can the items be excellent for a draft but not consideration for
errata?

After all I have proven transit times account for the data I am proposing
should be included, why cute shortcuts were taken to allow a calculation
which is much more accurate and straightforward otherwise.

Transit and jitter already account for the data in question as I have also
shown.

Since no breaking change occurs I believe that errata is the best way to
sort this initial problem out.

To reject it at this point is ignorant based on the fact so many other
edits are being looked at for rtp.

The padding issues is important but not as important as rtp has worked for
so long already.

The draft I will write will address this but should also cite the reasons
why it was needed to draft a newer version.

In that version I am going to regard this as an error and indicate the
basic mathematical principals I have cited here as well as the error in
logic in calculating payload data rate without the header and padding but
including those values in jitter and transit calculations which also can
effect rtcp.

I will also address the fact that video support was eliminated for no
apparent reason and never updated to include raw support.

Those are two items which need to be addressed (as well as the other edits)
in both errata and the new draft.

I am also changing how media clockrate is tied to calculations for jitter
and transit because of the issues with timestamps being the same when
multiple packets have the same timestamp in a frame among other issues
cited and not.

Padding location and content will also be addressed for security and
delivery protection as well as easier parsing.

I am also sure others have a few things to add to this as well (multi
pathing etc) which should also be addressed in the new draft.

There is a lot of things which can be improved but since that is outside
the scope of the proposed errata I need to address that first.

There is no protocol change for the proposed changes though (senders octet
count and raw video support) and the other edits are similar to reduce
ambiguity so unless it can be shown specifically why this is rejected I am
insisting that it be included with the 'final edits' to the rtp spec
already proposed.

I will begin work on the draft for version 3 regardless.

There is a lot of content which needs to be included for the smaller
existing standards which popped up e.g. rfc4751, Rtsp, feedback inter alia.

Since that will likely take time I highly suggest we correctly revise 3550
appropriately.

At this point we have 1889, 3551, 355x its already a nightmare researching
rtp and this new draft needs to fix that rather than repeat it and to make
a draft for this change alone when other changes are also being made is not
only ineffective its enneficient and displays instability in the standard.
On Dec 11, 2014 11:54 AM, "Dale R. Worley" <[e-mail]> wrote:

> Julius Friedman <[e-mail]> writes:
> > However,  before beginning I would like there to be an acknowledgement of
> > the given errata so it can be justified that time be spent working on the
> > draft.
>
> You've already been told that the erratum will be rejected, since the
> RFC does, in fact, correctly describe what the working group intended
> for it to describe.
>
> You believe that the information the protocol carries is not the
> information that it *should* carry.  That is a complex technical
> judgement that can only be made by the working group as a whole.  The
> way to get the working group to consider the question is to write an
> Internet-Draft and then raise the question on the appropriate working
> group mailing list.
>
> > Even if its held for update, (which it seems there are already at least
> one
> > without my additions) it would allow me to address these issues and
> outline
> > both the relationship and determine if a new version be specified in the
> > draft or if just the same version be specified but with changes given or
> to
> > make the draft correct for the initial standard (which would involve
> > keeping track of the entities in question to properly calculate the given
> > terms)of which options is the very least desirable to me.
> >
> > If a new version is specified I even will go as far to acknowledge all
> the
> > back to rtp 1 to ensure that all variations are specified partly because
> I
> > have identified version 0 as potentially another version (4) or
> explicitly
> > marking it as reserved for compatibility with VAT.
> >
> > I will also address that uncompressed video be supported abd pcm be
> > supported at a minimum.
> >
> > I also have changes which can remove dependence on media clock rate which
> > will simplify overall general calculations for jitter and the like, since
> > again they would be know or determinate and also incorrect which
> shouldn't
> > make calculations invalid.
> >
> > Hopefully you and everyone else sees that I have a lot of considerations
> /
> > ideas and that I don't want to flood the working group with such problems
> > if they can be avoided however with web rtc becoming mainstream I believe
> > we need to address these issues today rather than tomorrow and I will do
> > whatever work is necessary to ensure the standards are correct and
> > encompass the best possible principles of engineering possible but I need
> > to know that the work is both utilized and understood otherwise it will
> be
> > for nothing.
> >
> > Hopefully it's not too much to ask and thanks again and I appreciate your
> > time and effort in this matter as well as that of the committees.
>
> All of these matters can only be handled by the working group as a
> whole.  They are excellent items to address in an Internet-Draft.
>
> Dale
>