XEP-xxxx: Payment Required

Payer

The XMPP entity that receives a payment-required error and is expected to fulfill the payment. Typically this is the originating client.

Payee / Service

The XMPP entity that requires payment before granting access to a resource. This may be a server component, a MUC service, a bot, or any other XMPP service.

Invoice

A structured XML element, defined in this specification, that conveys one or more payment options to a payer.

Payment Option

A single, self-contained description of one method by which payment may be made (e.g., a SEPA bank transfer, a UPI payment request, a Lightning Network invoice).

Proof of Payment

A token supplied by the payer on retry to demonstrate that a payment has been made. The format depends on the payment scheme used (e.g., a Lightning Network payment preimage, a bank transaction reference number).

Payment Session

A short-lived, service-generated identifier that correlates a payment-required error with the subsequent retry stanza, analogous to a session identifier in Ad-Hoc Commands (XEP-0050) [5].

4.1 Paid MUC Room Entry with Multiple Payment Options¶

Juliet operates a premium conference room on conference.shakespeare.lit that charges an entry fee. Romeo attempts to join but is declined and presented with invoice options spanning both traditional banking and an instant-settlement network.

<presence from='romeo@shakespeare.lit/orchard'
          to='upperroom@conference.shakespeare.lit/Romeo'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence from='upperroom@conference.shakespeare.lit'
          to='romeo@shakespeare.lit/orchard'
          type='error'>
  <error type='auth'>
    <payment-required xmlns='urn:xmpp:payment:0'/>
    <text xml:lang='en'
          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      An entry fee of EUR 5.00 is required to join this room.
    </text>
    <invoice expires='2026-04-19T14:00:00Z'
             purpose='Premium room monthly entry'
             session='c4a1f902-7d3b-4e8c-a510-2f9b0e6d3178'
             xmlns='urn:xmpp:payment:0'>
      <description>
        Pay once per calendar month. Include your JID as the payment
        reference so your access can be confirmed promptly.
      </description>
      <option amount='EUR:5.00'
              label='Bank transfer (SEPA)'
              scheme='payto'>payto://iban/DE02200400300200270112?amount=EUR:5.00&amp;message=upperroom-c4a1f902&amp;receiver-name=Capulet+Hosting</option>
      <option amount='INR:450'
              label='UPI'
              scheme='payto'>payto://upi/capulethosting@examplebank?amount=INR:450&amp;message=upperroom-c4a1f902&amp;receiver-name=Capulet+Hosting
        <display-amount>&#x20B9; 450</display-amount>
      </option>
      <option amount='EUR:5.00'
              label='Lightning Network (instant)'
              scheme='lightning-bolt11'>lnbc50n1pn2s4czpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq
        <display-amount>EUR 5.00 via Lightning</display-amount>
      </option>
    </invoice>
  </error>
</presence>

<presence from='romeo@shakespeare.lit/orchard'
          to='upperroom@conference.shakespeare.lit/Romeo'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <payment scheme='payto'
           session='c4a1f902-7d3b-4e8c-a510-2f9b0e6d3178'
           xmlns='urn:xmpp:payment:0'>
    <proof type='reference'>NOTPROVIDED20260419DE02</proof>
  </payment>
</presence>

<presence from='romeo@shakespeare.lit/orchard'
          to='upperroom@conference.shakespeare.lit/Romeo'>
  <x xmlns='http://jabber.org/protocol/muc'/>
  <payment scheme='lightning-bolt11'
           session='c4a1f902-7d3b-4e8c-a510-2f9b0e6d3178'
           xmlns='urn:xmpp:payment:0'>
    <proof type='lightning-preimage'>a8f3e1d2b4c9078564fae012cc3d99a1b5e7d0f3a2c81496057832bd7e4f0c1a</proof>
  </payment>
</presence>

Because SEPA bank transfers may take time to settle, the service SHOULD set a generous session expiry for bank-transfer options and MAY grant access provisionally upon receiving the retry stanza, subsequently revoking it if reconciliation fails.

4.2 Per-Message Fee for an AI Agent Bot¶

Balthasar operates a news-summary bot that charges per query. Because the amounts are small and latency matters, only instant-settlement options are offered. This is a service-level policy decision, not a protocol constraint.

<message from='romeo@shakespeare.lit/orchard'
         id='msg-001'
         to='newssummary@bots.shakespeare.lit'
         type='chat'>
  <body>Summarize today's news from Verona.</body>
</message>

<message from='newssummary@bots.shakespeare.lit'
         id='msg-001'
         to='romeo@shakespeare.lit/orchard'
         type='error'>
  <body>Summarize today's news from Verona.</body>
  <error type='auth'>
    <payment-required xmlns='urn:xmpp:payment:0'/>
    <text xml:lang='en'
      xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      A payment of 10 sats is required per query.
    </text>
    <invoice expires='2026-03-19T14:20:00Z'
             purpose='Per-query fee'
             session='a3f7c291-84d0-4b2e-9b1a-0f3e2d1c5678'
             xmlns='urn:xmpp:payment:0'>
      <option amount='SAT:10'
          label='Lightning (instant, automated)'
          scheme='lightning-bolt11'>lnbc100n1pn2s3dzpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq
        <display-amount>10 sats</display-amount>
      </option>
      <option amount='SAT:10'
              label='BOLT 12 offer'
              scheme='lightning-bolt12'>lno1qgsyz4uzesxqcyq5rqwzqfqpqdynf
        <display-amount>10 sats</display-amount>
      </option>
    </invoice>
  </error>
</message>

<message from='romeo@shakespeare.lit/orchard'
         id='msg-002'
         to='newssummary@bots.shakespeare.lit'
         type='chat'>
  <body>Summarize today's news from Verona.</body>
  <payment scheme='lightning-bolt11'
           session='a3f7c291-84d0-4b2e-9b1a-0f3e2d1c5678'
           xmlns='urn:xmpp:payment:0'>
    <proof type='lightning-preimage'>a8f3e1d2b4c9078564fae012cc3d99a1b5e7d0f3a2c81496057832bd7e4f0c1a</proof>
  </payment>
</message>

<message from='newssummary@bots.shakespeare.lit'
         id='msg-003'
         to='romeo@shakespeare.lit/orchard'
         type='chat'>
  <body>Today in Verona: the Montagues and Capulets have agreed to a temporary truce...</body>
  <receipt reference='a8f3e1d2b4c9078564fae012cc3d99a1b5e7d0f3a2c81496057832bd7e4f0c1a'
           scheme='lightning-bolt11'
           session='a3f7c291-84d0-4b2e-9b1a-0f3e2d1c5678'
           settled='2026-03-20T09:01:14Z'
           xmlns='urn:xmpp:payment:0'/>
</message>

4.3 Anti-Spam Deposit for Non-Roster Contacts¶

Juliet's server requires a small deposit from senders not present in her roster, as a proof-of-intent mechanism to deter unsolicited messages. Instant-settlement options are used because slow bank transfers would allow queuing before verification.

<message from='juliet@shakespeare.lit'
         id='spam-001'
         to='stranger@othello.lit/mobile'
         type='error'>
  <body>Buy cheap goblets!</body>
  <error type='auth'>
    <payment-required xmlns='urn:xmpp:payment:0'/>
    <text xml:lang='en'
          xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      A small deposit is required to message this user for the first time.
      The deposit will be refunded if the recipient accepts your contact request.
    </text>
    <invoice expires='2026-03-19T16:01:00Z'
             purpose='First-contact anti-spam deposit'
             session='f1c3d9e2-7a04-4b8f-a629-3e0d15b7c412'
             xmlns='urn:xmpp:payment:0'>
      <option amount='SAT:10'
              label='Lightning deposit'
              scheme='lightning-bolt11'>lnbc100n1pn2s5azpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq
        <display-amount>10 sats</display-amount>
      </option>
    </invoice>
  </error>
</message>

4.4 Proactive Invoice Request¶

A client MAY proactively request an invoice from a service before sending the gated stanza. This is useful when the client wishes to present payment options to the user before committing to an action. Before sending a proactive invoice request, the client SHOULD discover whether the service supports this feature by querying for the 'urn:xmpp:payment:0#invoice-request' feature via Service Discovery (XEP-0030) [4].

<iq from='romeo@shakespeare.lit/orchard'
    id='inv-001'
    to='conference.shakespeare.lit'
    type='get'>
  <get-invoice service='muc-entry'
               target='upperroom@conference.shakespeare.lit'
               xmlns='urn:xmpp:payment:0'/>
</iq>

<iq from='conference.shakespeare.lit'
    id='inv-001'
    to='romeo@shakespeare.lit/orchard'
    type='result'>
  <invoice expires='2026-04-19T14:00:00Z'
           purpose='Premium room monthly entry'
           session='3c91b2e4-6f07-4a2d-b839-5e0f17d9c823'
           xmlns='urn:xmpp:payment:0'>
    <option amount='EUR:5.00'
            label='Bank transfer (SEPA)'
            scheme='payto'>payto://iban/DE02200400300200270112?amount=EUR:5.00&amp;message=3c91b2e4&amp;receiver-name=Capulet+Hosting</option>
    <option amount='EUR:5.00'
            label='Lightning (instant)'
            scheme='lightning-bolt11'>lnbc50n1pn2s4czpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq
      <display-amount>EUR 5.00</display-amount>
    </option>
  </invoice>
</iq>

If the service does not support proactive invoice requests, it SHOULD return a <feature-not-implemented/> error of type "cancel".

4.5 Payment Challenge as Alternative to CAPTCHA¶

This specification extends CAPTCHA Forms (XEP-0158) [2] by defining a new challenge field type that carries a payment invoice, allowing a service to offer payment as an alternative to solving a CAPTCHA.

To embed a payment invoice within a CAPTCHA Forms (XEP-0158) [2] challenge, the challenger SHOULD include a field with var='urn:xmpp:payment:0' inside the Data Form. The invoice is transmitted as a sibling element to the <x/> element in the same stanza.

<message from='security.shakespeare.lit'
         id='challenge-001'
         to='romeo@shakespeare.lit/orchard'>
  <x type='form' xmlns='jabber:x:data'>
    <title>Verify your intent</title>
    <field type='hidden' var='FORM_TYPE'>
      <value>urn:xmpp:captcha</value>
    </field>
    <field type='hidden' var='challenge'>
      <value>challenge-abc-123</value>
    </field>
    <field label='Enter the text you see:'
           type='text-single'
           var='ocr'>
      <media xmlns='urn:xmpp:media-element'>
        <uri type='image/jpeg'>https://security.shakespeare.lit/captcha/abc123.jpg</uri>
      </media>
      <required/>
    </field>
    <field label='Or pay the verification fee (enter session ID after payment):'
           type='text-single'
           var='urn:xmpp:payment:0'/>
  </x>
  <invoice expires='2026-03-19T14:30:00Z'
           purpose='Account verification fee'
           session='9d4e2c01-5b8f-4a3e-b796-0f1e28d7c589'
           xmlns='urn:xmpp:payment:0'>
    <option amount='EUR:0.01'
            label='Bank transfer (SEPA)'
            scheme='payto'>payto://iban/DE02200400300200270112?amount=EUR:0.01&amp;message=9d4e2c01
      <display-amount>EUR 0.01</display-amount>
    </option>
    <option amount='EUR:0.01'
            label='Lightning'
            scheme='lightning-bolt11'>lnbc10p1pn2s6azpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq
      <display-amount>EUR 0.01</display-amount>
    </option>
  </invoice>
</message>

5.1 Namespace¶

This specification uses the namespace 'urn:xmpp:payment:0'. (see Namespace Versioning regarding the possibility of incrementing the version number)

5.2 Elements¶

The following elements are defined in the 'urn:xmpp:payment:0' namespace.

5.3 Error Flow¶

When a service requires payment for an action, it MUST respond to the triggering stanza with an error of type "auth" containing the <payment-required/> application condition element qualified by 'urn:xmpp:payment:0', and MUST include an <invoice/> element as a sibling of the error condition element within the <error/> element.

The "auth" error type is appropriate because the payer has not yet demonstrated authorization (via payment) to access the resource. The <payment-required/> application condition distinguishes this case from <not-authorized/> and <registration-required/>.

If the requesting entity is not authenticated at all (e.g., it has not completed SASL authentication with its own server, or its JID cannot be verified), the service SHOULD return a <not-authorized/> error rather than a <payment-required/> error. Payment challenges SHOULD only be issued to entities whose identity can be established, to prevent anonymous entities from exploiting the payment flow to probe service behavior.

The service SHOULD include a human-readable <text/> child within the <error/> element describing the reason for the payment requirement.

When a <payment/> element is present on a retried stanza but verification fails, the service SHOULD return a <not-acceptable/> error of type "modify" containing a <payment-required/> element with an appropriate 'reason' attribute (see The payment-required Element), and MAY include a new <invoice/> element to allow the payer to retry with a fresh payment. Using a machine-readable 'reason' value allows automated agents to distinguish between a recoverable failure (e.g., 'payment-expired', which warrants requesting a new invoice) and a non-recoverable one (e.g., 'verification-failed', which warrants escalating to the user).

5.4 Verification¶

The mechanism by which a service verifies that a payment has been made is outside the scope of this specification. The following non-normative guidance is provided for implementors.

For bank transfers (SEPA, IBAN, UPI, PIX, SWIFT, etc.), the service typically cannot verify payment in real time. The service SHOULD encode the session identifier as the payment reference in the payto URI (the 'message' or 'instruction' query parameter) and reconcile incoming payments against outstanding sessions via its bank's API or statement-import mechanism. Because bank transfers can take from seconds (SEPA Instant) to days (SWIFT) to settle, bank transfer options are best suited to one-time access grants such as account registration or monthly subscriptions rather than per-message micropayments.

For Lightning Network payments, the service MAY verify payment by stateless preimage verification: if the payment hash is encoded in the session identifier, the service verifies that SHA-256(preimage) matches the payment hash without querying external state. Alternatively, the service MAY query its own Lightning node for a settled invoice.

A facilitator service MAY issue an opaque bearer token after verifying payment. The token can be used across multiple retried stanzas within its validity period, enabling a "pay once, use many times" pattern. The format and lifecycle of such tokens is outside the scope of this specification.

A service MUST NOT accept the same session identifier more than once. Once a session is consumed, the service MUST invalidate it. A service MUST NOT honor a session after the time specified in the 'expires' attribute.

6.1 Service Behavior¶

• A service MUST generate a new, unique session identifier for every invoice issued.
• A service SHOULD include at least one URI-based option (e.g., a payto URI) to support human payers using any payment application.
• A service SHOULD include at least one instant-settlement option (e.g., 'lightning-bolt11') where the use case demands low-latency payment verification.
• A service MUST NOT include personally identifiable information in invoice payloads beyond what is required for payment routing.
• Services SHOULD keep session expiry times appropriately short for instant-settlement options (10 to 30 minutes) and appropriately generous for bank-transfer options (1 to 3 business days).

6.2 Client Behavior¶

• Clients SHOULD present all payment options to the user, ordered from most to least preferred, to allow the user or automated agent to select the most suitable option.
• Automated agents SHOULD prefer instant-settlement options because these can be completed and verified programmatically without user interaction.
• Clients presenting a user interface SHOULD render URI-based options (e.g., payto URIs) as QR codes to facilitate payment from a mobile banking or wallet application.
• Clients MUST NOT silently retry a stanza without presenting payment options to the user unless the client has been explicitly configured by the user to auto-pay up to a defined amount threshold.
• If the 'expires' time has passed before the user initiates payment, the client SHOULD request a fresh invoice via the proactive IQ flow rather than attempting to pay an expired one.

10.1 Replay Attacks¶

Session identifiers MUST be unique and single-use. A service MUST maintain a record of consumed session identifiers for at least as long as the invoice expiry window to prevent replay attacks. Reusing a session identifier to obtain multiple access grants MUST be rejected.

10.2 Session Binding¶

Because XMPP servers routinely mutate stanzas in transit — adding elements such as <delay/>, rewriting the 'from' attribute, injecting stream management acknowledgements, and normalizing namespace prefixes — it is not possible for a service to cryptographically bind an invoice to the byte content of the stanza it declined. Body-level hashing, as used by HTTP-based payment protocols, is therefore not applicable in XMPP.

Instead, services SHOULD bind the 'session' attribute value to the parameters of the invoice itself using a keyed hash (HMAC). The RECOMMENDED input to the HMAC is the concatenation of: the service's JID, the 'purpose' value, the 'expires' value, and the total amount per scheme. Where the invoice was issued in response to a proactive <get-invoice/> request whose 'target' attribute identifies a specific resource (e.g., a content hash, a file identifier, or a room JID), the 'target' value SHOULD also be included as an HMAC input. This binds the session to the specific resource being purchased, so that a client cannot present a session identifier paid for resource A to obtain access to resource B.

Upon receiving a retried stanza, the service SHOULD recompute the HMAC over the same inputs and compare it against the received 'session' value. A session value that does not match MUST be rejected. This mechanism does not depend on any property of the client-supplied stanza, and therefore survives any server-side stanza mutation in transit.

10.3 Invoice Tampering¶

An intermediary XMPP server could modify <invoice/> contents in transit, redirecting payment destinations to attacker-controlled accounts. Implementations SHOULD use end-to-end encryption (e.g., OMEMO Encryption (XEP-0384) [7]) when the integrity of invoice contents is critical. For Lightning Network options, stateless preimage verification protects the service from granting access without payment: because the session identifier is bound to the payment hash (see Session Binding), a tampered invoice would yield a preimage that fails verification. This does not protect the payer, who may still send funds to an attacker; end-to-end encryption is required for that.

For traditional bank transfer options, no equivalent cryptographic binding between the invoice and the beneficiary account exists. Users SHOULD independently verify beneficiary account details before initiating a bank transfer, particularly when communicating with a service for the first time.

10.4 Financial Safety¶

Clients MUST NOT automatically pay an invoice above a configurable amount threshold without explicit user confirmation. Implementations SHOULD default this threshold to zero (i.e., all payments require explicit user approval) and SHOULD allow the user to raise it. Automated agents operating within a pre-authorized budget MAY raise this threshold programmatically for their specific use case, but MUST NOT do so without the knowledge and consent of the account holder.

13.1 Protocol Namespaces¶

The XMPP Registrar [8] shall include 'urn:xmpp:payment:0' in its registry of protocol namespaces.

If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

13.2 Service Discovery Features¶

