Re: [rtcweb] SDP lines (JSEP Issue 27)

I think we are just seeing different meanings in the word ignore. I see it as "ignore" would mean the browser did not process or store whatever it found in something that it MUST ignore. It's doing syntax checking on this and then storing it and then passing it back later (presumable unchanged). 

The things we are talking about here (with the exception of k=) seems like if some browser wanted to use them in the way SDP meant that is fine too, it just SDP does not require anything to happen with them. 

Can we find a different way of phrasing this than "MUST ignore" - I'm agreeing with you on what browser need to implement, I just don't think "MUST ignore" is the right way to say it. 

> On Apr 2, 2015, at 9:14 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> The API already exposes the sdp that went into set remote. Those lines should show up there. Otherwise, must ignore seems right to me.
> 
> Den 30. mars 2015 20.36.04 GMT+01:00, skrev Adam Roach <adam@nostrum.com>:
> On 3/30/15 14:18, Cullen Jennings wrote:
>  On Mar 30, 2015, at 10:09 AM, Adam Roach <adam@nostrum.com> wrote:
> 
>  i=, u=, e=, p=, z=, r=
>    SHOULD NOT send, MUST ignore.
>  I don't think MUST ignore is correct. First to be clear, I'm not saying the browser needs to do anything with the info in theses lines.
> 
>  I think MAY ignore or not typically used by a webrtc browser might be a better way to say it. For example, if rtcweb device was taking a streaming video session via webrtc protocols, it might make sense for it to use the i= or u= particularly if the SDP had originally come from an RTSP stream that was gatewayed to WebRTC. Similarly if a browser reported the full SDP it had
> received in some stats interface, I would expect it not to ignore the lines but actually report what it was it received.
> 
> 
>  To be clear, I'm not saying the browser needs to do anything with the info in theses lines - it's fine to ignore them. But that's very different from all webrtc things must ignore them. (and I agree with SHOULD NOT send part)
> 
> I think we're in agreement about the principle, but might be at cross 
> purposes regarding the venue: I agree that non-browsers may well have 
> reasons to use these fields, but I don't think this document has much 
> bearing on what those implementations do; at least, not as it currently 
> describes itself.
> 
>  From the introduction section, JSEP "describes how the W3C WEBRTC 
> RTCPeerConnection interface is used to control the setup, management and 
> teardown of a multimedia session." So, in the context of *this* 
> document, it would *appear* that we're in agreement that
> the proper 
> 
> normative behavior is to ignore the values in these lines. So I can see 
> why we might be quibbling about "SHOULD" versus "MUST," but your 
> objection seems much broader than that.
> 
> If our difference of opinion here arises from differing views about 
> intended scope for the JSEP document, then we need to start a broader 
> conversation around, minimally, the introduction section of the current 
> draft.
> 
> /a
> 
> 
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.