Hi Sam! Thanks for your clarification, details and more clarification from my side below.
On Freitag, 16. Juli 2021 15:48:10 CEST Sam Whited wrote:
> On Fri, Jul 16, 2021, at 08:55, Jonas Schäfer wrote:
> > How is a nonza different from an IQ, if both happen post-resource-
> > binding, as I understand from your text?
>
> This is not what the PR says (see next section). I would be curious what
> made it sound like that though, this should be fixed but reading and re-
> reading it I can't find anything that makes me think this.
The text says:
A server that wishes to allow enabling carbons at the beginning of the
stream (immediately after resource binding) may advertise a stream feature
called "carbons" with the namespace "urn:xmpp:carbons:2".
The "immediately after resource binding" was which was led me to believe that
this was about enabling carbons, well, *after* resource binding, not before.
Now, re-reading your reply for the second time, together with the text of the
PR, I get what that refers to: It refers to the point at which carbons are
enabled, not when the nonza is sent! [insert jabber.org logo here]
> > If the nonza (from the stream feature) were allowed to be sent
> > *before* resource binding, then there would be an interesting case
> > where you could announce to the server that you want carbons before
> > the first message is delivered. It doesn't fix the issue with MAM, but
> > at least you know that from the point on your resource was bound, you
> > got a complete picture of all (carbons-eligible) messages received on
> > the account, which is somewhat nice.
>
> That is what I'm trying to fix here and exactly what this does. This is
> a stream feature that gets negotiated pre-reource-binding and enables
> carbons immediately after resource binding but before any stanzas can
> be received.
>
> > Though I should mention that you could also simply ignore all incoming
> > messages until you get a reply to your carbons IQ and you had
> > approximately the same sync point (due to the in-order requirement of
> > stanza processing in XMPP).
>
> Servers could do this if they *know* the client is planning on enabling
> carbons, but if that's the case they might as well just enable carbons
> from the get-go (and that will never be the case).
>
> If you mean that clients can do this then I don't understand how it
> would solve anything, they can just ignore messages, but that seems
> bad and carbons still wouldn't have been enabled for them which is
> the point.
The flow I had in mind was this:
1. install hook (in your client or library or whatever) which makes the
remainder of the program behave as if any inbound <message/> had never arrived
2. bind resource
3. enable carbons via IQ
4. when IQ response arrives, synchronously remove the hook
From (4) onward, it is exactly the same as if carbons had been enabled pre-
resource-binding, with the exception that your resource technically existed
prior to enabling carbons already. As you have not sent presence before, that
doesn't matter, as nobody knows about your resource anyway.
(All of this ignoring that pre-initial-presence, you may not receive any
messages at all, so you have that pre-inbound-message-post-resource-binding
opportunity to enable carbons anyway... Though I cannot find the reference
from RFC6121 which specifically says that you're not going to receive
messages; §8.5 is somewhat ambiguous to me as to whether a connected resource
is sufficient to receive messages as long as it hasn't announced negative
priority.)
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 _______________________________________________
