> On Oct 29, 2016, at 5:46 PM, XMPP Extensions Editor <[email protected]> wrote: > > This message constitutes notice of a Last Call for comments on XEP-0371 > (Jingle ICE Transport Method). > > Abstract: This specification defines a Jingle transport method that results > in sending media data using datagram associations via the User Datagram > Protocol (UDP) or using end-to-end connections via the Transport Control > Protocol (TCP). This transport method is negotiated via the Interactive > Connectivity Establishment (ICE) methodology (which provides robust NAT > traversal for media traffic) and also supports the ability to exchange > candidates throughout the life of the session, consistent with so-called > "Trickle ICE" (draft-ietf-ice-trickle). > > URL: http://xmpp.org/extensions/xep-0371.html > > This Last Call begins today and shall end at the close of business on > 2016-11-12. > > Please consider the following questions during this Last Call and send your > feedback to the [email protected] discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol stack or to > clarify an existing protocol? > 2. Does the specification solve the problem stated in the introduction and > requirements? > 3. Do you plan to implement this specification in your code? If not, why not? > 4. Do you have any security concerns related to this specification? > 5. Is the specification accurate and clearly written? > > Your feedback is appreciated!
In addition to the comment Peter referenced, I also have a few other concerns about this spec. The definitions of the two Jingle-ICE fields that don’t map directly to SDP (“generation” and “network”) seem pretty underspecified to me. For generation, the table in Section 5.3 says generation maps to "extended name/value pair in a=candidate line” which makes very little sense. There are also a lot of issues that are unclear to me about its definition. Is the other Jingle endpoint required to use matching generation values, or are each side’s values independent? Is an endpoint allowed to skip values? Since the XSD defines the field as “unsignedByte”, what happens when I’ve done more than 256 ICE restarts? Similarly for “network” — are these values required to be stable across an ICE restart? Do srflx candidates’ network values have to match those of host candidates? What about relay candidates? If I have IPv4 and IPv6 on the same interface, should the network value be the same, or different? Since XEP-0371 doesn’t need to be backward compatible with XEP-0176 (the namespace URNs are different), my suggestion would be to drop these two fields from XEP-0371 entirely, and just exchange the information defined in the IETF ICE specs. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
