* Florian Schmaus [2018-04-12 09:28]:
> A different approach would be to define an am-I-still-here IQ send to
> the bare MUC address:
Yes, this was one of my initial proposals in the October mail.
> Advantages I see here is
> - The MUC does not intercept IQs
This is not quite true. A MUC must i
On 11.04.2018 21:46, Georg Lukas wrote:
> * Florian Schmaus [2018-04-11 19:07]:
>>> If Juliet is not joined, the MUC will respond with
>>> .
>> I feel like this is missing "or if the ping request does not originate
>> from Juliet". Or is this intentional?
>
> Responding with is the correct behav
* Florian Schmaus [2018-04-11 19:07]:
> > If Juliet is not joined, the MUC will respond with
> > .
> I feel like this is missing "or if the ping request does not originate
> from Juliet". Or is this intentional?
Responding with is the correct behavior for messages
sent to a participant while not
On 10.04.2018 15:08, Georg Lukas wrote:
> * Georg Lukas [2017-10-04 10:21]:
>> 2. Create a new, explicit am-I-joined IQ that a client can send to the
>>MUC JID.
>
> This seems to be the winner of the discussion from last October, even
> though it was qualified as a "sticking plaster".
>
> To
Resurrecting the self-ping thread in light of the current Council agenda
item.
* Georg Lukas [2017-10-04 10:21]:
> 2. Create a new, explicit am-I-joined IQ that a client can send to the
>MUC JID.
This seems to be the winner of the discussion from last October, even
though it was qualified as
On Donnerstag, 5. Oktober 2017 12:20:12 CET Kevin Smith wrote:
> > On 5 Oct 2017, at 11:39, Jonas Wielicki wrote:
> >
> > On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote:
> I think
> that “presence things with magic side effects” is one of the problems
> we
> have
Sat, 7 Oct 2017 16:11:49 +0200
Georg Lukas wrote:
> What about RFC 6120, §8.2.3?
I know about this rule, but it doesn't make sense for self-IQs, because
it breaks no compatibility.
> Also, one of the proposals actually was an IQ sent to the MUC JID
> instead of the self-JID, which would be a be
* Evgeny Khramtsov [2017-10-07 15:45]:
> No, you can filter out incoming self-IQs, nobody requires you to reply.
What about RFC 6120, §8.2.3? "An entity that receives an IQ request of
type "get" or "set" MUST reply with an IQ response of type "result" or
"error". The response MUST preserve the 'i
Sat, 7 Oct 2017 09:56:38 +0200
Florian Schmaus wrote:
> Would that require a namespace bump?
What Georg said.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
__
Sat, 7 Oct 2017 10:12:14 +0200
Georg Lukas wrote:
> Even if we mandate that self-IQs have to be reflected to the sender,
> it's still two round-trips just to figure out if we are still joined:
>
> c->s: ping
> c<-s: ping reflection
> c->s: pong
> c<-s: pong reflection
No, you can filter out inc
* Florian Schmaus [2017-10-07 09:58]:
> > Can be fixed by specifying the server rules for such self-IQs, i.e.
> > resources in 'from' and 'to' should match.
Even if we mandate that self-IQs have to be reflected to the sender,
it's still two round-trips just to figure out if we are still joined:
On 07.10.2017 08:27, Evgeny Khramtsov wrote:
> Wed, 4 Oct 2017 10:19:47 +0200
> Georg Lukas wrote:
>
>> (*) poezio and yaxim solve that by sending a 0199 ping to your own
>> participant JID. However, in Multi-Session Nick scenarios, the ping IQ
>> will be routed to a "random" client of yours, and
Wed, 4 Oct 2017 10:19:47 +0200
Georg Lukas wrote:
> (*) poezio and yaxim solve that by sending a 0199 ping to your own
> participant JID. However, in Multi-Session Nick scenarios, the ping IQ
> will be routed to a "random" client of yours, and if that client is
> currently suffering from a bad co
> TL;DR: checking if you are still in a MUC is broken
> Workaround: none. Burn GC1.0 with fire.
Please, burn MUC with fire. MUC is broken by concept, it is just a prototype
which emulates IRC channel.
There was some users in the start of the century who can be attracted by this
great decoy, bu
On 5 Oct 2017, at 12:51, Kim Alvefur wrote:
>
> On Thu, Oct 05, 2017 at 12:20:12PM +0100, Kevin Smith wrote:
>>
>>> On 5 Oct 2017, at 11:39, Jonas Wielicki wrote:
>>>
>>> On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote:
>> I think
>> that “presence things with magic side e
On Thu, Oct 05, 2017 at 12:20:12PM +0100, Kevin Smith wrote:
>
> > On 5 Oct 2017, at 11:39, Jonas Wielicki wrote:
> >
> > On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote:
> I think
> that “presence things with magic side effects” is one of the problems we
> have with
> On 5 Oct 2017, at 11:39, Jonas Wielicki wrote:
>
> On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote:
I think
that “presence things with magic side effects” is one of the problems we
have with MUC, so adding more such things isn’t what I’d choose when
addressing
On Donnerstag, 5. Oktober 2017 12:39:38 CEST Jonas Wielicki wrote:
> One idea I have is to use (2), but also specify a new feature and
> payload for MUC (let’s call it ). A MUC service would
> handle it as follows:
>
> 1. If the sender is currently joined, the presence is handled as usual.
> 2. I
On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote:
> On 4 Oct 2017, at 16:41, Jonas Wielicki wrote:
> > On Mittwoch, 4. Oktober 2017 16:08:43 CEST Kevin Smith wrote:
> >> OTOH, (2) simply requires the MUC
> >> code to send an iq, which is presumably straightforward for the majority
> >>
> On 4 Oct 2017, at 16:41, Jonas Wielicki wrote:
>
> On Mittwoch, 4. Oktober 2017 16:08:43 CEST Kevin Smith wrote:
>>> On 4 Oct 2017, at 14:07, Georg Lukas wrote:
>>>
>>> Hi Kev,
>>>
>>> * Kevin Smith [2017-10-04 11:43]:
Thanks for the write-up. I agree this is a problem worth solving.
On Mittwoch, 4. Oktober 2017 16:08:43 CEST Kevin Smith wrote:
> > On 4 Oct 2017, at 14:07, Georg Lukas wrote:
> >
> > Hi Kev,
> >
> > * Kevin Smith [2017-10-04 11:43]:
> >> Thanks for the write-up. I agree this is a problem worth solving.
> >
> > Thanks for the feedback!
> >
> >> I think (3)
> On 4 Oct 2017, at 14:07, Georg Lukas wrote:
>
> Hi Kev,
>
> * Kevin Smith [2017-10-04 11:43]:
>> Thanks for the write-up. I agree this is a problem worth solving.
>
> Thanks for the feedback!
>
>> I think (3) seems like it has nice properties in terms of a single
>> round-trip, but I think
Hi Kev,
* Kevin Smith [2017-10-04 11:43]:
> Thanks for the write-up. I agree this is a problem worth solving.
Thanks for the feedback!
> I think (3) seems like it has nice properties in terms of a single
> round-trip, but I think (2) is the preferable option in practice. It’s
> simple to implem
> On 4-Oct-2017, at 05:42, Kevin Smith wrote:
>
> Thanks for the write-up. I agree this is a problem worth solving.
>
> I think (3) seems like it has nice properties in terms of a single
> round-trip, but I think (2) is the preferable option in practice. It’s simple
> to implement for everyon
On 4 Oct 2017, at 09:19, Georg Lukas wrote:
>
> Hi,
>
> TL;DR: checking if you are still in a MUC is broken and needs to be
> fixed, either with new IQs or with a new rejoin-if-needed presence.
>
>
> MUC presence tends to break
> ===
>
> Most of us have experienced thi
On Mittwoch, 4. Oktober 2017 10:19:47 CEST Georg Lukas wrote:
> [… snip: excellent summary of the issue …]
>
> Proposed Solutions
> ==
>
> All of the following change behavior and would need to be feature-coded
> in the MUC/service caps:
>
> 1. Mandate different response codes to
26 matches
Mail list logo
