[payload] Request to Last Call draft-ietf-vp8-payload

[Harald Alvestrand <[e-mail]>]

Given that another week has gone by with zero feedback on 
draft-nandakumar-payload-sdp-max-video-resolution on this list, I hereby 
ask the chairs to consider an IETF Last Call for draft-ietf-payload-vp8 
without any link to this draft.

The interest shown by the community in pursuing such a linkage is not 
indicative of an IETF consensus for a linkage.

              Harald


On 05/20/2014 05:21 PM, Harald Alvestrand wrote:
> Just a reminder, since Cullen reminded me that this issue has languished:
>
> I have seen no response to my February 6 message raising specific 
> issues about max-video-resolution (reproduced below).
> I have seen no update to max-video-resolution based on the discussion 
> in London.
> I have seen no action from the chairs to either adopt or reject this 
> work item.
>
> As far as I can tell, nothing is happening.
>
> If there is no interest in pursuing this work, can we declare that it 
> is not an IETF work item and stop blocking other things on it?
>
>                    Harald
>
>
> On 02/06/2014 07:21 PM, Harald Alvestrand wrote:
>> On 02/01/2014 02:51 AM, Suhas Nandakumar wrote:
>>> Hello All
>>>
>>>   Following draft has been submitted to specify payload format 
>>> parameters indicating an end-point's maximum image resolution 
>>> receive capability in SDP. This draft aims at solving the issue with 
>>> specifying such functionality for VP8 and is also applicable to 
>>> other codecs in general.
>>
>> Thank  you for finally posting this to the payload list! (The date of 
>> the draft is Dec 7 - I've been waiting for the proponents to make a 
>> public statement about it).
>>
>> My biggest worry with this particular proposal is that it modifies 
>> the way a=fmtp is specified.
>>
>> As far as I understand, the syntax of a=fmtp has previously been 
>> assumed to be specified completely by the payload specification (viz 
>> the rather non-orthogonal stuff that is in the DTMF payload).
>>
>> This specification proposes to add new parameters into a=fmtp that 
>> are applicable to any payload. This seems like a doubtful 
>> architectural decision.
>> I think it would be cleaner to add a new a= attribute that is 
>> independent of codec (but linked to payload type) containing the 
>> information.
>>
>> I also have a nit with the way offer/answer is specified:
>>
>>                            ..... When the direction is
>>     sendonly, these attributes have no interpretation and MUST be ignored
>>     by the receiving Endpoint, if present.
>>
>>     ......
>>
>>     An SDP Answerer MUST NOT include these parameters in the SDP Answer
>>     unless they are specified in the associated SDP Offer.
>>
>>
>> If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless.
>>
>> My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply.
>>
>> Note: I see absolutely no reason to link this functionality, if 
>> desirable, to the RTP format for VP8. If it needs mandating, it 
>> should be mandated for all video types going forward, including 
>> H.265, and strongly recommended for all video types that have been 
>> standardized in the past.
>>
>> If it doesn't need mandating, it doesn't need mandating for anyone.
>>
>>
>>
>>
>>
>>>
>>>
>>> URL: 
>>> http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt
>>> Htmlized: 
>>> http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00
>>>
>>>
>>> Looking forward for the inputs on how do we take his work ahead.
>>>
>>>
>>> Thanks
>>> Suhas Nandakumar
>>>
>>>
>>> _______________________________________________
>>> payload mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/payload
>>
>>
>> -- 
>> Surveillance is pervasive. Go Dark.
>>
>>
>> _______________________________________________
>> payload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/payload
>
>
> -- 
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload