[Standards] Jingle initiate and resource determination
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.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards