Re: [Standards] XEP-0045 join when already in MUC

2016-06-23 Thread Kevin Smith
> On 23 Jun 2016, at 23:35, Georg Lukas wrote: > > Hi, > > TL;DR: whenever a client (re)sends a join, the MUC service should return > everything a newly joining client needs to know. > > According to XEP-0045, an initial join presence needs to contain an 'x' > element with 'http://jabber.org/p

Re: [Standards] XEP-0045 join when already in MUC

2016-06-23 Thread Daniel Gultsch
+1 from end. Please create a PR. ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___

Re: [Standards] XEP-0045 join when already in MUC

2016-06-23 Thread Emmanuel Gil Peyrot
On Fri, Jun 24, 2016 at 12:05:46PM +1000, Daurnimator wrote: > On 24 June 2016 at 08:35, Georg Lukas wrote: > > Hi, > > > > TL;DR: whenever a client (re)sends a join, the MUC service should return > > everything a newly joining client needs to know. > > > > According to XEP-0045, an initial join p

Re: [Standards] XEP-0045 join when already in MUC

2016-06-23 Thread Daurnimator
On 24 June 2016 at 08:35, Georg Lukas wrote: > Hi, > > TL;DR: whenever a client (re)sends a join, the MUC service should return > everything a newly joining client needs to know. > > According to XEP-0045, an initial join presence needs to contain an 'x' > element with 'http://jabber.org/protocol/

Re: [Standards] Mediated MUC invitations for someone already in room

2016-06-23 Thread Daurnimator
On 24 June 2016 at 02:17, Brian Cully wrote: > OTOH, since it’s a mediated invitation, the MUC service already has > state about pending invitations and room occupants. It is not required for a room to store any information about pending invitations. _

[Standards] XEP-0045 join when already in MUC

2016-06-23 Thread Georg Lukas
Hi, TL;DR: whenever a client (re)sends a join, the MUC service should return everything a newly joining client needs to know. According to XEP-0045, an initial join presence needs to contain an 'x' element with 'http://jabber.org/protocol/muc' namespace (§7.2.2), whereas a regular presence update

[Standards] Mediated MUC invitations for someone already in room

2016-06-23 Thread Brian Cully
It’s currently unspecified in XEP-0045 § 7.8.2 what should be done when multiple mediated invitations are sent, or when an invitation is sent to someone already in the room. Part of me wants to just duplicate the wording in XEP-0249 § 4[1], because it’s fairly straight forward o

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

2016-06-23 Thread Kevin Smith
On 23 Jun 2016, at 15:02, Sam Whited wrote: > > On Thu, Jun 23, 2016 at 2:49 AM, Florian Schmaus wrote: >> I also still think that we should clarify somewhere if the carbons state >> is kept after a stream resumption or not [1]. Not sure if the right >> place for this would be xep280 or xep198.

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

2016-06-23 Thread Sam Whited
On Thu, Jun 23, 2016 at 2:49 AM, Florian Schmaus wrote: > I also still think that we should clarify somewhere if the carbons state > is kept after a stream resumption or not [1]. Not sure if the right > place for this would be xep280 or xep198. I think the place for this is in Stream Management (

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

2016-06-23 Thread Florian Schmaus
On 22.06.2016 18:16, Peter Saint-Andre wrote: > On 6/22/16 10:06 AM, Georg Lukas wrote: >> * Peter Saint-Andre [2016-06-22 17:44]: >>>A is not eligible for carbons delivery if it is >>>determined to have been sent by a MUC room or service, even if it >>>would be otherwise eligible (th