Re: [MMUSIC] [Technical Errata Reported] RFC8864 (7805)

[Paul Kyzivat <[e-mail]>]

Harald,

I'm confused. I thought DCEP was created to support WebRTC usage. It 
included the even/odd rule, I suppose because the people defining DCEP 
thought it was needed. RFC8864 was defined for use by a different 
constituency. *It* included the even/odd rule solely for compatibility 
with DCEP. Now it seems you are saying that WebRTC can't comply with the 
even/odd rule so RFC8864 should be revised to remove that.

Are you also asking for DCEP (RFC8832) to remove its even/odd rule? If 
not, why not?

	Thanks,
	Paul

On 4/4/24 10:13 AM, Harald Alvestrand wrote:
> On 4/4/24 15:58, Christer Holmberg wrote:
>> Hi,
>>
>>>> I am not sure what you mean be "pre-agreed data channels", but I was
>>>> referring to applications that use both DCEP and SDP.
>>>
>>> I was specifically referring to datachannels created with the 
>>> "negotiated"
>>> flag
>>> set to "true".
>>
>> Gotcha.
>>
>> So, you are saying there ARE applications that use both DCEP and SDP
>> ("negotiated" flag set to "true") to negotiate data channels?
> 
> Yes. We've seen it used.
> 
>>
>>> WebRTC, as currently specified, will ignore all attempts to negotiate
>>> datachannels using SDP, so those channels can only be created by the
>>> application parsing the SDP, extracting the information, and calling
>>> "createDataChannel" with "negotiated" set to true.
>>
>> Correct.
>>
>>>> Also, your claim that the DCEP odd/even restriction would not apply for
>>>> certain cases is (AFAIK) not defined anywhere. Also, I don't 
>>>> understand why
>>>> the odd/even restriction would not apply in the case where you have 
>>>> pre-
>>>> agreed data channels.
>>>
>>> The WebRTC spec, at
>>> https://w3c.gi/
>>> thub.io%2Fwebrtc-pc%2F%23dom-rtcdatachannelinit-
>>> id&data=05%7C02%7Cchrister.holmberg%40ericsson.com%7C3bd0b5c63c86
>>> 470f330f08dc54a2bc12%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0
>>> %7C638478305114832628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C
>>> %7C&sdata=HbedMunDcF%2Fvy7YawmqPo%2FFBhqi7kjeflQWO185SXvQ%3
>>> D&reserved=0, does not
>>> mention the odd/even rule. For good reason; both ends have to call
>>> createDataChannel with the same value for "id", so it *has* to "violate"
>>> the odd/even rule.
>>
>> Both endpoints obviously have to use the same "id", but one endpoint 
>> has to
>> decide which "id" to use, and when using SDP the idea was to re-use 
>> the DCEP
>> odd/even rule.
> 
> And that re-use is exactly the thing that we can't do.
> 
>>
>> I DO agree that the odd/even rule does not work in SDP actpass cases 
>> (where
>> the id has to be set before the DTLS roles have been determined), and 
>> should
>> be corrected, but I am not sure whether the correction suggested in 
>> the errata
>> is the right way.
> 
> I'm happy to see alternate text suggested. My suggestion was only in 
> order to have something specific to suggest in order to get rid of the 
> inappropriate MUST.
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic