On 19/01/2022 10.11, Georg Lukas wrote:
The problem is that I need to have presence subscription to do that on a bare JID (due to
"https://xmpp.org/extensions/xep-0030.html#security";), even if the node I want
to request (in the presence case, it's XEP-0277's microblog node) is open and thus
publicly accessible.
I've made a pull request to update XEP-0030 at
https://github.com/xsf/xeps/pull/1145[1] . My proposal is to remove entirely
those considerations (but to keep ones regarding available resources).
Thanks for providing the PR. I see the rationale and the need for a
change, and I don't disagree with a backward-compatible change.
However, in the specific PR you are completely removing the
"algorithmic" description of what a server is supposed to do and which
exact replies it has to send.
Instead, I would very much welcome a PR that retains the overall
structure that you removed, and instead improves the wording of the
conditions to cover the additional use cases, like nodes with "open"
access model.
An other option could be to keep the consideration, but allow disco#info when a node is specified,
thus one could disco#info with node "urn:xmpp:microblog:0" even without pubsub
subscription, that would keep the "service-unavailble" when no node is specified (but I
think this measure will become totally useless as open nodes will become more common).
If you prefer to go down this path, this would be a change to XEP-0277,
where it can just override the default "MUST NOT" behavior of 0030
without touching the text of 0030, but I really see a need to update
0030 to cover the "open" nodes.
I suppose the concept of open nodes implies that the entity (in this
case a user's bare JID) can no longer be hidden. Then, to me the partial
sentence “or is not otherwise trusted” applies. I.e. everyone is
“otherwise trusted” now. A service may still choose to restrict what it
returns in response to a disco#info request, based on the existence of a
presence relationship. E.g. will respond with pubsub#rsm but not other
stuff.
Given the above, potentially no changes are needed, but clarifications
might help.
--
ralphm
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
