Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

[Florian Schmaus]

On 21/12/2022 14.49, Peter Waher wrote:

Hello


This specification defines a way for an XMPP entity to announce the

limits it will enforce for data received on a stream.


URL: https://xmpp.org/extensions/inbox/xep-sla.html 



This is a sorely needed extension. However, the proposal does not solve 
the more general problem of knowing the limitations when you communicate 
with another, only the size and time limits between immediately 
connected entities. A sender (client1) who needs to send something to 
another client (client2) passes one or two brokers (broker[1, broker2]), 
each one in this path might have different size limitations. A 
notification in the stream element does not resolve this more general 
problem. Furthermore, being constantly advertised in every request, 
creates a lot of extra bytes being communicated, with not added value, 
as the information is only needed once per limitation (best case).


Would it not be better with a statement in a service discovery response? 
There, each server/component/client can declare their limitations. Any 
change in limitation would change the hash in entities capabilities, 
which is already sent. So a change would be detected by all 
participants, without the added bytes each time an entity connects. 
Also, a service discovery mechanism, would allow an entity to query all 
participants in a route, to figure out what the limitations are along 
that particular route.


I can see the appeal of entities announcing the stanza size limit as 
part of their disco#info.


However, I wonder if many implementations would really put that 
information to a good use and implement a maximum stanza size discovery 
for a given path and adjust their behavior accordingly.


Really, the only robust way to deal with the stanza size limit is to 
take the lower bound for the maximum stanza size of 10 000 bytes, 
provided by the RFC, into account. Give a "little" room for stanza 
modifications on the path, allowing for additional elements to be added 
on the way, and send only stanzas of say, 4 KiB in size and you should 
be fine.


This, of course, requires that XMPP and its extensions is able to split 
request and result sets, and messages/notifications into smaller chunks. 
RSM certainly is helpful here, but I believe not everything we defined 
allows for a RSM-ish behavior.


For example, what if you discovered that the maximum stanza size of a 
path is M, but the user just typed a message with M+1 bytes? Split the 
user message into two message stanzas? What if the user later wants to 
revert or correct the message? What about reactions on that message?


I think the only reason we did not yet discuss those issues is that the 
maximum stanza size limit of most implementations is rather generous (I 
hear 128 KiB). And we can just live with the inadequateness of XMPP in 
this regard.


Zash's proposal is, as far as I understand it, just an optimization 
allowing a sending entity to determine if a stanza will hit the limit or 
not, without trying to actually send it.


And this goal is achieved with the proposed specification.

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

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

[Peter Waher]

Hello

> This specification defines a way for an XMPP entity to announce the
limits it will enforce for data received on a stream.
>
> URL: https://xmpp.org/extensions/inbox/xep-sla.html

This is a sorely needed extension. However, the proposal does not solve the 
more general problem of knowing the limitations when you communicate with 
another, only the size and time limits between immediately connected entities. 
A sender (client1) who needs to send something to another client (client2) 
passes one or two brokers (broker[1, broker2]), each one in this path might 
have different size limitations. A notification in the stream element does not 
resolve this more general problem. Furthermore, being constantly advertised in 
every request, creates a lot of extra bytes being communicated, with not added 
value, as the information is only needed once per limitation (best case).

Would it not be better with a statement in a service discovery response? There, 
each server/component/client can declare their limitations. Any change in 
limitation would change the hash in entities capabilities, which is already 
sent. So a change would be detected by all participants, without the added 
bytes each time an entity connects. Also, a service discovery mechanism, would 
allow an entity to query all participants in a route, to figure out what the 
limitations are along that particular route.

Best regards,
Peter Waher
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Council Agenda 2022-12-21

[Daniel Gultsch]

Good morning Council Members,

the next XMPP Council Meeting will take place today, Wednesday,
December 21st 2022 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join

The Agenda is as follows:

1) Roll call

2) Agenda Bashing

3) Editors update

a) NEW: XEP-0475 (Pubsub Signing) (https://xmpp.org/extensions/xep-0475.html)
b) NEW: XEP-0476 (Pubsub Signing: OpenPGP Profile)
(https://xmpp.org/extensions/xep-0476.html)
c) NEW: XEP-0477 (Pubsub Targeted Encryption)
(https://xmpp.org/extensions/xep-0477.html)


4) Items for voting

a) Proposed XMPP Extension: Stream Limits Advertisement
(https://xmpp.org/extensions/inbox/xep-sla.html)


5) Pending votes

none

See the all new Spreadsheet of Doom:
https://docs.google.com/spreadsheets/d/1Zp5FWJI0aubAL29LhrXkhc-MrZauJ1mtkVnm5TrtwLo/edit?usp=sharing

6) Date of Next

7) AOB

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

[Standards] XEP-0045: add MUC service shutdown example (pull request)

[Nicolas Cedilnik]

Hello all,

Following a discussion on jdev@ where Zash suggested that I added an 
example for something I had failed to understand by myself:


https://github.com/xsf/xeps/pull/1250

I think that even for a small change like that, sending an email here is 
to discuss is the appropriate workflow?


Cheers,

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

[Standards] XEP-0461 (Replies) pull request

[Nicolas Cedilnik]

Hello all,

I've submitted this PR about message replies: 
https://github.com/xsf/xeps/pull/1251


1. It was missing a disco#feature that I added.

2. The XEP required ("MUST") that the quoted author is referenced with a 
full JID, which I think makes sense in a groupchat context, but does not 
accomplishes much in 1:1 chats, so I added:


    In a 1:1 chat context, a bare jid MAY be used instead of a full jid.

3. The character counting for the fallback text in the example was wrong 
(it did not count new lines). Also, because of the stanza "pretty 
formatting", indent and 2 other newlines that should not be counted are 
added, so I mentioned it in the text. This may not seem much, but 
edhelas, deuill and I all had trouble getting our heads around how this 
worked, so I believe this is helpful for implementators. "Explicit is 
better than implicit", they say.


3. I also wanted to relax the constraint on the quoted author, ie, not 
make the `to` attribute of the `` tag mandatory. I confess this 
is in big part for self-centered reasons, since it's not always trivial 
to retrieve or determine the "quoted gatewayed contact's JID". After OOB 
discussion with marvin, we agreed to change my first iteration:


A client MAY omit the 'to' attribute

to

    The  element SHOULD have a 'to' attribute

It this last point is too controversial, I'm OK to remove it and will do 
my best to enforce it in my bridge implementation. I do think the other 
points are not controversial and make the XEP better overall.


Thanks in advance for you feedback.

Cheers,

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