Change:
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.

Discussion:
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