Original text:
information.  However, SDP allows many types of lines, not all of which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct <del> according its defining ABNF, check that it conforms to RFC4566 and </del>  RFC3264 semantics, and then either parse and store or discard the <del> provided value, as described below.  A partial list of ABNF definitions for SDP attributes can found in: </del>  <del> [TODO: ensure that every line is listed below.] If the line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description. This ensures that implementations do not accidentally misinterpret ambiguous SDP. </del>  5.7.1. same type (typically "a=") can occur in any order, and their ordering is not meaningful. <del> For non-attribute (non-"a=") lines, their sequencing, syntax, and semantics, are checked, as mentioned above.  The following lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. </del>  The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to not used by this specification; they MUST be checked for syntax but their values are not used. <del> The remaining lines are processed as follows: </del>  The "v=" line MUST have a version of 0, as specified in RFC4566, Section 5.1. The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored. <del> Specific processing MUST be applied for the following session-level attribute ("a=") lines: </del>  Any "a=group" lines are parsed as specified in RFC5888, Section 5, and the group's semantics and mids are stored. in RFC5245, Section 15.5, and the set of specified options is stored.  Any "a=fingerprint" lines are parsed as specified in RFC4572, Section 5, and the set of fingerprint and algorithm values is stored. specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored. <del> Any "a=candidate" attributes MUST be parsed as specified in RFC5245, Section 4.3, and their values stored. Any "a=remote-candidates" attributes MUST be parsed as specified in RFC5245, Section 4.3, but their values are ignored. If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. </del> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Reviewer comments:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)

Revised text:
information.  However, SDP allows many types of lines, not all of which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct  <ins> according to its defining ABNF, check that it conforms to RFC4566 and </ins> RFC3264 semantics, and then either parse and store or discard the  <ins> provided value, as described below. </ins>  <ins> If any line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description, even if the value is to be discarded.  This ensures that implementations do not accidentally misinterpret ambiguous SDP. </ins> 5.7.1. same type (typically "a=") can occur in any order, and their ordering is not meaningful.  <ins> The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. </ins> The "c=" line MUST be checked for syntax but its value is not used.  This supersedes the guidance in RFC5245, Section 6.1, to not used by this specification; they MUST be checked for syntax but their values are not used.  <ins> The remaining non-attribute lines are processed as follows: </ins> The "v=" line MUST have a version of 0, as specified in RFC4566, Section 5.1. The "b=" line, if present, MUST be parsed as specified in RFC4566, Section 5.8, and the bwtype and bandwidth values stored.  <ins> Finally, the attribute lines are processed.  Specific processing MUST be applied for the following session-level attribute ("a=") lines: </ins> Any "a=group" lines are parsed as specified in RFC5888, Section 5, and the group's semantics and mids are stored. in RFC5245, Section 15.5, and the set of specified options is stored. <ins> Any "a=candidate" attributes MUST be parsed as specified in RFC5245, Section 15.1, and their values stored. Any "a=remote-candidates" attributes MUST be parsed as specified in RFC5245, Section 15.2, but their values are ignored. If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. </ins> Any "a=fingerprint" lines are parsed as specified in RFC4572, Section 5, and the set of fingerprint and algorithm values is stored. specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored.  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.