Original text:
This specification prescribes more specific behavior.  When a sender of a given MediaStreamTrack, which is producing video of a certain <del> resolution, receives an "a=imageattr recv" attribute, it MUST first check to see if the original resolution meets the criteria specified in the attribute, and transmit it untouched if so.  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. If the original resolution is too large for the attribute criteria, </del>  the sender SHOULD apply downscaling to the output of the <del> MediaStreamTrack in order to satisfy the criteria. If the receiver requires a minimum resolution which is greater than the native resolution of the video, upscaling is needed, but this may not be appropriate in all cases.  To address this concern, the application can set an upscaling policy for each sent track.  For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution. Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD NOT upscale in other cases, even if the policy permits it. </del>  If there is no appropriate and permitted scaling mechanism that <del> allows the received criteria to be satisfied, the sender MUST NOT </del>  transmit the track. In the special case of receiving a maximum resolution of [0, 0], as setRemoteDescription, meaning the PeerConnection is in the "remote- pranswer" or "stable" states, an offer is generated based on the negotiated session descriptions by following the steps mentioned for <del> the "local-offer" state above, along with these exceptions: [OPEN ISSUE: should this be permitted in the remote-pranswer state? https://github.com/rtcweb-wg/jsep/issues/143] </del>  If a m= section exists in the current local description, but does not have an associated local MediaStreamTrack (possibly because

Reviewer comments:
Discusses multiple imageattr; use of different codecs; no aspect ratio handling; preserve aspect ratio when scaling
LGTM
LGTM

Revised text:
This specification prescribes more specific behavior.  When a sender of a given MediaStreamTrack, which is producing video of a certain  <ins> resolution, receives an "a=imageattr recv" attribute, it MUST check to see if the original resolution meets the size criteria specified in the attribute, and adapt the resolution accordingly by scaling (if appropriate).  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. For an "a=imageattr recv" attribute, only size limits are considered. Any other values, e.g. aspect ratio, MUST be ignored. When communicating with a non-JSEP endpoint, multiple relevant "a=imageattr recv" attributes may be received.  If this occurs, attributes other than the one with the highest "q=" value MUST be ignored. If an "a=imageattr recv" attribute references a different video codec than what has been selected for the MediaStreamTrack, it MUST be ignored. If the original resolution matches the size limits in the attribute, the track MUST be transmitted untouched. If the original resolution exceeds the size limits in the attribute, </ins> the sender SHOULD apply downscaling to the output of the  <ins> MediaStreamTrack in order to satisfy the limits.  Downscaling MUST NOT change the track aspect ratio. If the original resolution is less than the size limits in the attribute, upscaling is needed, but this may not be appropriate in all cases.  To address this concern, the application can set an upscaling policy for each sent track.  For this case, if upscaling is permitted by policy, the sender SHOULD apply upscaling in order to provide the desired resolution.  Otherwise, the sender MUST NOT apply upscaling.  The sender SHOULD NOT upscale in other cases, even if the policy permits it.  Upscaling MUST NOT change the track aspect ratio. </ins> If there is no appropriate and permitted scaling mechanism that  <ins> allows the received size limits to be satisfied, the sender MUST NOT </ins> transmit the track. In the special case of receiving a maximum resolution of [0, 0], as setRemoteDescription, meaning the PeerConnection is in the "remote- pranswer" or "stable" states, an offer is generated based on the negotiated session descriptions by following the steps mentioned for  <ins> the "local-offer" state above, along with these exceptions: </ins> If a m= section exists in the current local description, but does not have an associated local MediaStreamTrack (possibly because