Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Florian Schmaus]

On 03.10.2016 10:08, Kevin Smith wrote:
> On 2 Oct 2016, at 18:47, Florian Schmaus  wrote:
>>
>> On 30.09.2016 18:12, Kevin Smith wrote:
>>> On 30 Sep 2016, at 10:01, Dave Cridland  wrote:

 On 30 September 2016 at 09:49, Kevin Smith  wrote:
>
>> On 29 Sep 2016, at 22:58, Dave Cridland  wrote:
>>
>>
>> On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>>>
>>> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
 (And please, folks, unless you can think of something I can't, a
 randomish string prefix and a counter is fine).
>>>
>>> The dangers of using counters in stanza IDs and leaking information :)
>>
>> Yes, quite. I meant to argue against generating UUIDs and otherwise 
>> using a lot of entropy, and got carried away - but a random key and 
>> hmaccing a counter should be okay.
>>
>> Point being, if the stanza id attribute is causing us a problem, that 
>> can be fixed in compatible ways.
>
> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
> everything else. We should probably explicitly call out in carbons and 
> MAM the importance of preserving the id in the header.

 The MUC reflection-detection issue? I *think* that's the only use-case
 after however many years.

 We could mark just the reflected stanza, couldn't we?
>>>
>>> You mean add an element into the outgoing MUC message saying 
>>> original-id-was X? Seems that would work.
>>
>> That's exactly what XEP-0359's  was meant for.
> 
> I don’t think that was clear from 359. My reading of 359 was that this was 
> another client-generated ID, and that it was the client that stamped it.

Sorry, that was meant as reply to "We could mark just the reflected
stanza, couldn't we?". The idea was that clients will recognize their
own stanzas by the , which will stay unchanged unlike the
stanza id of the header.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 2 Oct 2016, at 18:47, Florian Schmaus  wrote:
> 
> On 30.09.2016 18:12, Kevin Smith wrote:
>> On 30 Sep 2016, at 10:01, Dave Cridland  wrote:
>>> 
>>> On 30 September 2016 at 09:49, Kevin Smith  wrote:
 
> On 29 Sep 2016, at 22:58, Dave Cridland  wrote:
> 
> 
> On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>> 
>> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
>>> (And please, folks, unless you can think of something I can't, a
>>> randomish string prefix and a counter is fine).
>> 
>> The dangers of using counters in stanza IDs and leaking information :)
> 
> Yes, quite. I meant to argue against generating UUIDs and otherwise using 
> a lot of entropy, and got carried away - but a random key and hmaccing a 
> counter should be okay.
> 
> Point being, if the stanza id attribute is causing us a problem, that can 
> be fixed in compatible ways.
 
 Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
 everything else. We should probably explicitly call out in carbons and MAM 
 the importance of preserving the id in the header.
>>> 
>>> The MUC reflection-detection issue? I *think* that's the only use-case
>>> after however many years.
>>> 
>>> We could mark just the reflected stanza, couldn't we?
>> 
>> You mean add an element into the outgoing MUC message saying original-id-was 
>> X? Seems that would work.
> 
> That's exactly what XEP-0359's  was meant for.

I don’t think that was clear from 359. My reading of 359 was that this was 
another client-generated ID, and that it was the client that stamped it.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Florian Schmaus]

On 30.09.2016 18:12, Kevin Smith wrote:
> On 30 Sep 2016, at 10:01, Dave Cridland  wrote:
>>
>> On 30 September 2016 at 09:49, Kevin Smith  wrote:
>>>
 On 29 Sep 2016, at 22:58, Dave Cridland  wrote:


 On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>
> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
>> (And please, folks, unless you can think of something I can't, a
>> randomish string prefix and a counter is fine).
>
> The dangers of using counters in stanza IDs and leaking information :)

 Yes, quite. I meant to argue against generating UUIDs and otherwise using 
 a lot of entropy, and got carried away - but a random key and hmaccing a 
 counter should be okay.

 Point being, if the stanza id attribute is causing us a problem, that can 
 be fixed in compatible ways.
>>>
>>> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
>>> everything else. We should probably explicitly call out in carbons and MAM 
>>> the importance of preserving the id in the header.
>>
>> The MUC reflection-detection issue? I *think* that's the only use-case
>> after however many years.
>>
>> We could mark just the reflected stanza, couldn't we?
> 
> You mean add an element into the outgoing MUC message saying original-id-was 
> X? Seems that would work.

That's exactly what XEP-0359's  was meant for.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 30 Sep 2016, at 17:25, Dave Cridland  wrote:
> 
> On 30 September 2016 at 17:12, Kevin Smith  wrote:
>> On 30 Sep 2016, at 10:01, Dave Cridland  wrote:
>>> 
>>> On 30 September 2016 at 09:49, Kevin Smith  wrote:
 
> On 29 Sep 2016, at 22:58, Dave Cridland  wrote:
> 
> 
> On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>> 
>> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
>>> (And please, folks, unless you can think of something I can't, a
>>> randomish string prefix and a counter is fine).
>> 
>> The dangers of using counters in stanza IDs and leaking information :)
> 
> Yes, quite. I meant to argue against generating UUIDs and otherwise using 
> a lot of entropy, and got carried away - but a random key and hmaccing a 
> counter should be okay.
> 
> Point being, if the stanza id attribute is causing us a problem, that can 
> be fixed in compatible ways.
 
 Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
 everything else. We should probably explicitly call out in carbons and MAM 
 the importance of preserving the id in the header.
>>> 
>>> The MUC reflection-detection issue? I *think* that's the only use-case
>>> after however many years.
>>> 
>>> We could mark just the reflected stanza, couldn't we?
>> 
>> You mean add an element into the outgoing MUC message saying original-id-was 
>> X? Seems that would work.
>> 
> 
> I was thinking simply  xmlns='urn:xmpp:reflection'/> actually. Could include the original
> stanza id, but I can't think of a use-case.
> 
> I suppose '308 might prefer if the original id were there in the
> broadcast message in case you want to correct a message before you've
> even seen the reflected copy, though.

Right.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dave Cridland]

On 30 September 2016 at 17:12, Kevin Smith  wrote:
> On 30 Sep 2016, at 10:01, Dave Cridland  wrote:
>>
>> On 30 September 2016 at 09:49, Kevin Smith  wrote:
>>>
 On 29 Sep 2016, at 22:58, Dave Cridland  wrote:


 On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>
> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
>> (And please, folks, unless you can think of something I can't, a
>> randomish string prefix and a counter is fine).
>
> The dangers of using counters in stanza IDs and leaking information :)

 Yes, quite. I meant to argue against generating UUIDs and otherwise using 
 a lot of entropy, and got carried away - but a random key and hmaccing a 
 counter should be okay.

 Point being, if the stanza id attribute is causing us a problem, that can 
 be fixed in compatible ways.
>>>
>>> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
>>> everything else. We should probably explicitly call out in carbons and MAM 
>>> the importance of preserving the id in the header.
>>
>> The MUC reflection-detection issue? I *think* that's the only use-case
>> after however many years.
>>
>> We could mark just the reflected stanza, couldn't we?
>
> You mean add an element into the outgoing MUC message saying original-id-was 
> X? Seems that would work.
>

I was thinking simply  actually. Could include the original
stanza id, but I can't think of a use-case.

I suppose '308 might prefer if the original id were there in the
broadcast message in case you want to correct a message before you've
even seen the reflected copy, though.

> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 30 Sep 2016, at 10:01, Dave Cridland  wrote:
> 
> On 30 September 2016 at 09:49, Kevin Smith  wrote:
>> 
>>> On 29 Sep 2016, at 22:58, Dave Cridland  wrote:
>>> 
>>> 
>>> On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
 
 On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
> (And please, folks, unless you can think of something I can't, a
> randomish string prefix and a counter is fine).
 
 The dangers of using counters in stanza IDs and leaking information :)
>>> 
>>> Yes, quite. I meant to argue against generating UUIDs and otherwise using a 
>>> lot of entropy, and got carried away - but a random key and hmaccing a 
>>> counter should be okay.
>>> 
>>> Point being, if the stanza id attribute is causing us a problem, that can 
>>> be fixed in compatible ways.
>> 
>> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
>> everything else. We should probably explicitly call out in carbons and MAM 
>> the importance of preserving the id in the header.
> 
> The MUC reflection-detection issue? I *think* that's the only use-case
> after however many years.
> 
> We could mark just the reflected stanza, couldn't we?

You mean add an element into the outgoing MUC message saying original-id-was X? 
Seems that would work.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dave Cridland]

