Re: [payload] New version of draft-ietf-payload-vp8

[Harald Alvestrand <[e-mail]>]

On 09/10/2015 03:28 AM, Colin Perkins wrote:
>> On 9 Sep 2015, at 23:12, Ben Campbell <[e-mail]> wrote:
>>
>> On 9 Sep 2015, at 16:01, Henrik Lundin wrote:
>>
>>> We have made no technical changes to the document, but have added a number of grammar updates and clarifications. Some of the important clarifications are as follows:
>> Payload participants: Please note that there are in fact changes to 2119 language in this version. I won't quibble about whether or not those count as "technical" changes, but please take a moment to review them. If people object to any of them please say so asap , as this draft will likely be on the agenda for the IESG telechat next week.
> The new text about the Payload Type in Section 4.1 says:
>
>   Payload type (PT):  In line with the policy in Section 3 of
>      [RFC3551], applications using the VP8 RTP payload profile MUST
>      assign a dynamic payload type number to be used in each RTP
>      session and provide a mechanism to indicate the mapping.  See
>      Section 6.2 for the mechanism to be used with the Session
>      Description Protocol (SDP) [RFC4566].
>
> This would be okay, except that RTP profiles that don’t derive from RFC 3551 could be defined. A better wording might be:
>
>   Payload Type (PT): The assignment of an RTP payload type for this
>   packet format is outside the scope of this document and will not be
>   specified here.  It is expected that the RTP profile for a particular
>   class of applications will assign a payload type for this encoding,
>   or if that is not done, then a payload type in the dynamic range
>   SHALL be chosen by means of an out-of-band signaling protocol. See
>   Section 6.2 for the mechanism to be used with the Session Description
>   Protocol (SDP) [RFC4566].
>
>
> In Section 4.2, rather than add a note that “this X bit is not to be confused with the X bit in the RTP header”, would it not make sense to rename this X bit?

We considered this option, but decided that having a large existing body
of documentation outside of the IETF that refers to the "X bit" and
having a payload type registration that called it something else, it ws
better to keep the name and just make a note that it's different.

>  Similarly for the M bit in the extension data fields, and the P bit in the payload header (which isn’t mentioned). Or, at least, annotate each mention of these fields to say which X, M, or P bit it required (e.g., “the P bit in the payload header” or “the P bit in the RTP header” rather than “the P bit”).

This can be done, and probably should be done for any reference that
occurs outside of the section describing the VP8 payload descriptor
(section 4.2) - I couldn't find any such references.

There is no P bit in the VP8 payload descriptor, but there is one in the
VP8 payload header, which is why we missed warning about the name
collision there. It's never referred to in text.


>
> Colin
>
>
>
>
>
>
>


-- 
Surveillance is pervasive. Go Dark.