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

I agree with Kev. If an entity does not wish to expose its address, it can simply choose to not provide the 'by' attribute. There's need to explicitly define the client/server role in that action too, right? - Guus On 29 September 2016 at 20:18, Kevin Smith wrote: > On 29 Sep 2016, at 19:08, F

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

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, q

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

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

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

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 a

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

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' a

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

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 servin

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

On 29 Sep 2016, at 18:22, Guus der Kinderen wrote: > 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 > servin

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

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? Regards, Guus

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

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

Re: [Standards] OpenPGP IM: all stanza types supported?

Hey Florian, thanks for your feedback. > Yes and No. XEP-0373 defines an extension element called > which carries OpenPGP encrypted and/or signed data. It does not talk > about (full or not full) stanza encryption per se, although full stanza > OpenPGP encryption using the element would be poss

Re: [Standards] OpenPGP IM: all stanza types supported?

On 29.09.2016 00:00, Fabian Beutel wrote: > First, did I interpret the OpenPGP-XEP-0373/374 correctly that any > stanza can be encrypted and not only messages? Yes and No. XEP-0373 defines an extension element called which carries OpenPGP encrypted and/or signed data. It does not talk about (full

Re: [Standards] XEP-0369 (MIX) - approach to Channel invitation

On 29 September 2016 at 09:41, Kevin Smith wrote: > On 27 Sep 2016, at 17:18, Sam Whited wrote: >> >> On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille wrote: >>> A simple approach to address this more complex scenario is a two-step >>> approach where the inviter starts by sending a message to the ch

Re: [Standards] XEP-0369 (MIX) - approach to Channel invitation

On 27 Sep 2016, at 17:18, Sam Whited wrote: > > On Tue, Sep 27, 2016 at 3:30 AM, Steve Kille wrote: >> A simple approach to address this more complex scenario is a two-step >> approach where the inviter starts by sending a message to the channel to >> grant the invitee rights to join the channel