> 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
+1 from end. Please create a PR.
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
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
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/
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.
_
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
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
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.
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 (
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
10 matches
Mail list logo