[Standards] namespace versioning for XEP-0176

Kevin Smith kevin.smith at isode.com
Fri Dec 11 12:00:02 UTC 2015


> On 11 Dec 2015, at 10:40, Dave Cridland <dave at cridland.net> wrote:
> 
> 
> 
> On 11 December 2015 at 10:07, Kevin Smith <kevin.smith at isode.com <mailto:kevin.smith at isode.com>> wrote:
> On 11 Dec 2015, at 09:56, Dave Cridland <dave at cridland.net <mailto:dave at cridland.net>> wrote:
>> 
>> 
>> 
>> On 11 December 2015 at 03:56, Peter Saint-Andre <stpeter at stpeter.im <mailto:stpeter at stpeter.im>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151211/13fac91e/attachment.html>


More information about the Standards mailing list