XEP-xxxx: Disco Feature Attachment

1. Introduction¶

Service Discovery (XEP-0030) [1] is ubiquitous tools used by nearly every XMPP implementation. It's handy to declare that an entity implements a specific feature, but it can be confusing when a feature may be part of several functionalities. For instance, if a server advertise support Result Set Management (XEP-0059) [2] and supports both Personal Eventing Protocol (XEP-0163) [3] and Message Archive Management (XEP-0313) [4], we don't know if RSM is implemented only for PEP, only for MAM, or for both (it could be also implemented for other functionalities such as disco items).

In Publish-Subscribe (XEP-0060) [5] there is a workaround which proposes to use http://jabber.org/protocol/pubsub#rsm, but this solution doesn't tell if RSM is implemented for MAM or any other protocol, it is Pubsub specific and not extensible.

To fix this situation, this XEP proposes a simple way to advertise that a feature is implemented for a specific functionality.

2. Requirements¶

It should be easy to implement Disco Feature Attachment both for the advertising entity and the requesting one, thus, the main requirement is to be based on Service Discovery (XEP-0030) [1] without any other extensions.

3. Glossary¶

• Attached Feature — feature being attached to a specific functionality (e.g.: Result Set Management (XEP-0059) [2]).
• Root Namespace — the main namespace of attached feature, the one normally advertised with Service Discovery (XEP-0030) [1] (e.g.: http://jabber.org/protocol/rsm)
• Target Feature — feature on which the attached feature is implemented (e.g.: Publish-Subscribe (XEP-0060) [5]).
• Target Namespace — namespace of the feature on which attached feature is implemented (e.g. http://jabber.org/protocol/pubsub)
• Attachment Namespace — namespace indicating that a feature is attached to an other one. (e.g. http://jabber.org/protocol/rsm@http://jabber.org/protocol/pubsub)

4. Use Cases¶

An XMPP server example.com wants to advertise support for Result Set Management (XEP-0059) [2], it is implemented for:

• Service Discovery (XEP-0030) [1] (for discovering items)
• Personal Eventing Protocol (XEP-0163) [3]
• Message Archive Management (XEP-0313) [4]

To do that, the server MUST advertise the root namespace as usual (here http://jabber.org/protocol/rsm), and it MUST advertise the attachment namespace for every supported target feature:

<iq from='example.org'
    id='disco1'
    to='example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='example.com'
    id='disco1'
    to='example.org'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    …
    <feature var='http://jabber.org/protocol/rsm'/>
    <feature var='http://jabber.org/protocol/rsm@http://jabber.org/protocol/pubsub'/>
    <feature var='http://jabber.org/protocol/rsm@urn:xmpp:mam:2'/>
    <feature var='http://jabber.org/protocol/rsm@http://jabber.org/protocol/disco#items'/>
    …
  </query>
</iq>

5. Business Rules¶

An attachment namespace is build by concatenating those 3 strings

• the root namespace of the attached feature (e.g.: urn:xmpp:order-by:1)
• the character @
• the target namespace (e.g.: http://jabber.org/protocol/pubsub)

Here the resulting attachment namespace is urn:xmpp:order-by:1@http://jabber.org/protocol/pubsub and it means "the Order-By (XEP-0413) [6] feature is implemented for Publish-Subscribe (XEP-0060) [5]".

If a functionality has several namespaces linked to it (e.g. Publish-Subscribe (XEP-0060) [5] has http://jabber.org/protocol/pubsub, http://jabber.org/protocol/pubsub#owner, http://jabber.org/protocol/pubsub#event, etc.), the one to be chosen it the one used for advertising with Service Discovery (XEP-0030) [1] (here it's http://jabber.org/protocol/pubsub).

If attached feature is only implemented for part of a functionality, only the corresponding namespace must be used in attachment namespace (e.g. if RSM is implemented only for discovering items but not features, the attachment namespace to advertise is only http://jabber.org/protocol/rsm@http://jabber.org/protocol/disco#items).

If a XEP has special requirements regarding disco feature attachments, then they MAY be specified there, in which case they take precedence over the rules defined here.

6. discovering support¶

If an entity supports the "Disco Feature Attachment" protocol, it MUST advertise it by including the "urn:xmpp:dfa:0" discovery feature (see Protocol Namespaces regarding issuance of one or more permanent namespaces) in response to a Service Discovery (XEP-0030) [1] information request:

<iq from='example.org'
    id='disco1'
    to='example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='example.com'
    id='disco1'
    to='example.org'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    …
    <feature var='urn:xmpp:dfa:0'/>
    …
  </query>
</iq>

7. Security Considerations¶

This document introduces no security considerations or concerns above and beyond those discussed in RFC 6120 and RFC 6125.

8. IANA Considerations¶

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].

9. XMPP Registrar Considerations¶

TODO

10. XML Schema¶

TODO

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.1

Last Updated

2021-07-22

Approving Body

XMPP Council

Dependencies

XMPP Core, XEP-0030

Supersedes

None

Superseded By

None

Short Name

dfa

This document in other formats: XML  PDF

Appendix B: Author Information¶

Jérôme Poisson

Email

goffi@goffi.org

JabberID

goffi@jabber.fr

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.1 (2021-07-22)¶

   First draft.

   jp

Appendix I: Bib(La)TeX Entry

@report{poisson2021dfa,
  title = {Disco Feature Attachment},
  author = {Poisson, Jérôme},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2021-07-22/2021-07-22},
}

END