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

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 May 2014 11:21:15 -0400

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/payload
>
>
> -- 
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

-- 
Surveillance is pervasive. Go Dark.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 May 2014 09:06:56 +0200

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:
> 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.
> 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
>
>
>>> 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.
>>
>> My biggest worry with this particular proposal is that it modifies 
>> the way a=fmtp is specified.
>>
>> This specification proposes to add new parameters into a=fmtp that 
>> are applicable to any payload. This seems like a doubtful 
>> architectural decision.
>> 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.
>>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 27 May 2014 11:14:33 +0300

Hi,

I sent an email to the list asking for feedback on the maximum receive
resolution.

Regardless I will start a WGLC next week and have this issue as one that
need to be concluded ASAP

Roni Even

Payload co-chair

From: payload [mailto:[email-masked]] On Behalf Of Harald
Alvestrand
Sent: 27 May, 2014 10:07 AM
To: [email-masked]
Subject: [payload] Request to Last Call draft-ietf-vp8-payload

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.

             Harald

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.

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

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.

 
   ......

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.

 

URL:
http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-r
esolution-00.txt
Htmlized:
http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution
-00

 

Thanks

Suhas Nandakumar