[Jingle] Typo and possible clarification in XEP 0166
juberti at google.com
Mon Apr 20 15:49:31 CDT 2009
Maybe I am just being slow, but it seems like the text within the paragraph
is inconsistent. The initial sentence in effect says, low SID wins, but the
later sentences indicate that the high-SID session is to be processed and
the low-SID session is to be closed. Did I misinterpret?
On Mon, Apr 20, 2009 at 8:40 AM, Peter Saint-Andre <stpeter at stpeter.im>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 4/20/09 8:29 AM, Peter Saint-Andre wrote:
> > On 4/19/09 10:36 PM, Justin Uberti wrote:
> >> One thing I noticed is that we don't have any defined semantics for
> >> handling ties on the call initiation (i.e. if A and B call each other at
> >> the same time). This happens more often than you would expect, and there
> >> are some easy things we could do to handle this scenario (e.g. lowest
> >> JID or session id wins). To have this actually work across all clients,
> >> we would need to explicitly specify this. Thoughts?
> > Good point!
> > Given the possible problems with JID comparison (not everyone does
> > stringprep correctly), I think that comparing session IDs might be
> > safer. But that means we might want to specify the allowable characters
> > for session IDs a bit more carefully (e.g., say that they need to match
> > the NMTOKEN datatype).
> > ... Well, checking the schema I see that we already say this:
> > <xs:attribute name='sid' type='xs:NMTOKEN' use='required'/>
> > So that would work.
> > Peter
> I've adjusted the text as follows...
> 7.2.16 Tie Breaking Related to Jingle Actions
> It is possible that the same Jingle action can be sent at the same time
> by two different parties. There are two possible scenarios:
> No existing session
> If there is no existing session and both parties simultaneously send
> a Jingle session-initiate message, the action with the lower of the two
> session IDs MUST overrule the other action, where by "lower" is meant
> the session ID that is sorted first using "i;octet" collation as
> specified in Section 9.3 of RFC 4790 . The party that receives the
> session-initiate action with the higher of the two session IDs MUST
> acknowledge the action or return an error condition that would normally
> be returned when receiving a session-initiate message, and the party
> that receives the session-initiate action with the lower of the two
> session IDs MUST return a <conflict/> error to the other party, which
> SHOULD include a Jingle-specific condition of <tie-break/>.
> Existing session
> In the context of an existing session, the action sent by the
> initiator MUST overrule the action sent by the responder; i.e., both
> parties MUST accept the action sent by the initiator and the initiator
> MUST return a <conflict/> error to the responder for the duplicate
> action, which SHOULD include a Jingle-specific condition of <tie-break/>.
> In both scenarios, the error to be returned is <conflict/>, as shown in
> the following example.
> Example 34. Initiator returns conflict error on tie-break
> <iq from='romeo at montague.lit/orchard'
> to='juliet at capulet.lit/balcony'
> <error type='cancel'>
> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
> <tie-break xmlns='urn:xmpp:jingle:errors:0'/>
> Does that seem acceptable?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Jingle