mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
Merge branch 'feature/xep-0410'
This commit is contained in:
Jonas Schäfer
commit
b28208e3aa
82
xep-0410.xml
82
xep-0410.xml
@ -29,6 +29,12 @@
|
||||
<email>georg@op-co.de</email>
|
||||
<jid>georg@yax.im</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.2.0</version>
|
||||
<date>2019-02-04</date>
|
||||
<initials>gl</initials>
|
||||
<remark>Incorporate feedback from Last Call.</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1.0</version>
|
||||
<date>2018-08-31</date>
|
||||
@ -53,15 +59,16 @@
|
||||
not designed to handle s2s interruptions or message loss well. Rather
|
||||
often, the restart of a server or a component causes a client to believe
|
||||
that it is still joined to a given chatroom, while the chatroom service
|
||||
does not know of this participant.</p>
|
||||
does not know of this occupant.</p>
|
||||
<p>Existing approaches for re-synchronization are either inefficient
|
||||
(presence updates and "silent" messages are reflected to all participants,
|
||||
(presence updates and "silent" messages are reflected to all occupants,
|
||||
totalling to O(N²) stanzas per time unit), or mask message /
|
||||
presence losses (the implicit join performed via the deprecated GC1.0
|
||||
protocol).</p>
|
||||
<p>This specification aims to provide the most efficient, albeit not the
|
||||
most elegant, way for clients to periodically check whether they are still
|
||||
joined to a chatroom.</p>
|
||||
joined to a chatroom. However, it can not ensure that a client remains
|
||||
joined to a room without any interruptions.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>This specification only makes sense in the context of &xep0045;
|
||||
@ -75,8 +82,8 @@
|
||||
and a typically local server-to-component link. If one of the involved
|
||||
servers or the MUC component is restarted, or one of the links is
|
||||
disturbed for some time, this can lead to the removal of some or all
|
||||
participants from the affected MUCs, without the clients being informed.</p>
|
||||
<p>To a participant, this looks like the MUC is silent (there is no chat
|
||||
occupants from the affected MUCs, without the clients being informed.</p>
|
||||
<p>To an occupant, this looks like the MUC is silent (there is no chat
|
||||
activity and no presence changes), making it hard to realize that the
|
||||
connection was interrupted.</p>
|
||||
<p>To prevent the bad usability effect (message loss, lack of reaction from
|
||||
@ -87,13 +94,13 @@
|
||||
it is still joined to a MUC:</p>
|
||||
<ol>
|
||||
<li><strong>Silent message</strong> (e.g. &xep0085;): this message will be reflected to
|
||||
all MUC participants, causing unwanted traffic and potentially waking
|
||||
all MUC occupants, causing unwanted traffic and potentially waking
|
||||
up mobile devices without reason. If implemented by all clients, this
|
||||
will result in O(N²) messages to the MUC.</li>
|
||||
<li><strong>Presence update</strong>: if the MUC service implements the legacy GC1.0 protocol,
|
||||
this will be treated as a join attempt, and the MUC will return the
|
||||
full list of participants and full room history. The user's client
|
||||
will however miss partial history (other participants leaving,
|
||||
full list of occupants and full room history. The user's client
|
||||
will however miss partial history (other occupants leaving,
|
||||
potentially also messages), and this has the same drawbacks as the
|
||||
first solution.</li>
|
||||
<li><strong>Private message to self</strong>: the client can send a MUC
|
||||
@ -101,7 +108,7 @@
|
||||
private messages, and there is no way to differentiate that from the
|
||||
error responses.</li>
|
||||
<li><strong>Private IQ to self</strong>: the client can send an IQ to
|
||||
its own participant JID. MUCs typically do not forbid those, and
|
||||
its own occupant JID. MUCs typically do not forbid those, and
|
||||
reflect the IQ request to the client (or another client of the same
|
||||
user). Once that client responds to the reflected IQ, the response is
|
||||
delivered to the initiating client as a sign of still being joined.
|
||||
@ -130,7 +137,7 @@
|
||||
<p>If Juliet's client is not joined, the MUC service will respond with a
|
||||
<not-acceptable> error. Thus, her client can automatically attempt
|
||||
a rejoin.</p>
|
||||
<example caption="Server Response to a Non-Participant"><![CDATA[
|
||||
<example caption="Server Response to a Non-Occupant"><![CDATA[
|
||||
<iq from='characters@chat.shakespeare.lit/JuliC' id='s2c1' type='error'
|
||||
to='juliet@capulet.lit/client' >
|
||||
<error type="cancel">
|
||||
@ -155,10 +162,14 @@
|
||||
<feature-not-implemented>)</strong>: the client is joined, but
|
||||
the pinged client does not implement &xep0199;.</li>
|
||||
<li><strong>Error (<item-not-found>)</strong>: the client is
|
||||
joined, but the participant just changed their name (e.g. initiated by
|
||||
joined, but the occupant just changed their name (e.g. initiated by
|
||||
a different client).</li>
|
||||
<li><strong>Any other error</strong>: the client is probably not
|
||||
joined.</li>
|
||||
<li><strong>Any other error</strong><note>Different service
|
||||
implementations will send different responses to a client that's not
|
||||
joined. The recommended error code is <not-acceptable>, however
|
||||
some servers will respond with <not-allowed> or
|
||||
<bad-request> as well.</note>: the client is probably not
|
||||
joined any more. It should perform a re-join.</li>
|
||||
<li><strong>Timeout (no response)</strong>: the MUC service (or another
|
||||
client) is unreachable. The client may indicate the status to the user
|
||||
and re-attempt the self-ping after some timeout, until it receives
|
||||
@ -173,32 +184,61 @@
|
||||
connectivity issues, which is often the case with mobile devices, the
|
||||
ping request might never be responded to.</p>
|
||||
<p>Therefore, a MUC service supporting this protocol may directly respond
|
||||
to a participant's Ping request to the participant's own nickname, as
|
||||
opposed to routing it to any of the participant's clients.</p>
|
||||
to a occupant's Ping request to the occupant's own nickname, as
|
||||
opposed to routing it to any of the occupant's clients. A service
|
||||
implementing this optimization needs to advertise the
|
||||
<tt>self-ping-optimization</tt> feature in the &xep0030; response on
|
||||
the individual MUC room JIDs, and it MUST respond to a self-ping request
|
||||
as follows:</p>
|
||||
<ul>
|
||||
<li><strong>Successful IQ response</strong>: the client is joined to the MUC.</li>
|
||||
<li><strong>Error (<not-acceptable>)</strong>: the client is not joined to the MUC.</li>
|
||||
</ul>
|
||||
<example caption='MUC Service Advertises Self-Ping Optimization'><![CDATA[
|
||||
<iq from='darkcave@chat.shakespeare.lit'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<!-- ... -->
|
||||
<feature var='http://jabber.org/protocol/muc#self-ping-optimization'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<p>In Multi-Session-Nick scenarios, where multiple clients of the same user
|
||||
are joined as the same participant, it is possible that another client
|
||||
are joined as the same occupant, it is possible that another client
|
||||
initiates a nickname change while a ping request is pending. In that case,
|
||||
the ping might be responded to with <item-not-found>.</p>
|
||||
<p>A client should not perform a self-ping after initiating a nickname
|
||||
change, and before receiving the response to the nickname change from the
|
||||
service, as it is not yet clear whether the new nickname will be accepted.
|
||||
</p>
|
||||
<p>If a client session is in hibernation (&xep0198;), the client should defer
|
||||
sending of self-ping requests until it is reconnected and re-authenticated.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>A MUC service implementation should not allow a non-participant to obtain
|
||||
information about participants. This is however true irregardless of
|
||||
<p>A MUC service implementation should not allow a non-occupant to obtain
|
||||
information about occupants. This is however true irregardless of
|
||||
implementing this specification.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>REQUIRED.</p>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>REQUIRED.</p>
|
||||
<p>Include "<tt>http://jabber.org/protocol/muc#self-ping-optimization</tt>"
|
||||
as a valid feature in the Registry of Features.</p>
|
||||
<code caption='Registry Submission'><![CDATA[
|
||||
<var>
|
||||
<name>http://jabber.org/protocol/muc#self-ping-optimization</name>
|
||||
<desc>Support for the MUC self-ping optimization</desc>
|
||||
<doc>XEP-0410</doc>
|
||||
</var>
|
||||
]]></code>
|
||||
|
||||
</section1>
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<p>REQUIRED for protocol specifications.</p>
|
||||
<p>This document does not define any new XML structure requiring a schema.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user