Original text:
described in RFC4566, Section 5.  The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information.  However, SDP allows many types of lines, not all of <del> which are relevant to JSEP applications, and the ones that are not specifically referenced below MAY be ignored.  Implementations MAY also act on such lines, in accordance with the specification that defines them.  For each line, the implementation will first ensure it is syntactically correct according its defining ABNF [TODO: reference], and then either parse the data value to store for later use, or ignore the value and move on.  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.6.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 and syntax are checked, as mentioned above, but the only line whose value MUST be parsed and stored is the "c=" line.  For example, because session- level bandwidth is ambiguous when multiple media streams are present, a "b=" line at session level is not useful and its value SHOULD be ignored.  [OPEN ISSUE: is this WG consensus?  Are there other non-a= lines that we need to do more than just syntactical validation, e.g. v=?] </del>  Specific processing MUST be applied for the following session-level attribute ("a=") lines: Any "a=rtcp-fb" attributes MUST be parsed as specified in RFC4585, Section 4.2., and their values stored. <del> Any "a=rtcp-mux" attribute MUST be parsed as specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. </del>  TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of- candidates bounds, or cannot be applied, processing MUST stop and an error MUST be returned. <del> If the ICE ufrag and password values changed, trigger the ICE Agent to start an ICE restart and begin gathering new candidates, as defined in RFC5245, Section X.Y. If the media section proto value indicates use of RTP: If the RTCP mux parameter is set, discard any RTCP transport, and begin muxing RTCP over the RTP transport, as specified in RFC5761, Section X.Y. [if answer] Set RTP header extension receive state, ensure all are known Set PT demux Set receive codecs, ensure all are known Set up RTX (verify apt) Set local directional state If the media section proto value indicates use of SCTP: Set local SCTP pseudo-port </del>  Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section

