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

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