The XMPP Registrar [8] shall include the following features in its registry of service discovery features (see <https://xmpp.org/registrar/disco-features.html>):

• urn:xmpp:payment:0
• urn:xmpp:payment:0#invoice-request
• urn:xmpp:payment:0#receipt

An entity that supports the error-flow portion of this protocol MUST advertise the feature 'urn:xmpp:payment:0'. An entity that additionally supports the proactive IQ-based invoice request MUST advertise 'urn:xmpp:payment:0#invoice-request'. An entity that supports emitting <receipt/> elements upon successful payment MUST advertise 'urn:xmpp:payment:0#receipt'.

13.3 Payment Schemes Registry¶

The XMPP Registrar [8] shall maintain a registry of payment scheme identifiers for use in the 'scheme' attribute of the <option/> element. The RECOMMENDED process for registering a new scheme is to define it in a Standards Track XEP or in a published specification and submit a registration request to the XMPP Registrar [8].

Each registration MUST specify all of the following:

1. Scheme identifier — A unique lowercase ASCII string used as the value of the 'scheme' attribute (e.g., payto, lightning-bolt11).
2. Payload format — The syntax and semantics of the character data of the <option/> element when this scheme is used (e.g., a payto URI per RFC 8905, a BOLT 11 invoice string).
3. Proof format — The proof type(s) that MAY accompany a <payment/> element for this scheme, and the syntax of the proof token (or explicitly "none" if no machine-verifiable proof exists for this scheme).
4. Verification procedure — A description of how a service can verify that a payment was made, including any constraints on timing, idempotency, and the handling of asynchronous settlement.

The initial contents of this registry are as follows.

Implementors MAY define private or experimental schemes using reverse-domain-name notation (e.g., com.example.custompay) without XMPP Registrar [8] registration. Public schemes intended for interoperability MUST be registered.

13.4 Proof Types Registry¶

The XMPP Registrar [8] shall maintain a registry of proof type identifiers for use in the 'type' attribute of the <proof/> element. The initial contents of this registry are as follows.

13.5 Invoice Request Service Registry¶

The XMPP Registrar [8] shall maintain a registry of service type identifiers for use in the 'service' attribute of the <get-invoice/> element. The initial contents of this registry are as follows.

14.1 Using Data Forms for the Invoice¶

Data Forms (XEP-0004) [10] Data Forms were considered as the vehicle for invoice delivery, since CAPTCHA Forms (XEP-0158) [2] already uses them for challenges. Data Forms were rejected for the primary invoice format because the structured multi-element nature of an invoice (multiple <option/> children, each with a payload string and a display annotation) does not map naturally onto flat form fields, and because a dedicated element is more self-describing and easier to parse for automated agents. Data Forms are retained only for the CAPTCHA Forms (XEP-0158) [2] integration use case, where the payment option appears as a single field alongside other challenge fields.

14.2 Choosing auth as the Error Type¶

The "auth" error type was chosen for the payment-required error rather than, say, "cancel" or a new type, because the payer genuinely lacks authorization to perform the requested action until payment is made. This mirrors the semantics of HTTP 402 and is consistent with the existing use of "auth" for <registration-required/> in RFC 6120 [11].

14.3 Streaming Payment Sessions¶

This specification defines only single-payment ("charge") semantics: one invoice, one payment, one grant. For high-frequency use cases such as per-query AI agent bots, this model requires a new invoice round-trip for every request, which introduces latency and overhead.

A future companion specification MAY define streaming payment session semantics, analogous to the session intent in the Machine Payments Protocol (MPP). In such a model, an agent would open a payment channel by pre-funding it, and subsequent requests within the same channel would be settled using off-chain cryptographic vouchers without requiring a new invoice or an on-chain transaction per query. Such a specification would advertise support via a new feature (e.g., 'urn:xmpp:payment:0#session') and is outside the scope of this document.

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

1. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.

2. XEP-0158: CAPTCHA Forms <https://xmpp.org/extensions/xep-0158.html>.

3. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.

4. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.

5. XEP-0050: Ad-Hoc Commands <https://xmpp.org/extensions/xep-0050.html>.

6. XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>.

7. XEP-0384: OMEMO Encryption <https://xmpp.org/extensions/xep-0384.html>.

8. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

9. XEP-0363: HTTP File Upload <https://xmpp.org/extensions/xep-0363.html>.

10. XEP-0004: Data Forms <https://xmpp.org/extensions/xep-0004.html>.

11. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.