On 11 December 2015 at 10:07, Kevin Smith <[email protected]> wrote:
> On 11 Dec 2015, at 09:56, Dave Cridland <[email protected]> wrote: > > > > > On 11 December 2015 at 03:56, Peter Saint-Andre <[email protected]> > wrote: > >> Folks, I am working on revisions [1] to XEP-0176 to bring it up to date >> with both RFC 6544 (ice-tcp) and draft-ietf-ice-trickle. Therefore, the >> next version of this specification will add support for several new >> candidate types ("tcp-active", "tcp-passive", and "tcp-so"). To prevent >> confusion, I am thinking it would be best to change the XML namespace as >> follows... >> >> old: "urn:xmpp:jingle:transports:ice-udp:1" >> >> new: "urn:xmpp:jingle:transports:ice:2" >> >> That is, because ICE can now be used to negotiate a TCP connection and >> not just a UDP association, I propose that we generalize XEP-0176 and thus >> change the transport name from "ice-udp" to "ice", while at the same time >> bumping the version from "1" to "2". >> >> Does anyone have concerns with this approach? >> > > It sounds sensible enough to me, from my position of ignorance. > > I admit I'm partly speaking as devil's advocate here - but I'm conscious > that there is relatively wide deployment of XEP-0176, and I'm wondering if > it might be better to create a new specification and deprecate this one in > favour of it. Accessing old versions of specifications is hard, and if the > changes are substantial, both specification versions will probably co-exist > for some time to come. > > > They’re available at a stable URL, though, so it’d be fairly > straightforward to put a link to the old version in the new version, if > that’s a concern. > > Yes, and maybe that's good enough. I just remember we had a degree of confusion around the time we changed XEP-0115 to include cryptographic hashes, and most clients were sending without. I don't want to make this stuff any harder than it is already. Dave.
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
