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
<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
_______________________________________________
