What holds on to RTCOfferOptions and its iceRestart member

[gsnedders]

https://w3c.github.io/webrtc-pc/#dictionary-rtcofferoptions-members defines a bunch of semantics, but it's not entirely clear what's meant to reference it.

It makes mention to "the relevant RTCPeerConnection object" — presumably this is the RTCPeerConnection instance which had its createOffer(optional RTCOfferOptions options = {}) called with that RTCOfferOptions dictionary, but is this just held together via some magic internal property (on the dictionary) or is it held together in some other way?

It's also not immediately clear as someone slightly detached from WebRTC "generated description" is meant to be — it's the only time the phrase appears, which is potentially surprising given it's far from the only thing that affects constructing an offer.

https://w3c.github.io/webrtc-pc/#dfn-final-steps-to-create-an-offer says:

Given the information that was obtained from previous inspection, the current state of connection and its RTCRtpTransceivers, generate an SDP offer, sdpString, as described in [RFC9429] (section 5.2.).

Is it part of the current state of the connection? Because it's not obviously part of the state, especially given it's not referenced in State Definitions — nothing made it part of the state, it just magically changes the description?

And https://www.rfc-editor.org/rfc/rfc9429#section-5.2.3 actually directly specifies behaviour based on the RTCOfferOptions object, again as if it's magically been passed across (and somehow it changes from the iceRestart member to presumably equivalent the IceRestart member, despite these being separate IDL dictionary keys).

From a spec point-of-view, it seems like RFC9429 is meant to read up the call stack, across an in parallel call, from:

• The createOffer method steps
• To create an offer
• The in-parallel steps to create an offer
• The final steps to create an offer
• RFC9429 5.2 Constructing an Offer

Only the top-most algorithm — the createOffer method steps — actually receives the RTCOfferOptions dictionary as an argument (and then doesn't do anything with it), thus presumably the ultimate reference in RFC9429 just magically walks the call stack? The "in parallel" steps especially make the question of what holds onto it significant.

This doesn't seem ideal from a specification point of view to have things magically reading up to what parent algorithms got as arguments — if the arguments are relevant, they should be passed down the call stack.