Change:
The second paragraph of section 3.6.1 seems odd when talking about creating answers, and downright incorrect when talking about offers. Minimally, it needs text to explain why x=0/y=0 would ever make more sense than using "a=sendonly/recvonly/inactive."
There was a clear rationale for why we did this, as I remember having this exact conversation before, but I need to go dig it up.
NAME -- >There was a clear rationale for why we did this, as I remember having this exact conversation before, but I need to go dig it up. Ideally, this rationale would be added to the document once you find it.
Sounds like a good idea.
I was able to find it - the concern was that if you offered a=recvonly, you could then potentially change that to a=sendrecv via transceiver.setDirection, so a=imageattr of [0, 0] provided a way to prevent any video from being sent without additional complexity. URL
I'm coming around to Adam's viewpoint on this one - not sure we should be inventing a new syntax for saying 'don't send me this video stream'.
Section 3.6.1 describes mandatory constraints applied to an incoming track resulting in a new offer-answer exchange. Since this is "action at a distance" (modify the track and the PeerConnection emits a negotiation-needed), I think this needs to be synced with the webrtc-1.0 API spec, and possibly even media-capture. Also, what's the state of the track between the changing of constraints at the receiver and the renegotiation? It seems to me that the track should be scaled at the receiver to fit the agreed-upon constraints.
OK, agreed we have moved away from this sort of approach. I guess we could add a new API to RtpReceiver if we decide we need this sort of functionality; we can either spec said API here in JSEP for future implementation, or drop discussion of it altogether. NAME wdyt?
Dropping discussion seems like the simplest approach; that will mean that the receiver hands whatever comes to it into the track, and the track processes it like it processes any other source. Simple is good.
See PR

Discussion:
Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard <del> limits on what its video decoder can process, or it may wish to constrain what it receives due to application preferences, e.g. a specific size for the window in which the video will be displayed. </del> <ins> limits on what its video decoder can process, or it may have some maximum set by policy. </ins> Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP

3.6.1. <del> In order to determine the limits on what video resolution a receiver wants to receive, it will intersect its decoder hard limits with any mandatory constraints that have been applied to the associated MediaStreamTrack.  If the decoder limits are unknown, e.g. when using a software decoder, the mandatory constraints are used directly.  For the answerer, these mandatory constraints can be applied to the remote MediaStreamTracks that are created by a setRemoteDescription call, and will affect the output of the ensuing createAnswer call. Any constraints set after setLocalDescription is used to set the answer will result in a new offer-answer exchange.  For the offerer, because it does not know about any remote MediaStreamTracks until it receives the answer, the offer can only reflect decoder hard limits. If the offerer wishes to set mandatory constraints on video resolution, it must do so after receiving the answer, and the result will be a new offer-answer to communicate them. If there are no known decoder limits or mandatory constraints, the "a=imageattr" attribute SHOULD be omitted. </del> <ins> The receiver will first intersect any known local limits (e.g., hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. </ins> Otherwise, an "a=imageattr" attribute is created with "recv" <del> direction, and the resulting resolution space formed by intersecting the decoder limits and constraints is used to specify its minimum and </del> <ins> direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and </ins> maximum x= and y= values.  If the intersection is the null set, i.e., <del> there are no resolutions that are permitted by both the decoder and the mandatory constraints, this MUST be represented by x=0 and y=0 values. </del> <ins> the degenerate case of no permitted resolutions, this MUST be represented by x=0 and y=0 values. </ins> The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to

The "a=imageattr" field is payload type specific.  When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. <del> However, when the supported video codecs have differing capabilities, </del> <ins> However, when the supported video codecs have different limitations, </ins> specific "a=imageattr" attributes MUST be inserted for each payload type. As an example, consider a system with a multiformat video decoder, <del> which is capable of decoding any resolution from 48x48 to 720p, and where the application has constrained the received track to at most 360p.  In this case, the implementation would generate this attribute: </del> <ins> which is capable of decoding any resolution from 48x48 to 720p, In this case, the implementation would generate this attribute: </ins> <del> a=imageattr:* recv [x=[48:640],y=[48:360],q=1.0] </del> <ins> a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] </ins> This declaration indicates that the receiver is capable of decoding <del> any image resolution from 48x48 up to 640x360 pixels. </del> <ins> any image resolution from 48x48 up to 1280x720 pixels. </ins> 3.6.2.