Overall it looks good. Thanks, Dirk! Dirk Meyer wrote:
Pavel Simerda wrote:On Sun, 24 Aug 2008 20:59:22 +0200 Dirk Meyer <[EMAIL PROTECTED]> wrote:Johansson Olle E wrote:Could this functionality benefit from some sort of Disco support to check what the other side supports, before setting up the connection?+1You could put the stuff I added as <offer> to the disco stuff. But it must also work serverless. And when I work link-local I can not use disco#query before connecting.I don't know much about link-local messaging but if it uses DNS (which it does), it can use it for discovery. (I don't say it's good or bad.)We could hook into the txt records and add the offer there.
Right. In link-local you don't have disco or caps before you try TLS, but these features can be put in txt records (see XEP-0174).
But then I would expect a real-world usecase with XML examples for better understanding.Yes, I know. But since all people on the list know what it is about I skiped that part. It will be added later.And it would be good to resolve the "SRP vs. SAS vs. whatever else" issue or leave this possibility out of the spec before it's resolved (so we aren't pushed by the developers to keep what we put there already). A short paragraph about other possibilities to be included would do.Agreed. The list in 'Requirements' is based on what is a RFC now. I should add a note that anything that can be used with TLS can also be used at this point. And if there will be SAS support in TLS it can be used. If a client does not support it, it can simple ignore the <sas> offer. So a note: 'ignore offers you do not know' and 'there can be more in the future' is needed.
Agreed.
Furthermore, it's important to hear from Peter Saint-Andre and maybe others about the disco features and other interoperability issues.Yes. If we can put the offer from starttls in the disco feature and use txt records, that would be nice to have. Or offer disco#query as feature before starttls. But the second offer in proceed can not be avoided since only at this point the receiver knows what it wants to support for that specific client based on what it can verify.
I think we worked out the disco+caps / txt-record issue -- advertise multiple disco features (not items).
BTW I think it's not only c2c, is it? In the future we might use e2e streams for things like encrypted MUCs (if you trust the groupchat service to securely hold a key -- perhaps a big if).
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