On 30 September 2016 at 09:49, Kevin Smith  wrote:
>
>> On 29 Sep 2016, at 22:58, Dave Cridland  wrote:
>>
>>
>> On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>> >
>> > On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
>> > > (And please, folks, unless you can think of something I can't, a
>> > > randomish string prefix and a counter is fine).
>> >
>> > The dangers of using counters in stanza IDs and leaking information :)
>>
>> Yes, quite. I meant to argue against generating UUIDs and otherwise using a 
>> lot of entropy, and got carried away - but a random key and hmaccing a 
>> counter should be okay.
>>
>> Point being, if the stanza id attribute is causing us a problem, that can be 
>> fixed in compatible ways.
>
> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
> everything else. We should probably explicitly call out in carbons and MAM 
> the importance of preserving the id in the header.

The MUC reflection-detection issue? I *think* that's the only use-case
after however many years.

We could mark just the reflected stanza, couldn't we?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

> On 29 Sep 2016, at 22:58, Dave Cridland  wrote:
> 
> 
> On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
> >
> > On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
> > > (And please, folks, unless you can think of something I can't, a
> > > randomish string prefix and a counter is fine).
> >
> > The dangers of using counters in stanza IDs and leaking information :)
> 
> Yes, quite. I meant to argue against generating UUIDs and otherwise using a 
> lot of entropy, and got carried away - but a random key and hmaccing a 
> counter should be okay.
> 
> Point being, if the stanza id attribute is causing us a problem, that can be 
> fixed in compatible ways.

Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does 
everything else. We should probably explicitly call out in carbons and MAM the 
importance of preserving the id in the header.

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dave Cridland]

On 29 Sep 2016 22:00, "Kevin Smith"  wrote:
>
> On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
> > (And please, folks, unless you can think of something I can't, a
> > randomish string prefix and a counter is fine).
>
> The dangers of using counters in stanza IDs and leaking information :)

Yes, quite. I meant to argue against generating UUIDs and otherwise using a
lot of entropy, and got carried away - but a random key and hmaccing a
counter should be okay.

Point being, if the stanza id attribute is causing us a problem, that can
be fixed in compatible ways.

>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 29 Sep 2016, at 21:17, Dave Cridland  wrote:
> (And please, folks, unless you can think of something I can't, a
> randomish string prefix and a counter is fine).

The dangers of using counters in stanza IDs and leaking information :)

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dave Cridland]

On 28 September 2016 at 17:38, Kevin Smith  wrote:
> Sadly not, 6121 says
>  " It is up to the originating entity whether the value of the 'id'
>attribute is unique only within its current stream or unique
>globally.”

Equally, absolutely nothing stops a client issuing globally-unique (or
at least, bare-jid-unique) stanza identifiers on all stanzas.

I'd be up for saying something along the lines of:

"Where the previous message is from a different full jid, the receiver
MAY choose to treat it as a new message, and MUST do so if the bare
jid is not known to be a normal user account. Clients wishing to
correct messages from other client instances of the same user (and
thus using different full jids) MUST use globally unique stanza
identifiers, and SHOULD ensure the message they are correcting is from
a client which advertises this feature."

Then somewhere define a feature for globally unique stanza ids -
possibly in a new XEP.

(And please, folks, unless you can think of something I can't, a
randomish string prefix and a counter is fine).

This would remain compatible with the (draft) spec.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Florian Schmaus]

On 29.09.2016 12:55, Florian Schmaus wrote:
> On 27.09.2016 11:06, Tobias M wrote:
>>> On 27 Sep 2016, at 00:33, Kevin Smith >> > wrote:
 What do you think? Do you have further comments on this issue?
>>>
>>> I think there’s also a concern that different resources may use the
>>> same IDs. Perhaps we should be moving away from using stanza IDs for
>>> this, and move towards something like 359 (although 359 has the
>>> client-id, stanza-id oddity which we should probably fix at some point
>>> and just use multiple stanza-id stamps with the relevant ‘by’ instead).
>>
>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could
>> provide a solution if we can’t rely on unique and stable stanza IDs.
>> It’s not discussed in XEP-0359, but I guess it’s the reason for its
>> existence, that stanza IDs may only be stable/unique regarding one XMPP
>> stream and might change in a multi-hop routing like C-to-S -> S-to-S ->
>> S-to-C or C-to-S -> MUC -> S-to-C.
> 
> Correct

