> On 11 Dec 2015, at 10:40, Dave Cridland <[email protected]> wrote: > > > > On 11 December 2015 at 10:07, Kevin Smith <[email protected] > <mailto:[email protected]>> wrote: > On 11 Dec 2015, at 09:56, Dave Cridland <[email protected] > <mailto:[email protected]>> wrote: >> >> >> >> On 11 December 2015 at 03:56, Peter Saint-Andre <[email protected] >> <mailto:[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.
Sure. A backref in this cases might be quite sensible. /K
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
