diff --git a/xep-0410.xml b/xep-0410.xml index 71843f34..ec9efcbd 100644 --- a/xep-0410.xml +++ b/xep-0410.xml @@ -53,9 +53,9 @@ 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.
+ does not know of this occupant.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).
@@ -76,8 +76,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. -To a participant, this looks like the MUC is silent (there is no chat + occupants from the affected MUCs, without the clients being informed.
+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.
To prevent the bad usability effect (message loss, lack of reaction from @@ -88,13 +88,13 @@ it is still joined to a MUC:
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.
-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. A service
+ 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
self-ping-optimization feature in the &xep0030; response on
the individual MUC room JIDs, and it MUST respond to a self-ping request
@@ -201,7 +201,7 @@
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>. A client should not perform a self-ping after initiating a nickname
@@ -213,8 +213,8 @@
A MUC service implementation should not allow a non-participant to obtain
- information about participants. This is however true irregardless of
+ A MUC service implementation should not allow a non-occupant to obtain
+ information about occupants. This is however true irregardless of
implementing this specification.