Re: [payload] New Version Notification for draft-nandakumar-payload-sdp-max-video-resolution-00.txt

[Harald Alvestrand <[e-mail]>]

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.