Hi, Peter Saint-Andre wrote: > You might want to make it clear that by "server" you don't mean "XMPP > server" and by "client" you don't mean "XMPP client".
I guess I should use my own words "service provider" and "controller" all the time to avoid confusion. > In your architecture, is a "node" (1) <[EMAIL PROTECTED]> or (2) > <[EMAIL PROTECTED]/resource>? If (2), does each application have its > own certificate? (2) and each application has its own certificate. > About authorization, you might want to check out XEP-0235. I already was thinking about this. I have to do some more thinking. Since I'm about to split the doc into three XEP proposals, the authorization doc will be send to you later. > About security, what about using something like XTLS? > http://www.xmpp.org/extensions/inbox/xtls.html I was thinking about DTLS, I did not know that there already is something in the inbox. But not many tls implementations support it, my python bindings use tlslite which lacks dlls support. I know it is not a good reason, but since all XMPP clients already support <starttls> for streams this looks like a simpler idea. And the overhead IBB + <starttls> is similar to XTLS, with stream compression in the inside even less. And when not using IBB, it can reduce the server traffic. I will do some more thinking about this. >> Before finishing it and sending it to the XMPP council I want to ask on >> this list for some opinions about it. It clearly uses XMPP in a way >> XMPP was not indented to be used, but it could be the base for new use >> cases (examples of such use cases are in the document). > > Well, HTTP is being used for things that Tim Berners-Lee never intended, > so who are we to complain about creative uses of XMPP? :) :) Dirk -- Dancing is a vertical expression of a horizontal desire.
