Re: [Standards] Clarification on iq routing in semi-anonymous MUCs

[Jonas Schäfer]

On Sonntag, 6. Oktober 2019 17:15:11 CET Marvin W wrote:
> Hi,
> 
> On 06.10.19 14:46, Jonas Schäfer wrote:
> >> Currently server implementations seem to have diverting behavior in this
> >> regard: ejabberd and Prosody<0.11 route IQs to the full JID (any of them
> >> if there are multiple) except if the IQ contains a vCard query, which is
> >> send to the bare JID. Prosody 0.11+ routes PubSub IQs to the bare JID.
> >> ejabberd allows to disable IQ forwarding on a per room basis
> >> (allow_query_users config).
> > 
> > FTR, this is, as all of Multi-Session Nick, implementation-defined land.
> > We
> > should probably clean this up indeed.
> > 
> >> What is supposed to be the correct behavior? Can we clarify in
> >> XEP-0045§17.4 how to correctly route IQs in a MUC?
> > 
> > Yes please, also Multi-Session Nick in general. It is a dark field of
> > things which is mostly passed on by tribal knowledge.
> > 
> > I wonder whether it would make sense to mix both into the same add-on XEP.
> 
> I don't think that multi session nicks and iq routing are directly
> related. Routing IQs to bare vs full jid makes a huge difference even in
> single sessions.
> 
> Intuitively, if we wouldn't have multi-session nicks, I would argue that
> IQs are to be routed to the full JID, because that's the same as
> messages and there is no indication in XEP-0045 that IQs MAY be handled
> differently, although there also isn't any explicit mention that they
> SHOULD NOT.
> 
> However with multi-session nicks, IQ routing to the full JID makes less
> sense, because there are multiple of them, so it is somehow related. In
> fact in the wiki there is https://wiki.xmpp.org/web/Multi-Session_Nicks
> which has a section on IQ routing, asking IQs to be routed to one of the
> connected full JIDs
> 
> I think we should
> a) Clarify the routing of IQs in XEP-0045 or at least clarify that IQ
> routing in MUCs is intended to be undefined behavior in XEP-0045 but
> might be defined in other XEPs.
> b) Write down the rules of multi session nicks (including IQ routing) in
> a new XEP

I agree.

> One additional idea regarding IQ routing (and probably terribly
> over-engineered) would be that the occupant somehow indicates how they
> want their incoming IQs to be routed. This could even be statements like
> "route vcard requests to bare jid, route pings to full jid and
> ignore/error everything else". In multi session nick scenarios one could
> even combine these statements so that some iqs are forwarded to bare,
> some to full jid A and some to full jid B. - But if we do this, it
> probably does not belong into XEP-0045...

I’m pretty sure that we should not do this. This is, indeed, terribly over-
engineered, and at the risk of sounding like part of a huge, unlikeable herd: 
This is hopefully not going to be a problem with MIX anymore, since resources 
of members (and the bare JID itself) can be fully addressed there.

Writing down how we want things to currently happen in XEP-0045 and slapping a 
feature var on it is probably a good idea. Going full in and trying to find 
another solution to the "multiple entities behind an address" problem, 
probably not.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Bookmarks 2 extensibility

[Dave Cridland]

On Wed, 4 Dec 2019 at 21:07, Florian Schmaus  wrote:

> On 26.11.19 20:48, Dave Cridland wrote:
> >
> >
> > On Tue, 26 Nov 2019 at 18:46, Florian Schmaus  > > wrote:
> >
> > On 25.11.19 14:16, Dave Cridland wrote:
> > > As a general rule, I think clients need to try and
> > preserve unknown XML
> > > nodes in data they manipulate. This goes for PEP data, roster
> > data, and
> > > all sorts.
> >
> > I don't share that sentiment. Clearly XMPP entities need to simply
> > ignore unknown extension elements if they are just consuming them.
> But
> > in cases where entities are modifying elements, like roster data,
> > demanding that they have to replay also all unknown extension
> elements
> > is, among other things, dangerous: One rotten apple could destroy the
> > whole batch. That is, one misbehaving client could ruin everything.
> That
> > is why I hope that we will never put extension elements in roster
> > s that the client needs to replay [1].
> >
> > In such cases I instead favour the approach Emmanuel suggests:
> clearly
> > define extension points and explicitly state the requirement to
> > handle/preserve unknown XML in the specification.
> >
> >
> > OK - I disagree, but I also think this is an acceptable compromise.
> >
> > Should server-generated metadata also have a container element, so that
> > clients know it can be ignored and must not be replayed?
> >
> > Should these elements be generic elements, common across all cases, or
> > do we make them individually each time?
>
> Good questions. I do not have a strong opinion regarding the answer.
> Mostly because I can not come up with an example or reason that
> demonstrates that there is value in having a generic element or a
> container element for server-generated metadata. That does not mean that
> such a thing does not exists though.
>
>
I think the summary, then, is that:

