XEP-0060 / XEP-0248: Improve separation of 'collections' #1455
Conversation
Moves section 5.2 "Discover Nodes" from XEP-0060 (which has text and examples that are based on hierarchies / collections) to XEP-0248, replacing therein the section of the same name and number (which did _not_ explictly use hierarchy in its example). Section 5.2 in XEP-0060 is replaces with text and examples that do not use any hierarchy. This change makes explicit a requirement (MUST) to enable entities to discover the nodes in the service by means of the Service Discovery protocol. Prior to this commit, this requirement arguably applied only to a hierarchy of nodes.
…ailable Prevents conflicts in protocols that provide a 'node' attribute, where the absense of a 'node' value is significant (such as to distinguish between 'Node Discovery' and 'Item Discovery').
…60 to XEP-0248 Prior to this change XEP-0060 described changing a leaf to a collection, while XEP-0248 described changing a collection to a leaf (but uses generic language that is easily interpreted as if node type changes are not allowable at all). By having both processes be specified in XEP-0248, there is a lot less room for ambiguity (while it also further reduces complexity in XEP-0060).
XEP-0060 should no longer reference to XEP-0248 for a 'process to retrieve the default subscription configuration options for collection nodes'. Such process is not explicitly defined in XEP-0248 (meaning that the process is equal to that in XEP-0060), meaning that the reference is more likely to cause confusion than clarity. Although additional configuration options (but not a new process) are provided in XEP-0248, it is perfectly reasonable for readers to expect that type-specific configuration is to be found in type-specific XEPs.
… from XEP-0060 to XEP-0248 The hard requirement that is specific to collection nodes should be defined in the XEP for collection nodes.
…d standardization Removes from XEP-0060 field standardization that already exists in XEP-0248.
…gistration is duplicated in XEP-0248
|
CI checks fail because this PR changes more than one XEP. Although I understand that this is generally inadvisable, that's deliberately done here, as texts have been moving between two XEPs. (as an aside: I could have sworn that I modified workflow scripts to allow for having more than one XEP in a PR?) |
guusdk
added
the
Needs Council
|
This looks great. I do wonder if 0060 should have an informational reference to 0248 somewhere just so people know to read both? |
| <p>Note: Node hierarchies and collection nodes are OPTIONAL. For details, refer to the <link url='#impl-semantics'>NodeID Semantics</link> and <link url='#collections'>Collection Nodes</link> sections of this document.</p> | ||
| <p>In the first example, an entity sends a service discovery items ("disco#items") request to the root node (i.e., the service itself), which is a <link url='#collections'>Collection Node</link>:</p> | ||
| <example caption='Entity asks service for all first-level nodes'><
There was a problem hiding this comment.
A service MUST enable entities to discover the nodes
This must be a SHOULD here, the original MUST was for pubsub services implementing hierarchy only, but a pubsub service may decide to not show its nodes with disco#items (to keep them private for instance).
There was a problem hiding this comment.
I don't object to changing this MUST to a SHOULD in XEP-0060. I believe that this indeed most closely resembles the gist of this section prior to the changes in this PR. I can, however, imagine that other Council members find this debatable. I suggest that we hold off applying this particular change until there's confirmation of consensus among Council members.
I have verified that the MUST has been moved to XEP-0248, where I think it is obvious that it is needed there.
There was a problem hiding this comment.
Having a MUST here changes the behaviour of the original XEP, and there are definitely services which don't show their nodes on disco#items (in fact, a pubsub service can even show different nodes depending on the requesting entity or other factors). So it would make some existing implementations incompatible.
Of course I'm fine with bringing that to other council members, I'll paste the link to this in the room.
Regarding XEP-248, yes there it must clearly be a MUST.
There was a problem hiding this comment.
Note that another acceptable option, is to keep a MUST but specify explicitly that the list can be empty, or the listed nodes can differ according to requesting entity or other service-specific parameters, and that nodes can be hidden from this list.
There was a problem hiding this comment.
I am certainly not against any of this at all. I just want to prevent you and me making a change to the proposed change-set while other Council members are still evaluating. That could be confusing, particularly if other Council members would prefer a different approach.
I'm leaning towards your first suggestion (but would be fine with the second suggestion, too). Let's just wait for consensus withing Council on this particular change, before applying the change.
There already is! Notably, in the Glossary, that defines "Collection Node" there's a link to XEP-0248, and it's mentioned & linked to in a couple of different places, too. We could add more, but that feels superfluous to me. |
In version 1.12 of XEP-0060, the concept of PubSub Collection Nodes was split off to a new document, XEP-0248.
To date, various hierarchy/collection related bits of specification linger in XEP-0060. This adds needless complexity to a XEP that's already rather complex. This PR tries to clean that up, by more clearly separating concerns.
The changes herein are discussed on the mailing list, in https://mail.jabber.org/hyperkitty/list/[email protected]/thread/COEJQNNCEHHT2WFF46CWYYYVCL2NIOE4/ Not every change in this PR has been discussed on the mailinglist yet, but I suspect that by the time that this PR gets processed by Editor/Board, it has. If significant concerns do pop up, I'll change the status of this PR to 'draft'.
I have kept individual changes isolated, to improve reviewability.
My personal motivation is triggered by adding support for this XEP to our interop test project, which proved to be difficult to do without taking into account node hierarchies and collections. I imagine that the reason for splitting off XEP-0248 form XEP-0060 is to avoid just that.