Although I believe that non-xep359 stanza IDs should be stable in the
"c2s → s2s → s2c" case you gave, as error stanzas and IQ responses could
not be matched any more otherwise. But your MUC example is correct. I
remember that people have found that xep45 allows MUC services to change
the stanza id when the stanza is reflected by the service. Which causes
some trouble for client developers. Another potential use case for
xep359 are, of course, archiving services like MAM.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 28 Sep 2016, at 21:18, Tobias M  wrote:
> 
>> 
>> On 28 Sep 2016, at 18:38, Kevin Smith  wrote:
>> 
>> On 27 Sep 2016, at 10:06, Tobias M  wrote:
>>> 
>>> 
 On 27 Sep 2016, at 00:33, Kevin Smith  wrote:
 
> However, it has little discussion on why there is this restriction. While 
> it certainly is a MUST for security reasons in MUC situations where 
> different full JIDs are different accounts (i.e. associated to different 
> bare JIDs), it is less so for security reasons in the non-MUC case.
 
 I think one can construct other situations like MUC, where multiple people 
 control different resources of the same bare JID, but maybe that’s 
 pathological (although I’m not sure).
>>> 
>>> If multiple people would use different resources of the same bare JID, this 
>>> would also lead to strange UX regarding Carbons where the user will see 
>>> messages as sent which they didn’t write. I think this is a rather rare 
>>> edge case we shouldn’t put much efforts in to support.
>> 
>> That may well be true.
>> 
>>> 
 
> I’ve shortly discussed it with other community members in the XSF 
> chatroom [1], but thought I’d bring it up here for discussion with a 
> wider audience, while providing a short summary of the room discussions 
> below:
> 
> When would a client send an correction for a message from another account 
> resource? Two cases come to mind:
> a) Carbons, editing a message from another client when you switch clients 
> mid-discussion.
 
 Certainly in this case we’d want to be able to correct them.
 
> b) Reconnection, where a client has the server assign it a resource.
 
 Which is more or less the same instance as (a), I think.
 
> What do you think? Do you have further comments on this issue?
 
 I think there’s also a concern that different resources may use the same 
 IDs. Perhaps we should be moving away from using stanza IDs for this, and 
 move towards something like 359 (although 359 has the client-id, stanza-id 
 oddity which we should probably fix at some point and just use multiple 
 stanza-id stamps with the relevant ‘by’ instead).
>>> 
>>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide 
>>> a solution if we can’t rely on unique and stable stanza IDs. It’s not 
>>> discussed in XEP-0359, but I guess it’s the reason for its existence, that 
>>> stanza IDs may only be stable/unique regarding one XMPP stream and might 
>>> change in a multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> 
>>> MUC -> S-to-C.
>> 
>> Sadly not, 6121 says
>> " It is up to the originating entity whether the value of the 'id'
>>   attribute is unique only within its current stream or unique
>>   globally.”
> 
> So, basically XEP-0308 should adopt XEP-0359 in a new version (probably 
> requires namespace version bump) and use the sender's ID for replacements? Is 
> that what you suggest?

It doesn’t seem to be a stupid approach, to me, at least. It has the advantage 
of working in MUCs that do stanza id rewriting, too, as well as working through 
MAM and Carbons, etc.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Tobias M]

> On 28 Sep 2016, at 18:38, Kevin Smith  wrote:
> 
> On 27 Sep 2016, at 10:06, Tobias M  > wrote:
>> 
>> 
>>> On 27 Sep 2016, at 00:33, Kevin Smith >> > wrote:
>>> 
 However, it has little discussion on why there is this restriction. While 
 it certainly is a MUST for security reasons in MUC situations where 
 different full JIDs are different accounts (i.e. associated to different 
 bare JIDs), it is less so for security reasons in the non-MUC case.
>>> 
>>> I think one can construct other situations like MUC, where multiple people 
>>> control different resources of the same bare JID, but maybe that’s 
>>> pathological (although I’m not sure).
>> 
>> If multiple people would use different resources of the same bare JID, this 
>> would also lead to strange UX regarding Carbons where the user will see 
>> messages as sent which they didn’t write. I think this is a rather rare edge 
>> case we shouldn’t put much efforts in to support.
> 
> That may well be true.
> 
>> 
>>> 
 I’ve shortly discussed it with other community members in the XSF chatroom 
 [1], but thought I’d bring it up here for discussion with a wider 
 audience, while providing a short summary of the room discussions below:
 
 When would a client send an correction for a message from another account 
 resource? Two cases come to mind:
 a) Carbons, editing a message from another client when you switch clients 
 mid-discussion.