* Some elements are part of the core specification and must always be
preserved.
* Some elements are private client extensions and must be preserved
unchanged by other clients.
* Some elements are server-driven extensions and should not be preserved
explicitly by the client, and may be ignored.

My gut feeling is that the latter two ought to sit in a container element,
to provide the most flexible solution.

If that sounds right, I'll prepare a PR.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Resurrecting Reactions

[Dave Cridland]

On Tue, 3 Dec 2019 at 20:51, Marvin W  wrote:

> I'd like the council to re-evaluate granting Experimental status to the
> proposed XEP. As per XEP-0001, "the granting of Experimental status must
> not be construed as indicating any level of approval by the XSF, the
> XMPP Council, or the XMPP developer community". If any of the council
> members prefers to refuse granting experimental status at this point,
> please give clear guidance on how to further process bringing this
> feature to XMPP in form of a XEP that can be implemented in practice.
>

I really dislike the notion of asking Council to essentially revote on
something a couple of months after rejecting it.

I disagreed with the decision the Council made in rejecting Reactions - in
fact, all bar one Council member voted in favour of it. Nevertheless, we do
not operate the Council on a simple majority basis - instead each Council
member has a veto to use to block adoption of new specifications and no
restraint placed upon this. So whether I agree with the reasoning or not is
somewhat irrelevant, as is the question of whether the members of the new
Council would have voted differently. Whatever the individual members of
Council choose to do, the decision of Council deserves some collective
responsibility.

Allowing decisions to be revisited after a couple of months merely because
there are new Council members who might see it your way now is, therefore,
a dangerous path. Therefore I will resist strongly any attempts to "wait
out" a Council or otherwise circumvent its decisions.

I think it'd be better if we considered the question of how to meet the
Council's overall verdict - that we need to have a generic and unified way
of specifying that a message relates to, and is subordinate to, another. I
desperately want to address Reactions in our standards suite, and while I
would have been fine accepting it as-is, I do nevertheless accept and
indeed agree that the general problem exists and needs addressing.

Various client implementers have noted that the nature of an
ever-increasing number of these ancillary messages means that MAM is
eroding in utility, as a request for the previous N messages gets, instead,
N receipts, reactions, and so on. Similar functionality, such as inboxes
etc, also suffers. The current solution server-side is to have the server
"know" what each ancillary message looks like - but this is both
unsustainable and undesirable, since we don't want to require a server
upgrade each time a new one is added.

I appreciate that your (and other) comments were left unacknowledged on
Fastening. While I hope you appreciate that we are all volunteers here
(even those who work on XMPP systems for a living), I'm obviously keen that
we can unblock this conversation again and seek some constructive progress.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX-PAM: private PEP node for joined channels

[Jonas Schäfer]

On Montag, 9. Dezember 2019 11:39:17 CET Matthew Wild wrote:
> > [...] Note
> > however that MAM silently treats the case of "the last stanza you saw
> > expired from the archive" as "fetch everything since beginning of
> > archives", which means you won’t notice that you lost notifications when
> > using MAM (with expiry) for sync.
> 
> It's true that originally there was no error specified in this case,
> but that's not the case in the latest version of the XEP:
> https://xmpp.org/extensions/xep-0313.html#query-paging

Agh you caught me. I meant to double-check that paragraph against the specs 
before sending, but I simply forgot. Thanks for clarifying. So at least with a 
MAM-ish thing, we’d be able to know that we need to do a full resync.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX-PAM: private PEP node for joined channels

[Daniel Gultsch]

Am Mo., 9. Dez. 2019 um 10:13 Uhr schrieb Jonas Schäfer :

> I think what Daniel says is sound. I also think that we don’t have to solve
> versioning *right now*. We should provision this, by adding a `ver` attribute
> with the following (initial semantics):

I case this wasn’t obvious from my initial post that was my thinking
as well; We wouldn’t have to solve this now and could finally continue
working on MIX; but also have a path to add versioning later.

That sounds much more convenient that figuring out how to do that with PubSub.

I mean I'm all for reusing tools; but if we have to change the tools
first to be able to use them it might be a good idea to reconsider
that.


cheers
Daniel
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX-PAM: private PEP node for joined channels

[Matthew Wild]

Hi Jonas,

A couple of observations about your post follow below, though not to
say I agree or disagree with your overall position (I need to think
about this issue more).

On Mon, 9 Dec 2019 at 10:12, Jonas Schäfer  wrote:
>

