Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-13 Thread Sam Whited
Daniel actually pointed out (OOB) that the problem I was seeing wasn't
that clients aren't handling instance tags properly: Instead it looks
like some clients (Conversations does this) don't actually even use
the OTR lib for messages which arrive via Carbons, so the instance
tags never get used and the message isn't discarded.

Since they'll only be decryptable by a single session, I still don't
see a benefit to sending to the bare JID though (you'll just be
wasting bandwidth and dropping them anyways, so you might as well just
send to the full JID and not waste time copying it everywhere else or
letting the server accidentally send it to the wrong location).

Also, my language probably needs to be changed (or split out into
documentation and recommendation sections), since this is an
informational OTR and SHOULD only be documenting existing usages (I
really need to get rid of the RFC 2119 style language), and it looks
like most things send to the full JID.

All that being said, OTR isn't a good fit for XMPP and I'm hoping
OMEMO/axolotl will replace it once it's been vetted a bit more, so I'm
not super concerned either way. Documenting existing usage is probably
the best thing to do here.

—Sam


On Sun, Sep 13, 2015 at 9:50 AM, Thijs Alkemade  wrote:
>
>> On 13 sep. 2015, at 15:50, Sam Whited  wrote:
>>
>> I was experimenting with OTR a bit today and was going to tweak this
>> section of the document, but I think I'm still siding with Daniel on
>> this one and am not going to make any change at the moment: Sending to
>> the full JID just doesn't work with OTR in practice.
>>
>> Does any client actually use instance tags to discard junk messages?
>> After a (very cursory) search over some popular clients I didn't see
>> any of them using instance tags. Would love to be told otherwise
>> though.
>
> libotr does:
>
> https://bugs.otr.im/projects/libotr/repository/revisions/master/entry/src/message.c#L994
>
> otr4j does:
>
> https://github.com/jitsi/otr4j/blob/bfd0b363a9a7865f68e46db19c095a8f34ace6be/src/main/java/net/java/otr4j/session/OtrAssembler.java#L96
>
> AFAICT those two together cover a great number of clients.
>
> The only implementation of OTR I could find that does not support instance
> tags is pure-python-otr:
>
> https://github.com/python-otr/pure-python-otr/issues/28
>
> Best regards,
> Thijs
>



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com


Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-13 Thread Thijs Alkemade

> On 13 sep. 2015, at 15:50, Sam Whited  wrote:
> 
> I was experimenting with OTR a bit today and was going to tweak this
> section of the document, but I think I'm still siding with Daniel on
> this one and am not going to make any change at the moment: Sending to
> the full JID just doesn't work with OTR in practice.
> 
> Does any client actually use instance tags to discard junk messages?
> After a (very cursory) search over some popular clients I didn't see
> any of them using instance tags. Would love to be told otherwise
> though.

libotr does:

https://bugs.otr.im/projects/libotr/repository/revisions/master/entry/src/message.c#L994

otr4j does:

https://github.com/jitsi/otr4j/blob/bfd0b363a9a7865f68e46db19c095a8f34ace6be/src/main/java/net/java/otr4j/session/OtrAssembler.java#L96

AFAICT those two together cover a great number of clients.

The only implementation of OTR I could find that does not support instance
tags is pure-python-otr:

https://github.com/python-otr/pure-python-otr/issues/28

Best regards,
Thijs



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-13 Thread Sam Whited
I was experimenting with OTR a bit today and was going to tweak this
section of the document, but I think I'm still siding with Daniel on
this one and am not going to make any change at the moment: Sending to
the full JID just doesn't work with OTR in practice.

Does any client actually use instance tags to discard junk messages?
After a (very cursory) search over some popular clients I didn't see
any of them using instance tags. Would love to be told otherwise
though.

Maybe there's a case for making a future recommendation that says "if
clients support instance tags then allow OTR messages to be copied and
send to the bare JID".

Best,
Sam


Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-09 Thread Daniel Gultsch
and more importantly makes the behavior (who will actually receive the
message) much more predictable
On Sep 9, 2015 20:32, "Daniel Gultsch"  wrote:

> well instance tags only help the receiving client to discard garbage. if
> you send your messages to a full jid you avoid unnecessary traffic.
> On Sep 9, 2015 16:16, "Sam Whited"  wrote:
>
>> Thanks Thijs, I was forgetting about instance tags entirely. Will fix.
>>
>> —Sam
>>
>> On Wed, Sep 9, 2015 at 6:20 AM, Thijs Alkemade  wrote:
>> >> However, OTR requires that messages be sent to a particular resource.
>> Therefore clients SHOULD send OTR messages to a full JID, possibly allowing
>> the user to determine which resource they wish to start an encrypted
>> session with.
>> >
>> > This is no longer true with OTR v3. This version added “instance tags”
>> which
>> > can distinguish different clients signed in to the same account.
>> >
>> > Regards,
>> > Thijs
>>
>>
>>
>> --
>> Sam Whited
>> pub 4096R/54083AE104EA7AD3
>> https://blog.samwhited.com
>>
>


Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-09 Thread Daniel Gultsch
well instance tags only help the receiving client to discard garbage. if
you send your messages to a full jid you avoid unnecessary traffic.
On Sep 9, 2015 16:16, "Sam Whited"  wrote:

> Thanks Thijs, I was forgetting about instance tags entirely. Will fix.
>
> —Sam
>
> On Wed, Sep 9, 2015 at 6:20 AM, Thijs Alkemade  wrote:
> >> However, OTR requires that messages be sent to a particular resource.
> Therefore clients SHOULD send OTR messages to a full JID, possibly allowing
> the user to determine which resource they wish to start an encrypted
> session with.
> >
> > This is no longer true with OTR v3. This version added “instance tags”
> which
> > can distinguish different clients signed in to the same account.
> >
> > Regards,
> > Thijs
>
>
>
> --
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
>


Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-09 Thread Sam Whited
Thanks Thijs, I was forgetting about instance tags entirely. Will fix.

—Sam

On Wed, Sep 9, 2015 at 6:20 AM, Thijs Alkemade  wrote:
>> However, OTR requires that messages be sent to a particular resource. 
>> Therefore clients SHOULD send OTR messages to a full JID, possibly allowing 
>> the user to determine which resource they wish to start an encrypted session 
>> with.
>
> This is no longer true with OTR v3. This version added “instance tags” which
> can distinguish different clients signed in to the same account.
>
> Regards,
> Thijs



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com


Re: [Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-09-09 Thread Thijs Alkemade
> However, OTR requires that messages be sent to a particular resource. 
> Therefore clients SHOULD send OTR messages to a full JID, possibly allowing 
> the user to determine which resource they wish to start an encrypted session 
> with.

This is no longer true with OTR v3. This version added “instance tags” which
can distinguish different clients signed in to the same account.

Regards,
Thijs


signature.asc
Description: Message signed with OpenPGP using GPGMail


[Standards] NEW: XEP-0364 (Current Off-the-Record Messaging Usage)

2015-08-27 Thread XMPP Extensions Editor
Version 0.1 of XEP-0364 (Current Off-the-Record Messaging Usage) has been 
released.

Abstract: 
This document outlines the current usage of Off-the-Record 
messaging in
XMPP, its drawbacks, its strengths, and recommendations for 
improving the
end user experience.


Changelog: Initial published version approved by the XMPP Council. (XEP Editor 
(mam))

Diff: http://xmpp.org/extensions/diff/api/xep/0364/diff/0.1/vs/0.1

URL: http://xmpp.org/extensions/xep-0364.html