Reviewer comments:
NAME NAME PTAL and let me know if you think this is on the right track. If so, I will flesh out in whatever time I have on Sunday.
This seems like it's on the right track. My biggest concern is whether we really want to require people to ignore values which we also prescribe values for. For instance, you say that the impl should discard the c= line, but S 5.2.1 is very prescriptive about the c= line contents. I recognize that valid (non-JSEP) implementations might produce other values for the c= line but I wonder if we really want to ignore them.
What would one do with the c= line? We make our c= lines in a certain way for the benefit of dumb remote endpoints. JSEP endpoints aren't so encumbered.
I guess you would validate that it properly reflected one of the candidates (if any) in the m= section. I'm torn here, because it seems like if we totally ignore these values we contribute to them just getting more and more bogus. But on the other hand, validating them for consistency also seems like a problem.
With that said, Firefox seems to basically ignore these values.
It wouldn't be hard to verify c=; we would have to store the value, and then deal with it during the "Verifying Consistency" section. However this could be a slippery slope; should we validate that t= values are not garbage, etc?
"It wouldn't be hard to verify c=; we would have to store the value, and then deal with it during the "Verifying Consistency" section. However this could be a slippery slope; should we validate that t= values are not garbage, etc?" Fair enough. OTOH there's a hygiene argument about rejecting bogus stuff early so it doesn't get into the ecosystem is not contaminated. Maybe we should say that these lines can be checked for consistency? I don't feel strongly about this.
I am strongly on the side of "be strict in what you accept, or else people will turn your ecosystem into a cesspool", but I have a hard time getting excited about extensively validating stuff that is going to be ignored anyway. Saying that the application MAY do additional consistency checks seems like a reasonable balance; I'll see if I can craft some text around that.
I am currently working on an edit that tries to address the points raised here, look for it in ~30 min.
OK, I took another shot at this. Now, I sort lines into things that JSEP specifically cares about and MUST be acted on, and things that JSEP doesn't say anything about, and implementations MAY act on them or ignore them.
I finished fleshing out the SDP parsing stuff. It definitely could be tightened up with another editorial pass, but I think it mostly defines what needs to happen at the parse stage, and is worth keeping; we can polish it later. The apply-local-description stuff is still quite primitive and we might want to pull it for this rev.
I will be in the office by 8:30 PT tomorrow - ping me and we can figure out how to land this from the current state.
working my way thought the latest ...
Based on the comments right now, I am planning on making the following changes: Specifically mention SDP general rules and specific ABNF in "syntactically correct" section mark session-level b= as open issue clean up "if valid" text clarify a couple places as to whether multiple values are OK (e.g. rtcp-mux) LMK if you disagree or have additional things you want to see.
I suggest that you also put in some sort of general "This is a draft" disclaimer. Other than that, I'm fine with proceeding as you propose. I'll be around for another 30-60 minutes and then out for lunch. Back around 2-2:30ish.
I'm around next two hours then in meeting till late. To me the most important thing is to make this clear we are not picking a few parts of SDP to implement but instead we are doing SDP. So I am nok OK with things like "ignore everything but what is mentioned here". I am OK with the way we use SDP here means that X,Y, are never used. I view what I am saying here matches WG consensus
This doesn't seem philosophically unreasonable, but at this point I suggest we focus on what's actionable. Are there specific things that are still in this PR that you object to? If so, let's call them out and fix them and merge it. In this spirit, you and Justin have my proxy to merge any variant of this PR that you mutually agree upon. I'm happy to review to the extent I am around, but don't not submit b/c of me.
As a check list of things I think we need to mention ... somewhere in this text I think we need to say browser need to support RFC2833 RFC3264 RFC4566 ietf-mmusic-msid ietf-mmusic-sdp-bundle-negotiation RFC5761 RFC3605 ietf-payload-rtp-opus RFC3551 RFC4145 RFC5245 RFC5576 RFC5506 RFC6465 RFC6464 ietf-mmusic-trickle-ice ietf-mmusic-sctp-sdp ietf-rtcweb-data-channel ietf-payload-vp8 ietf-mmusic-sdp-simulcast RFC7022 I've missed a few there (like 264) but I think that is bunch of them
I expect to talk about each of these in detail in the parse/apply sections, but the laundry list already exists in URL
Cullen, regarding "I am nok OK with things like "ignore everything but what is mentioned here". I am OK with the way we use SDP here means that X,Y, are never used": The current text says that this spec defines how JSEP deals with the specific lines X,Y,Z, but implementations MAY process other lines in accordance with their definitions. Does that work for you? Cullen - answering in this comment to see how that works ... The part I am having the problem is is saying "you can ignore anything not mentioned here". I'm not agaoins pointing out specific lines which the SDP spec says are useless in WebRTC context, I just don't want to be redefining SDP here.
OK. Working on editing this all now - expect an update circa 3:00 PM PT
New version of this PR has been pushed that addresses (I believe) all points discussed today.
reading
Overall I think this has uncovered a bunch of stuff that I think we need to discuss in Dallas, so I'd like to find a way to land this, with whatever disclaimers are appropriate. I plan to remove the apply-local stuff before submitting, will work on removing it now.
apply-local stuff gutted
talking to EKR and trying to resolve something
Justin, Cullen and I talked and his principal concern is defaulting to ignoring stuff not listed. I think the way to fix this is to just list all (15 or so) non a= lines and their disposition. i didn't have time here, but PR puts in the framework and then we should be able to resolve these quickly, leaving the controversial ones for IETF. wdyt? See

Revised text:
described in RFC4566, Section 5.  The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information.  However, SDP allows many types of lines, not all of  <ins> which are relevant to JSEP applications.  For each line, the implementation will first ensure it is syntactically correct according its defining ABNF [TODO: reference], check that it conforms to RFC4566 and RFC3264 semantics, and then either parse and store or discard the provided value, as described below.  [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. </ins> 5.6.1. same type (typically "a=") can occur in any order, and their ordering is not meaningful.  <ins> 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. TODO The remaining lines are processed as follows: The "c=" line MUST be parsed and stored. [OPEN ISSUE: For example, because session-level bandwidth is ambiguous when multiple media streams are present, a "b=" line at session level is not useful and its value SHOULD be ignored. [OPEN ISSUE: is this WG consensus?  Are there other non-a= lines that we need to do more than just syntactical validation, e.g. v=?] </ins> Specific processing MUST be applied for the following session-level attribute ("a=") lines: Any "a=rtcp-fb" attributes MUST be parsed as specified in RFC4585, Section 4.2., and their values stored.  <ins> If present, a single "a=rtcp-mux" line MUST be parsed as specified in RFC5761, Section 5.1.1, and its presence or absence flagged and stored. </ins> TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of- candidates bounds, or cannot be applied, processing MUST stop and an error MUST be returned.  <ins> TODO </ins> Finally, if this description is of type "pranswer" or "answer", follow the processing defined in the sec.applying-an-answer section