>>> 
>>> Certainly in this case we’d want to be able to correct them.
>>> 
 b) Reconnection, where a client has the server assign it a resource.
>>> 
>>> Which is more or less the same instance as (a), I think.
>>> 
 What do you think? Do you have further comments on this issue?
>>> 
>>> I think there’s also a concern that different resources may use the same 
>>> IDs. Perhaps we should be moving away from using stanza IDs for this, and 
>>> move towards something like 359 (although 359 has the client-id, stanza-id 
>>> oddity which we should probably fix at some point and just use multiple 
>>> stanza-id stamps with the relevant ‘by’ instead).
>> 
>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide 
>> a solution if we can’t rely on unique and stable stanza IDs. It’s not 
>> discussed in XEP-0359, but I guess it’s the reason for its existence, that 
>> stanza IDs may only be stable/unique regarding one XMPP stream and might 
>> change in a multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> 
>> MUC -> S-to-C.
> 
> Sadly not, 6121 says
> " It is up to the originating entity whether the value of the 'id'
>   attribute is unique only within its current stream or unique
>   globally.”

So, basically XEP-0308 should adopt XEP-0359 in a new version (probably 
requires namespace version bump) and use the sender's ID for replacements? Is 
that what you suggest?

Cheers,
Tobi___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 27 Sep 2016, at 10:06, Tobias M  wrote:
> 
> 
>> On 27 Sep 2016, at 00:33, Kevin Smith  wrote:
>> 
>>> However, it has little discussion on why there is this restriction. While 
>>> it certainly is a MUST for security reasons in MUC situations where 
>>> different full JIDs are different accounts (i.e. associated to different 
>>> bare JIDs), it is less so for security reasons in the non-MUC case.
>> 
>> I think one can construct other situations like MUC, where multiple people 
>> control different resources of the same bare JID, but maybe that’s 
>> pathological (although I’m not sure).
> 
> If multiple people would use different resources of the same bare JID, this 
> would also lead to strange UX regarding Carbons where the user will see 
> messages as sent which they didn’t write. I think this is a rather rare edge 
> case we shouldn’t put much efforts in to support.

That may well be true.

> 
>> 
>>> I’ve shortly discussed it with other community members in the XSF chatroom 
>>> [1], but thought I’d bring it up here for discussion with a wider audience, 
>>> while providing a short summary of the room discussions below:
>>> 
>>> When would a client send an correction for a message from another account 
>>> resource? Two cases come to mind:
>>> a) Carbons, editing a message from another client when you switch clients 
>>> mid-discussion.
>> 
>> Certainly in this case we’d want to be able to correct them.
>> 
>>> b) Reconnection, where a client has the server assign it a resource.
>> 
>> Which is more or less the same instance as (a), I think.
>> 
>>> What do you think? Do you have further comments on this issue?
>> 
>> I think there’s also a concern that different resources may use the same 
>> IDs. Perhaps we should be moving away from using stanza IDs for this, and 
>> move towards something like 359 (although 359 has the client-id, stanza-id 
>> oddity which we should probably fix at some point and just use multiple 
>> stanza-id stamps with the relevant ‘by’ instead).
> 
> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide a 
> solution if we can’t rely on unique and stable stanza IDs. It’s not discussed 
> in XEP-0359, but I guess it’s the reason for its existence, that stanza IDs 
> may only be stable/unique regarding one XMPP stream and might change in a 
> multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> MUC -> S-to-C.

Sadly not, 6121 says
 " It is up to the originating entity whether the value of the 'id'
   attribute is unique only within its current stream or unique
   globally.”

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Tobias M]

> On 27 Sep 2016, at 00:33, Kevin Smith  wrote:
> 
>> However, it has little discussion on why there is this restriction. While it 
>> certainly is a MUST for security reasons in MUC situations where different 
>> full JIDs are different accounts (i.e. associated to different bare JIDs), 
>> it is less so for security reasons in the non-MUC case.
> 
> I think one can construct other situations like MUC, where multiple people 
> control different resources of the same bare JID, but maybe that’s 
> pathological (although I’m not sure).

If multiple people would use different resources of the same bare JID, this 
would also lead to strange UX regarding Carbons where the user will see 
messages as sent which they didn’t write. I think this is a rather rare edge 
case we shouldn’t put much efforts in to support.