> 1. Current state of archiving in PEP

> So the state transfer must be initiated by the client (with the client telling
> whichever entity keeps the history what its last state was). This is like
> roster versioning.

Yes, something like roster versioning for pubsub would be interesting
in general.

> This could be via a MAM archive which holds the notifications of the PubSub
> node (either the user’s archive, but see what Holger said, or an archive on
> the PEP node itself, which is unheard of so far, as far as I know). [...]

Yes, unheard of as far as I know. It would be tricky because PEP nodes
don't have their own JID, a PEP service uses the user's JID (which
typically already has a MAM archive).

> [...] Note
> however that MAM silently treats the case of "the last stanza you saw expired
> from the archive" as "fetch everything since beginning of archives", which
> means you won’t notice that you lost notifications when using MAM (with
> expiry) for sync.

It's true that originally there was no error specified in this case,
but that's not the case in the latest version of the XEP:
https://xmpp.org/extensions/xep-0313.html#query-paging

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX-PAM: private PEP node for joined channels

[Jonas Schäfer]

This is a length response. Table of contents:

1. Current state of archiving in PEP
2. Argument in favour of custom IQ-based wire protocol

On Donnerstag, 21. November 2019 21:20:30 CET Linus Jahn wrote:
> On Thu, 21 Nov 2019 11:51:11 +0100 Holger Weiß  
wrote:
> > * Daniel Gultsch  [2019-11-20 21:49]:
> > > Am Mi., 20. Nov. 2019 um 20:45 Uhr schrieb Linus Jahn
> > > 
> > > :
> > > > Also the 'blocking command' way isn't so flexible. Ideally I
> > > > would like to send one request to the server to receive all
> > > > updates of all of my implicitly subscribed nodes after logging
> > > > in. (I'm not entirely sure whether this is currently possible
> > > > with PEP and MAM though?)
> > > 
> > > "Give me the delta" is currently not (properly?) specified in
> > > PubSub.
> > 
> > There's XEP-0312 (PubSub Since), but that's timestamp-based.
> > 
> > I guess you wouldn't want to base queries on item IDs, as items may be
> > overwritten.  So maybe you'd want PubSub-MAM indeed?  Or just make
> > sure notifications end up in the user archive?
> > 
> > Holger
> 
> How is archiving currently working with other PEP nodes?
> I can't image that a client has to e.g. load all avatar metadata (User
> Avatar) from all contacts at login to not miss updates that happened while
> it was offline.

1. Current state of archiving in PEP

It does not have to, but the crucial difference is that avatar metadata is 
only a single item.

You get a notification of the last published item when you come online (if you 
subscribe to that using XEP-0115), but you may not get notifications of all 
items which were published while your client was offline. This is handled by 
the PEP service itself.

The delta transmission can not be initiated by the PEP service itself; the PEP 
service can, in general, not recognize your client (since your resource may 
change), and it probably also doesn’t want to store the last known state of 
every client forever. In addition, in face of s2s outages or otherwise lost 
stanzas, this would be error-prone and fragile.

So the state transfer must be initiated by the client (with the client telling 
whichever entity keeps the history what its last state was). This is like 
roster versioning.

This could be via a MAM archive which holds the notifications of the PubSub 
node (either the user’s archive, but see what Holger said, or an archive on 
the PEP node itself, which is unheard of so far, as far as I know). Note 
however that MAM silently treats the case of "the last stanza you saw expired 
from the archive" as "fetch everything since beginning of archives", which 
means you won’t notice that you lost notifications when using MAM (with 
expiry) for sync.


2. Argument in favour of custom IQ-based wire protocol

I think what Daniel says is sound. I also think that we don’t have to solve 
versioning *right now*. We should provision this, by adding a `ver` attribute 
with the following (initial semantics):

- Clients MUST NOT set the attriubte. Servers MUST ignore the attribute if set 
and send the full roster list. Clients MUST NOT rely on this server behaviour, 
as it may be changed in the future.
- Servers SHOULD NOT set the ver attribute. Clients MUST ignore the ver 
attribute if it is set.

This wording should allow us to add roster versioning-like semantics on top of 
this without requiring a namespace bump.


Note that we’re only talking about wire format here. Wire format is cheap. 
Implementations are not.

If a server chooses to implement all of this with a hidden PEP-like node with 
MAM backing and later implement the versioning stuff by querying the MAM 
archive using the ver value, so be it. There is no reason why they should not 
be able to re-use those facilities; the only thing which changes is how the 
abstract data and events are serialised on the wire.

And I’d argue that using a separate wire format is the right thing because it 
helps to immediately trigger the right subsystem, as special handling of all 
commands related to this magic PEP node would be required.


kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___