Re: [Standards] XEP-0359 Client vs. non-client IDs

[Guus der Kinderen]

I appreciate the implementation-related argument too. I don't think that
that argument should outweigh the value of applying clear, concise
naming. Removing the "client/server" role is a big improvement there.
There's no use-case for this XEP where the 'by' is left out by an entity
that's not an 'origin' entity?

On 3 October 2016 at 11:11, Kevin Smith  wrote:

>
> > On 2 Oct 2016, at 18:46, Florian Schmaus  wrote:
> >
> > On 29.09.2016 20:18, Kevin Smith wrote:
> >> On 29 Sep 2016, at 19:08, Florian Schmaus  wrote:
> >>>
> >>> On 29.09.2016 19:22, Guus der Kinderen wrote:
>  Hi,
> 
>  What's the purpose of the distinction between "Unique Stanza IDs" and
>  "Client generated stanza IDs"? Why not add a unbounded list of
> stanza-id
>  elements (each with a unique 'by' attribute value), and not worry
> about
>  what entity is serving in a client-capacity?
> >>>
> >>> It was designed that way to avoid leaking the client's XMPP address in
> >>> cases like MUC. Notice that  has a 'by' attribute whereas
> >>>  has not. I should add that rationale to the XEP.
> >>
> >> That makes sense, but why not just say something like “the stanza-id
> without a by is the originating entity”.
> >
> > That's the other approach I could have taken when designing the protocol
> > (and I find myself often in the situation where I have to decide between
> > those two approaches when working on new extension protocols for XMPP).
> >
> > I personally find the variance it introduces, that the 'by' attribute
> > can either exit or not, less desirable. Instead I enjoy the fact that I
> > can look at the element's name and tell if it requires a non-empty 'by'
> > attribute or that it must not have one. I find this preferable when
> > writing parsers, designing classes for extension elements (e.g. a method
> > "getBy()" will always return a JID for the class 
> > represents), or writing the XEP itself.
>
> I can buy that argument.
>
> >
> >> Else sometimes the orginating entity stamps with a client-id (when it’s
> a client) or doesn’t (when it’s a server), or you have servers stamping
> with client-id, or whatever.
> >
> > Fair point. How about 's/client-id/origin-id/‘?
>
> Or just origin? Either way, I think an improvement, yes.
>
> /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-0359 Client vs. non-client IDs

[Kevin Smith]

> On 2 Oct 2016, at 18:46, Florian Schmaus  wrote:
> 
> On 29.09.2016 20:18, Kevin Smith wrote:
>> On 29 Sep 2016, at 19:08, Florian Schmaus  wrote:
>>> 
>>> On 29.09.2016 19:22, Guus der Kinderen wrote:
 Hi,
 
 What's the purpose of the distinction between "Unique Stanza IDs" and
 "Client generated stanza IDs"? Why not add a unbounded list of stanza-id
 elements (each with a unique 'by' attribute value), and not worry about
 what entity is serving in a client-capacity?
>>> 
>>> It was designed that way to avoid leaking the client's XMPP address in
>>> cases like MUC. Notice that  has a 'by' attribute whereas
>>>  has not. I should add that rationale to the XEP.
>> 
>> That makes sense, but why not just say something like “the stanza-id without 
>> a by is the originating entity”.
> 
> That's the other approach I could have taken when designing the protocol
> (and I find myself often in the situation where I have to decide between
> those two approaches when working on new extension protocols for XMPP).
> 
> I personally find the variance it introduces, that the 'by' attribute
> can either exit or not, less desirable. Instead I enjoy the fact that I
> can look at the element's name and tell if it requires a non-empty 'by'
> attribute or that it must not have one. I find this preferable when
> writing parsers, designing classes for extension elements (e.g. a method
> "getBy()" will always return a JID for the class 
> represents), or writing the XEP itself.

I can buy that argument.

> 
>> Else sometimes the orginating entity stamps with a client-id (when it’s a 
>> client) or doesn’t (when it’s a server), or you have servers stamping with 
>> client-id, or whatever.
> 
> Fair point. How about 's/client-id/origin-id/‘?

Or just origin? Either way, I think an improvement, yes.

/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 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
___