[Standards] Jingle initiate and resource determination

[Peter Saint-Andre]

Ian Paterson wrote:
> Lauri Kaila wrote:
>> Hi Ian,
>>
>> 2007/6/6, Ian Paterson <ian.paterson at clientside.co.uk>:
>>> > What do you think about this idea: Jingle session receiver publishes
>>> > session-initiate, accept and terminate stanzas. That would provide
>>> > means to implement "someone calling/sends a file to your PC" note on a
>>> > mobile device.
>>>
>>> Sorry, I didn't understand your idea. Could you please expand it. 
>>> Thanks.
>>
>> OK - I'll try. I haven't studied Publish-Subscribe and PEP enough to
>> be more precise, but I assume that it would be quite easy to
>> distribute Jingle stanzas between a person's own XMPP clients using
>> the same account. XEP-0166 would need to define more specifically how
>> to get these "Jingle action events".

Yes, it might be nice for one of your resources to know that another has 
a Jingle session underway or whatever. Though presumably there is a 
person controlling all those resources (you!), so you would know what's 
happening with each device.

> Technically it would be trivial to forward the stanzas to the other 
> resources (there would be no need for pubsub or PEP). But, in any case, 
> the other resources wouldn't be allowed to reply to the session-initiate 
> (since only the original recipient is allowed to reply to an <iq/> 
> stanza). i.e., the advantage of forwarding would be purely "FYI".

Right, it's not true forwarding it's more of an FYI.

> Furthermore, Ralph (yes he is alive) 

He is? Tell him to vote on the Council items outstanding. ;-)

> reminded me that the reason we 
> haven't accepted a standard for indicating the original sender of 
> forwarded stanzas is the difficult trust issue that  inevitably arises. 
> You could argue that those problems don't arise when forwarding between 
> resources of the same bareJID. However, I'm not yet convinced you have 
> identified a compelling use case.

Me neither. :)

>> That would be enough to ensure that a call is never missed because of 
>> the priority values.

That's a good goal.

> AFAICT the proposed Namespace Priority approach solves the significant 
> issues. Have you identified real-world scenarios where calls will be 
> missed because of the priority values?

Having re-read your namespace priority idea, I think it has merit.

One challenge I see is synchronization of namespace priorities across 
resources. We already have this to some extent with standard XMPP 
presence priorities (oh damn I left my desktop priority as 99 and now I 
need to use remote controlling to change it there, or make my priority 
here 100). But with presence priorities at least the numbers are 
broadcasted to all of your other resources. AFAICT we would not have 
that with the IQ-based namespace priorities unless there would be some 
kind of "NP-push".

> If you have then a more simple fix might be to employ the existing 
> <redirect/> error (as defined in RFC 3920). This allows the resource 
> that receives the session-initiate to indicate to the sender that it 
> should instead try opening the Jingle session with another specified 
> resource.

Yep, we've got that.

The more I ponder forking of headline messages, the more I like that 
idea, because it also works for plain old chat sessions. Currently 
Google Talk sends all messages to all resources but they need a fancy 
coordination protocol to retract messages that are not of interest to 
other resources. If the initial message in a chat session (or the stanza 
session negotiation request) is of type headline and all the others are 
of type "chat" then you get only one message at the other resources (and 
we could even give that a TTL so the receiving clients at your other 
resources throw it away after a certain time).

/me ponders some more...

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070606/44459b63/smime.bin