From fb20b7c15b4ae9cfcfe310ac31a5cd8d56b63ef0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Poisson?= Date: Thu, 22 Jul 2021 11:18:42 +0200 Subject: [PATCH] ProtoXEP: Disco Feature Attachment --- inbox/disco-feature-attachment.xml | 139 +++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 inbox/disco-feature-attachment.xml diff --git a/inbox/disco-feature-attachment.xml b/inbox/disco-feature-attachment.xml new file mode 100644 index 00000000..df097155 --- /dev/null +++ b/inbox/disco-feature-attachment.xml @@ -0,0 +1,139 @@ + + +%ents; +]> + + +
+ Disco Feature Attachment + This specification provides a way to indicate that a feature is implemented for a specific namespace + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0030 + + + + dfa + + Jérôme + Poisson + goffi@goffi.org + goffi@jabber.fr + + + 0.0.1 + 2021-07-22 + jp +

First draft.

 + +
+ +

&xep0030; 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 &xep0059; and supports both &xep0163; and &xep0313;, 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 &xep0060; 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.

+ + +

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 &xep0030; without any other extensions.

+ + + +
    +
  • Attached Feature — feature being attached to a specific functionality (e.g.: &xep0059;).
    • +
  • Root Namespace — the main namespace of attached feature, the one normally advertised with &xep0030; (e.g.: http://jabber.org/protocol/rsm)
    • +
  • Target Feature — feature on which the attached feature is implemented (e.g.: &xep0060;).
    • +
  • 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)
    • +
+ + + +

An XMPP server example.com wants to advertise support for &xep0059;, it is implemented for:

+
    +
  • &xep0030; (for discovering items)
    • +
  • &xep0163;
    • +
  • &xep0313;
    • +
+

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:

+ + + +]]> + + + … + + + + + … + + +]]> + + + +

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 &xep0413; feature is implemented for &xep0060;".

+

If a functionality has several namespaces linked to it (e.g. &xep0060; 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 &xep0030; (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.

+ + + + +

If an entity supports the "Disco Feature Attachment" protocol, it MUST advertise it by including the "urn:xmpp:dfa:0" discovery feature &NSNOTE; in response to a &xep0030; information request:

+ + + +]]> + + + … + + … + + +]]> + + + +

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

+ + +

This document requires no interaction with &IANA;.

+ + +

TODO

+ + +

TODO

+ +