> 
>> I’ve shortly discussed it with other community members in the XSF chatroom 
>> [1], but thought I’d bring it up here for discussion with a wider audience, 
>> while providing a short summary of the room discussions below:
>> 
>> When would a client send an correction for a message from another account 
>> resource? Two cases come to mind:
>> a) Carbons, editing a message from another client when you switch clients 
>> mid-discussion.
> 
> Certainly in this case we’d want to be able to correct them.
> 
>> b) Reconnection, where a client has the server assign it a resource.
> 
> Which is more or less the same instance as (a), I think.
> 
>> What do you think? Do you have further comments on this issue?
> 
> I think there’s also a concern that different resources may use the same IDs. 
> Perhaps we should be moving away from using stanza IDs for this, and move 
> towards something like 359 (although 359 has the client-id, stanza-id oddity 
> which we should probably fix at some point and just use multiple stanza-id 
> stamps with the relevant ‘by’ instead).

Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide a 
solution if we can’t rely on unique and stable stanza IDs. It’s not discussed 
in XEP-0359, but I guess it’s the reason for its existence, that stanza IDs may 
only be stable/unique regarding one XMPP stream and might change in a multi-hop 
routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> MUC -> S-to-C.

Cheers,
Tobi___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

> On 16 Sep 2016, at 12:39, Tobias M  wrote:
> 
> Hi,
> 
> Under 4. Business Rules XEP-0308 mentions:
> 
>> A correction MUST only be allowed when both the original message and 
>> correction are received from the same full-JID.
> 
> However, it has little discussion on why there is this restriction. While it 
> certainly is a MUST for security reasons in MUC situations where different 
> full JIDs are different accounts (i.e. associated to different bare JIDs), it 
> is less so for security reasons in the non-MUC case.

I think one can construct other situations like MUC, where multiple people 
control different resources of the same bare JID, but maybe that’s pathological 
(although I’m not sure).

> I’ve shortly discussed it with other community members in the XSF chatroom 
> [1], but thought I’d bring it up here for discussion with a wider audience, 
> while providing a short summary of the room discussions below:
> 
> When would a client send an correction for a message from another account 
> resource? Two cases come to mind:
> a) Carbons, editing a message from another client when you switch clients 
> mid-discussion.

Certainly in this case we’d want to be able to correct them.

> b) Reconnection, where a client has the server assign it a resource.

Which is more or less the same instance as (a), I think.

> What do you think? Do you have further comments on this issue?

I think there’s also a concern that different resources may use the same IDs. 
Perhaps we should be moving away from using stanza IDs for this, and move 
towards something like 359 (although 359 has the client-id, stanza-id oddity 
which we should probably fix at some point and just use multiple stanza-id 
stamps with the relevant ‘by’ instead).

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Georg Lukas]

* Dumaine, Xander  [2016-09-20 19:20]:
> While I can understand the use case, I also believe it’s low value compared 
> to potentially negative consequences.

I'm interested in the possible side effects. Could you please outline
the potential consequences you see?

Georg


signature.asc
Description: Digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Dumaine, Xander]

While I can understand the use case, I also believe it’s low value compared to 
potentially negative consequences. I think at most this could change from MUST 
to SHOULD in order to encourage the full-jid restriction, and prevent the can 
of worms from opening too far, but allowing the use case for implementations 
that choose to allow the use case.


Thanks,
Xander Dumaine


On September 20, 2016 at 2:09:18 AM, Georg Lukas 
(ge...@op-co.de) wrote:

* Tobias M  [2016-09-16 13:41]:
> What would speak for allowing edits across resources:

+1 for allowing this use case. I think it would improve the consistency
of the XMPP UX, and increase user confidence.

> Another case is where a server sends different carbons messages to different 
> resources. Some think allowing cross-resource corrections will open a can of 
> worms.

I think that LMC is already a huge can of worms, and should be treated
accordingly by clients. If your client B sees a different message from
what you sent from client A, and you LMC that message on B, you are
probably already aware of the differences.


Georg
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Georg Lukas]

* Tobias M  [2016-09-16 13:41]:
> What would speak for allowing edits across resources:

+1 for allowing this use case. I think it would improve the consistency
of the XMPP UX, and increase user confidence.

> Another case is where a server sends different carbons messages to different 
> resources. Some think allowing cross-resource corrections will open a can of 
> worms.

I think that LMC is already a huge can of worms, and should be treated
accordingly by clients. If your client B sees a different message from
what you sent from client A, and you LMC that message on B, you are
probably already aware of the differences.


Georg


signature.asc
Description: Digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___