Lauri Kaila wrote:
Hi Peter, Ian, All,2007/6/7, Peter Saint-Andre <[EMAIL PROTECTED]>:> 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 -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
