Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?

I don’t see them as contradictory. ice-sip-sdp requires implementations not suporting rtcweb-mdns-ice to ignore the .local candidates. This combined with ice-pac should enable interop of with implementations of rtcweb-mdns-ice via server reflexive candidates.

The one remaining piece is legacy handling of c= lines with mDNS names. 

> On Jul 3, 2019, at 5:58 PM, Justin Uberti <juberti=40google.com@dmarc.ietf.org> wrote:
> 
> Hmm, that's unfortunate. I think this is a mistake, given that we are about to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this extension spec is written.
> 
> ice-sip-sdp isn't published yet, so it seems an update to that document could still be a possibility. If that's not an option, putting forth #1 as a specific extension that allows FQDN candidates to be generated in certain situations seems like the right path.
> 
> 
> 
>> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <roman@telurix.com> wrote:
>> Part of the problem is that mmusic have decided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the final language that was included:
>> 
>> <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).  When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6.  An agent generating local candidates MUST NOT use FQDN addresses.  An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized.  The procedures for generation and handling of FQDN candidates, as well as, how agents indicate support for such procedures, need to be specified in an extension specification.
>> 
>> So, at this point we have two options: 
>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define how FQDN candidates generated by mdns are handled
>> 2. write a new draft in mmusic which defines FQDN handling
>> 
>> In any case some sort of mmusic discussion is needed to reconcile this.
>> 
>> Best Regards,
>> _____________
>> Roman Shpount
>> 
>> 
>>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <juberti@google.com> wrote:
>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If there are individual issues to resolve, we can send them out to mmusic for discussion, but AFAIK no changes to existing ICE specs are needed.
>>> 
>>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
>>>> Hi All,
>>>> 
>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are significant interop implications for this draft between browser and non-browser end points which probably warrant larger discussion outside of rtcweb group. I would think mmusic would be a much better place for this draft. I know there is an incentive to complete this draft quickly but this has a potential to break a lot of things (it already did break interop with almost every existing ICE implementation).
>>>> 
>>>> Regards,
>>>> _____________
>>>> Roman Shpount
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb