Draft: draft-ietf-rtcweb-jsep

Commentary: Still LGTM 
 we have consensus on this from the editor team , but please comment here if you see anything else and I 'll take a look . 
 Thanks , I think it looks good in general . Regarding the " par " question raised the current text promotes some picture over correct picture aspect ratio . Having a bullet that one selects one that has PAR that the sending side supports to send can result in more optimal choice but also may result in a slight increase in blocked video where a stretched video may be shown instead .
Paragraph (version A):
First, the most suitable "a=imageattr recv" attribute is selected.
This is performed by taking the attribute with the highest "q="
value from the set of attributes that reference the media format
that has been selected for the specified encoding.  If multiple
attributes have the same "q=" value, the one that appears first in
the m= section is used.  Note that while JSEP endpoints will
include at most one "a=imageattr recv" attribute per media format,
JSEP endpoints may receive session descriptions from non-JSEP
endpoints with m= sections that contain multiple such attributes.
Paragraph (version A):
If there is an applicable "a=imageattr recv" attribute for the
encoding, the limits from the attribute are then compared to the
encoder resolution.  Only the specific limits mentioned below are
considered; any other values, such as picture aspect ratio, MUST
be ignored.  When considering a MediaStreamTrack that is producing
rotated video, the unrotated resolution MUST be used for the
checks.  This is required regardless of whether the receiver
supports performing receive-side rotation (e.g., through CVO
TS26.114), as it significantly simplifies the matching logic.
Paragraph (version B):
For each encoding being produced by the RtpSender, the set of
"a=imageattr recv" attributes in the corresponding m= section of the
remote description is processed to determine what should be
transmitted.  Only attributes that reference the media format
selected for the encoding are considered; each such attribute is
evaluated individually, starting with the attribute with the highest
"q=" value.  If multiple attributes have the same "q=" value, they
are evaluated in the order they appear in their containing m=
section.  Note that while JSEP endpoints will include at most one
"a=imageattr recv" attribute per media format, JSEP endpoints may
receive session descriptions from non-JSEP endpoints with m= sections
that contain multiple such attributes.
Paragraph (version B):
For each "a=imageattr recv" attribute, the following rules are
applied.  If this processing is successful, the encoding is
transmitted accordingly, and no further attributes are considered for
that encoding.  Otherwise, the next attribute is evaluated, in the
aforementioned order.  If none of the supplied attributes can be
processed successfully, the encoding MUST NOT be transmitted, and an
error SHOULD be raised to the application.
Paragraph (version B):
The limits from the attribute are compared to the encoder
resolution.  Only the specific limits mentioned below are
considered; any other values, such as picture aspect ratio, MUST
be ignored.  When considering a MediaStreamTrack that is producing
rotated video, the unrotated resolution MUST be used for the
checks.  This is required regardless of whether the receiver
supports performing receive-side rotation (e.g., through CVO
TS26.114), as it significantly simplifies the matching logic.
Paragraph (version A):
If the attribute includes a "sar=" (sample aspect ratio) value set
to something other than "1.0", indicating the receiver wants to
receive non-square pixels, this cannot be satisfied and the sender
MUST NOT transmit the encoding.
Paragraph (version B):
If the attribute includes a "sar=" (sample aspect ratio) value set
to something other than "1.0", indicating the receiver wants to
receive non-square pixels, this cannot be satisfied and the
attribute MUST NOT be used.
Paragraph (version A):
If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits, although the downscaling MUST NOT change the
picture aspect ratio of the encoding.  For example, if the encoder
resolution is 1280x720, and the attribute specified a maximum of
640x480, the expected output resolution would be 640x360.  If
downscaling cannot be applied, the encoding MUST NOT be
transmitted, and an error SHOULD be raised to the application.
Paragraph (version A):
If the encoder resolution is less than the minimum size permitted
by the attribute, the encoding MUST NOT be transmitted, and an
error SHOULD be raised to the application; the encoder MUST NOT
apply upscaling.  JSEP implementations SHOULD avoid this situation
by allowing receipt of arbitrarily small resolutions, perhaps via
fallback to a software decoder.
Paragraph (version B):
If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits, although the downscaling MUST NOT change the
picture aspect ratio of the encoding.  For example, if the encoder
resolution is 1280x720, and the attribute specified a maximum of
640x480, the expected output resolution would be 640x360.  If
downscaling cannot be applied, the attribute MUST NOT be used.
Paragraph (version B):
If the encoder resolution is less than the minimum size permitted
by the attribute, the attribute MUST NOT be used; the encoder MUST
NOT apply upscaling.  JSEP implementations SHOULD avoid this
situation by allowing receipt of arbitrarily small resolutions,
perhaps via fallback to a software decoder.
Paragraph (version B):
If the encoder resolution is within the maximum and minimum sizes,
no action is needed.