Jonathan Schleifer wrote:
Jonathan Dickinson <[EMAIL PROTECTED]> wrote:(compared to making a new standard which would have no implementations).ESessions *HAS* implementations! That's the point I bring up again and again against reinventing the wheel and doing something with TLS now!
ESessions has one implementation. As far as I know, we cannot use the plural "implementations" w.r.t. ESessions.
<encrypted from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]"> 192376123abd078f123aasdjib123khnasd0u123== </encrypted>Now you're even talk about breaking XMPP Core compatibility? And libotr can't handle arbitrary data, just messages. For which it will add HTML escapes if it's plaintext.Originator-Supported Add <e2e2/> tag to iq query. Receiver-Supported Recognise <e2e2/> tag and begin e2e2 negotiation. Originator-Unsupported No changes made. Receiver-Unsupported No changes to code made, new <e2e2/> tag simply ignored if present. Negotate e2e as normal. Receiver-Unsupported Originator-Supported When first IQ response it aquired, <e2e2>...</e2e2> tag is not present. Continue e2e negotiation.libotr uses whitespaces to detect support. It's hardcoded.
And other ugliness.
As you can see it kinda works the kinks out itself.Doesn't look like that to me.
As far as I can see, OTR doesn't meet the requirements specified in XEP-0210:
http://www.xmpp.org/extensions/xep-0210.html /psa
smime.p7s
Description: S/MIME Cryptographic Signature
