[Standards] Jingle initiate and resource determination

Peter Saint-Andre stpeter at jabber.org
Thu Jun 14 21:25:12 UTC 2007

Lauri Kaila wrote:
> Hi Peter, Ian, All,
> 2007/6/7, Peter Saint-Andre <stpeter at jabber.org>:
>> > Information overload - this thread contains more information than I
>> > can handle right now. I'll ask more silly questions later...
>> I think in part what we're trying to prevent here is information
>> overload -- too many decisions forced onto the user when perhaps the
>> servers in the middle could have enough information to deliver stanzas
>> more intelligently...
> Some questions and thoughts:
> - I'm not against intelligent software, but could the resource
> determination process now be simplified? :) Now there are new
> dependencies for clients to implement (0166->0155->0068).

Right. Personally I think that plain old messaging and social 
negotiation is fine. I send a message to your bare JID and you reply if 
you want to talk.

But that assumes people can type messages, that this stuff won't be 
negotiated between devices in a more automatic fashion, etc. If people 
want to automate this stuff, I don't think that XEP-0155 is a huge burden.

> - Isn't RAP practical only if server always includes the priorities in
> presence? It doesn't feel quite good to create a RAP request before
> each session.

The servers are included by the clients. The server just passes them along.

> - Isn't disco request unnecessary step in resource determination? Why
> not simply let initiation fail?

Sure, that's another possibility. My sense is that people always want 
the call to go through. :)

> - The initiator shouldn't need to know which resource to choose, but
> it shouldn't be prevented to create session with any specific
> resource. This is OK by having RAP/NP and XEP-0155 optional, as it
> currently is.

Agreed. See my previous warning about trying to get too smart.

> - A scenario when even the most correct priority-based resource
> selection fails: File transfer when I'll be receiving files related to
> work/home/hobby and maybe some files are specific to only
> Windows/Linux/OSX/mobile client. The human would make the decision
> based on file content and purpose. This is a fictional use case but I
> think not totally from the outer space.

See above on social negotiation. I ask you where you want me to send it 
and you specify the resource. Could also be done via XEP-0155 request 
with type='headline' if those get delivered to all resources.

> - I would like to have a mandatory FYI notification to all resources.
> A headline message would be fine, but I wouldn't like priority routing
> for that. Then a human could react always when the computers fail.

Correct. I like that headline forking stuff for just this reason.

> - <redirect> would be really nice in some of these sitiations, but the
> original resource must know where to redirect, and it doesn't happen
> automatically. Hmm - at least it fits nicely for some file transfer
> scenarios: I could forward huge file transfers from a mobile to PC.

Yes. But with presence, you probably know about your other resources.

> - If a <redirect> response contains a bare JID, the usual resource
> determination procedure should be applied. Obvious?

I think so. :)

> - Is it possible to go into a <redirect> loop? Should it be detected
> that the same session-initiate is being received twice? If yes, how?
> Require using the same SID for redirected initiation?

Ick yes that seems like a possibility. I think that will be handled on 
the initiator side.

> - Application name registration was removed from XEP-0168. I think
> there should be some kind of standard convention for app names.

XML namespaces are not good enough?

> Otherwise clients may use any names with Entity Capabilites (ext
> attribute).  Therefore a same name could mean something different for
> each active resource of my roster, which would require an IQ for each.
> Why not define a standard name for each XEP like "xep-0167", or
> shorter "0167" for previously used "jingle-audio"? Maybe a prefix for
> private extensions?

I *think* we don't need the appnames (just one more mapping for clients 
to remember) and can use XML namespaces instead. If not, we can always 
add the appnames back in. I was just trying to simplify things.


Peter Saint-Andre
XMPP Standards Foundation

-------------- 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/20070614/7889a26f/attachment.bin>

More information about the Standards mailing list