[Council] Fwd: Re: [Standards] Jingle specification bug - missing error condition
stpeter at stpeter.im
Mon Feb 13 23:44:35 UTC 2012
-------- Original Message --------
Subject: Re: [Standards] Jingle specification bug - missing error condition
Date: Mon, 13 Feb 2012 16:43:01 -0700
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Standards <standards at xmpp.org>
CC: Ben Langfeld <ben at langfeld.co.uk>
On 1/26/12 10:29 AM, Peter Saint-Andre wrote:
> On 1/26/12 9:18 AM, Peter Saint-Andre wrote:
>> On 1/26/12 4:53 AM, Ben Langfeld wrote:
>>> I believe I have found a minor bug in XEP-0166, as follows:
>>> 1) An example states that a <security-required/> error element be
>>> included in a response, qualified by the urn:xmpp:jingle:errors:1
>>> namespace: http://gitorious.org/xmpp/xmpp/blobs/master/extensions/xep-0166.xml#line1399
>>> 2) The table of error conditions does not include
>>> 3) The schema does not include <security-required/>:
>>> I am unsure if it is the schema or the example which is correct. If
>>> someone can nudge me in the right direction, I can get a patch
>>> submitted today.
>> Thanks for the bug report. I think that was an oversight in the table
>> and schema, but I'll double-check and post again.
> Now I'm not so sure. Let's look at the paragraph before that example:
> If one of the parties attempts to send information over the
> unsecured XMPP signalling channel that the other party expects to
> receive over the encrypted data channel...
> That's kind of a strange scenario. You and I have set up an encrypted
> data channel, but I try to send data to you over the signalling channel
> that you would have expected me to send to you over the data channel.
> Perhaps we were thinking of XTLS at the time, but even that spec 
> does not use the <security-required/> error. So I now think that this is
> extraneous text that needs to be removed.
> I'll forward this message to the jingle at xmpp.org list for verification.
I've received no verification, but I still think this is the right thing
to do. I'll bring it up in the next XMPP Council meeting.
More information about the Council