mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
1.3rc2
This commit is contained in:
stpeter
parent
f935c7b826
commit
6fec6fb608
65
xep-0198.xml
65
xep-0198.xml
@ -30,10 +30,10 @@
|
||||
&dcridland;
|
||||
&mwild;
|
||||
<revision>
|
||||
<version>1.3rc1</version>
|
||||
<date>in progress, last updated 2011-04-20</date>
|
||||
<version>1.3rc2</version>
|
||||
<date>in progress, last updated 2011-06-01</date>
|
||||
<initials>psa/mw</initials>
|
||||
<remark><p>Corrected the value of 'h' in several examples; removed an extraneous 'stanzas' attribute from one example.</p></remark>
|
||||
<remark><p>Corrected the value of 'h' in several examples; removed an extraneous 'stanzas' attribute from one example; clarified terminology; added note about the order of events in the stream negotiation process.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.2</version>
|
||||
@ -167,14 +167,14 @@
|
||||
<li>Stanza Acknowledgements -- the ability to know if a stanza or series of stanzas has been received by one's peer.</li>
|
||||
<li>Stream Resumption -- the ability to quickly resume a stream that has been terminated.</li>
|
||||
</ul>
|
||||
<p>Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in &xmppcore;) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.</p>
|
||||
<p>Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see &xmppcore;), &xep0199;, or TCP keepalives. By constrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.</p>
|
||||
<p>(Examples prepended by "C:" are sent by a client and examples prepended by "S:" are sent by a server. Stream management can be used server-to-server but most of the examples in this specification show its use between a client and a server.)</p>
|
||||
<p>Stream management implements these features using short XML elements at the root stream level. These elements are not "stanzas" in the XMPP sense (i.e., not &IQ;, &MESSAGE;, or &PRESENCE; stanzas as defined in <cite>RFC 6120</cite>) and are not counted or acked in stream management, since they exist for the purpose of managing stanzas themselves.</p>
|
||||
<p>Stream management is used at the level of an XML stream. To check TCP connectivity underneath a given stream, it is RECOMMENDED to use whitespace keepalives (see <cite>RFC 6120</cite>), &xep0199;, or TCP keepalives. By constrast with stream management, &xep0079; and &xep0184; define acks that are sent end-to-end over multiple streams; these facilities are useful in special scenarios but are unnecessary for checking of a direct stream between two XMPP entities.</p>
|
||||
<p>Note: Stream Management can be used for server-to-server streams as well as for client-to-server streams. However, for convenience this specification discusses client-to-server streams only. The same principles apply to server-to-server streams. (In this document, examples prepended by "C:" are sent by a client and examples prepended by "S:" are sent by a server.)</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Stream Feature' anchor='feature'>
|
||||
<p>The receiving entity returns a stream header to the intiating entity along with stream features, where the features include an <sm/> element qualified by the 'urn:xmpp:sm:3' namespace &VNOTE;.</p>
|
||||
<p>Note: The initiating entity cannot negotiate stream management until it has authenticated with the receiving entity and (for clients) possibly until after it has bound a resource; see below for specific restrictions.</p>
|
||||
<p>The server returns a stream header to the client along with stream features, where the features include an <sm/> element qualified by the 'urn:xmpp:sm:3' namespace &VNOTE;.</p>
|
||||
<p>Note: The client cannot negotiate stream management until it has authenticated with the server and has bound a resource; see below for specific restrictions.</p>
|
||||
<example caption='Server sends new stream header along with stream features'><![CDATA[
|
||||
S: <stream:stream
|
||||
from='example.com'
|
||||
@ -194,24 +194,24 @@ S: <stream:features>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Enabling Stream Management' anchor='enable'>
|
||||
<p>To enable use of stream management, the initiating entity sends an <enable/> command to the receiving entity.</p>
|
||||
<p>To enable use of stream management, the client sends an <enable/> command to the server.</p>
|
||||
<example caption='Client enables stream management'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>If the initiating entity wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false &BOOLEANNOTE;. For information about resuming a previous session, see the <link url='#resumption'>Resumption</link> section of this document.</p>
|
||||
<p>The <enable/> element MAY include a 'max' attribute to specify the initiating entity's preferred maximum resumption time in seconds.</p>
|
||||
<p>Upon receiving the enable request, the receiving entity MUST reply with an <enabled/> element or a <failed/> element qualified by the 'urn:xmpp:sm:3' namespace. The <failed/> element indicates that there was a problem establishing the stream management "session". The <enabled/> element indicates successful establishment of the stream management session.</p>
|
||||
<p>If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false &BOOLEANNOTE;. For information about resuming a previous session, see the <link url='#resumption'>Resumption</link> section of this document.</p>
|
||||
<p>The <enable/> element MAY include a 'max' attribute to specify the client's preferred maximum resumption time in seconds.</p>
|
||||
<p>Upon receiving the enable request, the server MUST reply with an <enabled/> element or a <failed/> element qualified by the 'urn:xmpp:sm:3' namespace. The <failed/> element indicates that there was a problem establishing the stream management "session". The <enabled/> element indicates successful establishment of the stream management session.</p>
|
||||
<example caption='Server enables stream management'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3'/>
|
||||
]]></example>
|
||||
<p>The parties can then the use stream management features defined below.</p>
|
||||
<p>If the receiving entity allows session resumption, it MUST include a 'resume' attribute set to a value of "true" or "1" &BOOLEANNOTE;.</p>
|
||||
<p>If the server allows session resumption, it MUST include a 'resume' attribute set to a value of "true" or "1" &BOOLEANNOTE;.</p>
|
||||
<example caption='Server enables stream management with session resumption'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
|
||||
]]></example>
|
||||
<p>The <enabled/> element MAY include a 'max' attribute to specify the receiving entity's preferred maximum resumption time.</p>
|
||||
<p>The <enabled/> element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of <cite>RFC 6120</cite> (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.</p>
|
||||
<p>The initiating entity MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an <enable/> element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.</p>
|
||||
<p>The <enabled/> element MAY include a 'max' attribute to specify the server's preferred maximum resumption time.</p>
|
||||
<p>The <enabled/> element MAY include a 'location' attribute to specify the server's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of <cite>RFC 6120</cite> (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in <cite>RFC 6120</cite> applies.</p>
|
||||
<p>The client MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an <enable/> element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.</p>
|
||||
<p>For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding <em>unless it is resuming a previous session</em> (see <link url='#resumption'>Resumption</link>).</p>
|
||||
<p>The server SHALL enforce this order and return a <failed/> element in response if the order is violated (see <link url='#errors'>Error Handling</link>).</p>
|
||||
<example caption='Server returns error if client attempts to enable stream management before resource binding'><![CDATA[
|
||||
@ -222,21 +222,21 @@ S: <failed xmlns='urn:xmpp:sm:3'>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acks' anchor='acking'>
|
||||
<p>After enabling stream management, the initiating or receiving entity can send ack elements at any time over the stream. An ack element is one of the following:</p>
|
||||
<p>After enabling stream management, the client or server can send ack elements at any time over the stream. An ack element is one of the following:</p>
|
||||
<ul>
|
||||
<li>The <a/> element is used to <strong>answer</strong> a request for acknowledgement or to send an unrequested ack.</li>
|
||||
<li>The <r/> element is used to <strong>request</strong> acknowledgement of received stanzas.</li>
|
||||
</ul>
|
||||
<p>The following attribute is defined:</p>
|
||||
<ul>
|
||||
<li>The 'h' attribute identifies the last <strong>handled</strong> stanza (i.e., the last stanza that the receiver will acknowledge as having received).</li>
|
||||
<li>The 'h' attribute identifies the last <strong>handled</strong> stanza (i.e., the last stanza that the server will acknowledge as having received).</li>
|
||||
</ul>
|
||||
<p>An <a/> element MUST possess an 'h' attribute.</p>
|
||||
<p>The <r/> element has no defined attributes.</p>
|
||||
<p class='def'><strong>Definition:</strong> Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the receiver. By "handled" we mean that the receiver has accepted responsibility for a stanza or stanzas (e.g., to process the stanza(s) directly, deliver the stanza(s) to a local entity such as another connected client on the same server, or route the stanza(s) to a remote entity at a different server); until a stanza has been affirmed as handled by the receiver, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the receiver).</p>
|
||||
<p class='def'><strong>Definition:</strong> Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the server. By "handled" we mean that the server has accepted responsibility for a stanza or stanzas (e.g., to process the stanza(s) directly, deliver the stanza(s) to a local entity such as another connected client on the same server, or route the stanza(s) to a remote entity at a different server); until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).</p>
|
||||
<p>Receipt of an <r/> element does not imply that new stanzas have been transmitted by the peer; receipt of an <a/> element only indicates that new stanzas have been processed if the 'h' attribute has been incremented.</p>
|
||||
<p>The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled, is incremented to one for the first stanza handled, and is incremented by one again with each subsequent stanza handled. In the unlikely case that the number of stanzas handled during a stream management session exceeds the number of digits that can be represented by the unsignedInt datatype as specified in &w3xmlschema2; (i.e., 2<span class='super'>32</span>), the value of 'h' SHALL be reset from 2<span class='super'>32</span>-1 back to zero (rather than being incremented to 2<span class='super'>32</span>).</p>
|
||||
<p>Note: In fact, there are two values of 'h': one for the initiator, and one for the receiver. The initiator's value needs to be intialized to 0 at the transmission or receipt of <enable/>, and the receiver's value needs to be initialized to 0 at the transmission or receipt of <enabled/>. It is expected that the receiver will response immediately to <enable/> and reset both counters.</p>
|
||||
<p class='box'>Note: There are two values of 'h' for any given stream: one maintained by the client to keep track of stanzas it has handled from the server, and one maintained by the server to keep track of stanzas it has handled from the client. The client initializes its value to zero when it sends <enable/> to the server, and the server initializes its value to zero when it receives <enabled/> from the client (it is expected that the server will respond immediately to <enable/> and set its counter to zero at that time). After this initialization, the client increments its value of 'h' for each stanza it handles from server, and the server increments its value of 'h' for each stanza it handles from the client.</p>
|
||||
<p>The following annotated example shows a message sent by the client, a request for acknowledgement, and an ack of the stanza.</p>
|
||||
<example caption='Simple stanza acking'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3'/>
|
||||
@ -285,11 +285,11 @@ S: <a xmlns='urn:xmpp:sm:3' h='1'/>
|
||||
<example caption='Client enables stream management'><![CDATA[
|
||||
C: <enable xmlns='urn:xmpp:sm:3' resume='true'/>
|
||||
]]></example>
|
||||
<p>If the receiving entity will allow the stream to be resumed, it MUST include a 'resume' attribute set to "true" or "1" on the <enabled/> element and MUST include an 'id' attribute that specifies an identifier for the stream.</p>
|
||||
<p>If the server will allow the stream to be resumed, it MUST include a 'resume' attribute set to "true" or "1" on the <enabled/> element and MUST include an 'id' attribute that specifies an identifier for the stream.</p>
|
||||
<example caption='Server allows stream resumption'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
|
||||
]]></example>
|
||||
<p class='def'><strong>Definition:</strong> The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the receiving entity (server). The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The receiving entity MAY encode any information it deems useful into the SM-ID, such as the full JID &LOCALFULL; of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (but the server need not ensure that SM-IDs are unique for all time, only for as long as the server is continuously running). The SM-ID SHOULD NOT be longer than 4000 bytes.</p>
|
||||
<p class='def'><strong>Definition:</strong> The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the server. The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The server MAY encode any information it deems useful into the SM-ID, such as the full JID &LOCALFULL; of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (but the server need not ensure that SM-IDs are unique for all time, only for as long as the server is continuously running). The SM-ID SHOULD NOT be longer than 4000 bytes.</p>
|
||||
<p>As noted, the <enabled/> element MAY include a 'location' attribute that specifies the server's preferred location for reconnecting (e.g., a particular connection manager that hold session state for the connected client).</p>
|
||||
<example caption='Server prefers reconnection at a particular location'><![CDATA[
|
||||
S: <enabled xmlns='urn:xmpp:sm:3'
|
||||
@ -297,9 +297,9 @@ S: <enabled xmlns='urn:xmpp:sm:3'
|
||||
location='[2001:41D0:1:A49b::1]:9222'
|
||||
resume='true'/>
|
||||
]]></example>
|
||||
<p>If the stream is terminated unexpectedly, the initiating entity would then open a TCP connection to the receiving entity. The order of events is as follows:</p>
|
||||
<p>If the stream is terminated unexpectedly, the initiating entity would then open a TCP connection to the server. The order of events is as follows:</p>
|
||||
<ol start='1'>
|
||||
<li>After disconnection, the initiating entity opens a new TCP connection to the receiving entity, preferring the address specified in the 'location' attribute (if any).</li>
|
||||
<li>After disconnection, the initiating entity opens a new TCP connection to the server, preferring the address specified in the 'location' attribute (if any).</li>
|
||||
<li>Initiating entity sends initial stream header.</li>
|
||||
<li>Receiving entity sends response stream header.</li>
|
||||
<li>Receiving entity sends stream features.</li>
|
||||
@ -315,20 +315,21 @@ S: <enabled xmlns='urn:xmpp:sm:3'
|
||||
<li>Receiving entity sends stream features, offering the SM feature.</li>
|
||||
<li>Initiating entity requests resumption of the former stream.</li>
|
||||
</ol>
|
||||
<p>To request resumption of the former stream, the initiating entity sends a <resume/> element qualified by the 'urn:xmpp:sm:3' namespace. The <resume/> element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MAY include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the receiving entity to the initiating entity (if stream management was being used in both directions); if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
|
||||
<p>Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in <cite>RFC 6120</cite>. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.</p>
|
||||
<p>To request resumption of the former stream, the initiating entity sends a <resume/> element qualified by the 'urn:xmpp:sm:3' namespace. The <resume/> element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MAY include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the initiating entity (if stream management was being used in both directions); if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
|
||||
<example caption='Stream resumption request'><![CDATA[
|
||||
C: <resume xmlns='urn:xmpp:sm:3'
|
||||
h='some-sequence-number'
|
||||
previd='some-long-sm-id'/>
|
||||
]]></example>
|
||||
<p>If the receiving entity can resume the former stream, it MUST return a <resumed/> element, which MUST include a 'previd' attribute set to the SM-ID of the former stream. The <resumed/> element MAY also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the initiating entity to the receiving entity; if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
|
||||
<p>If the server can resume the former stream, it MUST return a <resumed/> element, which MUST include a 'previd' attribute set to the SM-ID of the former stream. The <resumed/> element MAY also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the initiating entity to the server; if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
|
||||
<example caption='Stream resumed'><![CDATA[
|
||||
S: <resumed xmlns='urn:xmpp:sm:3'
|
||||
h='another-sequence-number'
|
||||
previd='some-long-sm-id'/>
|
||||
]]></example>
|
||||
<p>If the receiving entity does not support session resumption, it MUST return a <failed/> element, which SHOULD include an error condition of &feature;. If the receiving entity does not recognize the 'previd' as an earlier session (e.g., because the former session has timed out), it MUST return a <failed/> element, which SHOULD include an error condition of ¬found;. In both of these failure cases, the receiving entity SHOULD allow the initiating entity to bind a resource at this point rather than forcing the initiating entity to restart the stream negotiation process and re-authenticate.</p>
|
||||
<p>If the former stream is resumed and the receiving entity still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.</p>
|
||||
<p>If the server does not support session resumption, it MUST return a <failed/> element, which SHOULD include an error condition of &feature;. If the server does not recognize the 'previd' as an earlier session (e.g., because the former session has timed out), it MUST return a <failed/> element, which SHOULD include an error condition of ¬found;. In both of these failure cases, the server SHOULD allow the initiating entity to bind a resource at this point rather than forcing the initiating entity to restart the stream negotiation process and re-authenticate.</p>
|
||||
<p>If the former stream is resumed and the server still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.</p>
|
||||
<p>When a session is resumed, the parties proceed as follows:</p>
|
||||
<ul>
|
||||
<li>Both parties SHOULD retransmit any stanzas that were not handled during the previous session, based on the sequence number reported by the peer.</li>
|
||||
@ -339,7 +340,7 @@ S: <resumed xmlns='urn:xmpp:sm:3'
|
||||
</section1>
|
||||
|
||||
<section1 topic='Error Handling' anchor='errors'>
|
||||
<p>If an error occurs with regard to an <enable/> or <resume/> element, the receiving entity MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in &xmppcore;.</p>
|
||||
<p>If an error occurs with regard to an <enable/> or <resume/> element, the server MUST return a <failed/> element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in <cite>RFC 6120</cite>.</p>
|
||||
<p>An example follows.</p>
|
||||
<example caption='Server returns error'><![CDATA[
|
||||
S: <failed xmlns='urn:xmpp:sm:3'>
|
||||
@ -361,7 +362,7 @@ S: <failed xmlns='urn:xmpp:sm:3'>
|
||||
<p>The Stream Management protocol can be used to improve reliability using acks without the ability to resume a session. A basic implementation would do the following:</p>
|
||||
<ul>
|
||||
<li>As an initiating entity, send <enable/> with no attributes, and ignore the attributes on the <enabled/> response.</li>
|
||||
<li>As a receiving entity, ignore the attributes on the <enable/> element received, and respond via <enabled/> with no attributes.</li>
|
||||
<li>As a server, ignore the attributes on the <enable/> element received, and respond via <enabled/> with no attributes.</li>
|
||||
<li>When receiving an <r/> element, immediately respond via an <a/> element where the value of 'h' returned is the sequence number of the last handled stanza.</li>
|
||||
<li>Keep an integer X for this stream session, initially set to zero. When about to send a stanza, first put the stanza (paired with the current value of X) in an "unacknowleged" queue. Then send the stanza over the wire with <r/> to request acknowledgement of that outbound stanza, and increment X by 1. When receiving an <r/> or <a/> element with an 'h' attribute, all stanzas whose paired value (X at the time of queueing) is less than or equal to the value of 'h' can be removed from the unacknowledged queue.</li>
|
||||
</ul>
|
||||
@ -451,7 +452,7 @@ S: <a h='10'/>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>As noted, a receiving entity MUST NOT allow an initiating entity to resume a stream management session until after the initiating entity has authenticated (for some value of "authentication"); this helps to prevent session hijacking.</p>
|
||||
<p>As noted, a server MUST NOT allow an initiating entity to resume a stream management session until after the initiating entity has authenticated (for some value of "authentication"); this helps to prevent session hijacking.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
@ -603,7 +604,7 @@ S: <a h='10'/>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Bruce Campbell, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Alexey Melnikov, Pedro Melo, Robin Redeker, Mickaël Rémond, and Florian Schmaus for their feedback.</p>
|
||||
<p>Thanks to Bruce Campbell, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Alexey Melnikov, Pedro Melo, Robin Redeker, Mickaël Rémond, Florian Schmaus, and Tomasz Sterna for their feedback.</p>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user