W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2017

[webrtc-pc] Section 4.2.3 (createOffer)

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Wed, 31 May 2017 16:33:54 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-232624626-1496248433-sysbot+gh@w3.org>
aboba has just created a new issue for https://github.com/w3c/webrtc-pc:

== Section 4.2.3 (createOffer) ==
>From EKR: https://lists.w3.org/Archives/Public/public-webrtc/2017May/0166.html

   4. Return the result of enqueuing the following steps:
      1. Let p be a new promise.

This seems like another situation where a generic algorithm would

   setLocalDescription without causing an error as long as
   setLocalDescription is called reasonably soon.

I have no idea what "reasonably soon" means

This algorithm leaves the state of the PC changed in case of
bogus inputs. However, JSEP requires that the state be unchanged
(see JSEP S 5.8)


   3. If both sdpMid and sdpMLineIndex are null, return a promise
   rejected with a newly created TypeError.

See above about consistency. Why is the promise rejected here
immediately but otherwise these are enqueued? How does that help?


    3. For each url in server.urls parse url and obtain scheme
    name. If the scheme name is not implemented by the browser, or if
    parsing based on the syntax defined in [ RFC7064] and [RFC7065]
    fails, throw a SyntaxError.

This seems unwise as it makes it very hard to introduce new schemes.
Why aren't they just ignored?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1278 using your GitHub account
Received on Wednesday, 31 May 2017 16:34:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:15:25 UTC