REsource LOcation And Discovery (RELOAD) (RFC6940) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.
+REsource LOcation And Discovery (RELOAD) (&rfc6940;) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.
The XMPP Usage involves two basic functions:
In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of RFC6940).
+In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of &rfc6940;).
As a simple example, consider Juliet with an XMPP address "juliet@capulet.lit" at Node-ID "1234". She might store the mapping "juliet@capulet.lit -> 1234" telling anyone who wants to contact her to establish a direct XMPP stream with node "1234".
RELOAD peers can store two kinds of XMPP mappings,
Note that the rules for leaf certificates comply with the rules defined for client certificates under Sections 13.7.1.1 and 13.7.1.4 of &rfc6120;. Thus they can be used for c2s SASL EXTERNAL authentication.
-The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-XOR) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.
+The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-0415) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.
The following rules apply to domain-associated certificates:
An XMPP entity MAY maintain its own list of root certificates. However, in practice it's convenient to retrieve this list from a trusted source. For example, several organizations in the Internet maintain and provide such lists for certificates verification in the Web. This section specifies how the list of root certificates can be retrieved for the purpose of e2e authentication in XMPP.
-Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of RFC6940). The root certificates are PEM-encoded (RFC7468) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.
-In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (RFC7232).
+Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of &rfc6940;). The root certificates are PEM-encoded (&rfc7468;) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.
+In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (&rfc7232;).
Further versions of this specification MAY extend the Overlay Configuration with new XML elements.
An XMPP entity MAY want to publish its certificate so other XMPP entities MAY retrieve it. The method to accomplish this depends on the usage: