[Standards] Proposed XMPP Extension: Disco Feature Attachment

goffi goffi at goffi.org
Tue Aug 10 16:25:38 UTC 2021


Le 2021-08-09 02:08, Stephen Paul Weber a écrit :
> My main observation about this proposal is that it attaches meaning to
> otherwise-opaque var strings, and in general reads more like a hack 
> than a
> solution.  I am sympathetic to the need here, but I think we can solve 
> it
> without resorting to this, and even still without needing to update 
> caps.  Disco
> and Caps already define a solid extensability mechanism as data forms 
> to be
> included with the info.  This proposal could perhaps look something 
> like this:
> 
> <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'/>
>    <x xmlns="jabber:x:data">
>        <field type="hidden" var="FORM_TYPE">
>            <value>urn:xmpp:feature-attachments</value>
>        </field>
>        <field var="http://jabber.org/protocol/rsm">
>          <value>http://jabber.org/protoco/pubsub</value>
>          <value>urn:xmpp:mam:2</value>
>          <value>http://jabber.org/protocol/disco#items</value>
>        </field>
>    </x>
>>  </query>
> </iq>
> 
> Thus anyone not implementing the XEP sees exactly what the do 
> currently, caps
> will work unmodified, but anyone implementing the XEP can easily (and 
> dare I say
> *more* easily) get the list of attached features to any given other 
> feature.


Hi Stephen,

Thank you very much for your suggestion, I find your proposal far better 
than mine.
My proposition was a working base for a problem I want to see solved, so 
if the protoXEP passes council (and if council member who have voted in 
favor of it are OK with it), I can publish a new version using this 
solution, and add you as an author.

We have been discussing this suggestion and protoXEP in general on xsf@ 
MUC room (unfortunately, I would have rather seen the discussions 
happening here), and there were some useful arguments.
As I remember, the main points were (I don't necessarily agree with all 
of them):

- disco feature string should be opaque, and my proposal break this by 
doing a construction
- added complexity: my proposal is more straightforward to implement (we 
just have to look as the attachment namespace to know if a feature is 
attached to an other one), while yours must be done in two steps
- having a generic solution may bring non sense while attaching randomly 
to features (e.g. RSM on MUC)
- it would be better to specify feature attachment directly on the 
concerned XEPs (e.g. directly on RSM or Order-By)

In my opinion, your proposition is cleaner, takes elegantly profit of 
data forms/disco extensions, and doesn't feel like a hack. I don't think 
the extra complexity is a big problem.

I also think a generic XEP is needed to have a common syntax, and to 
know if disco-feature attachment is implemented (otherwise we don't know 
for older XEPs if a announced feature is implemented for it or not, and 
some XEPs are in state which prevent namespace bumps).
Furthermore, having a generic XEPs explaining the syntax doesn't prevent 
to mention it and to explain how exactly the feature is attached (e.g. 
what does it mean using Order-By with Pubsub, and how to use it).

I would love to see feedbacks here, I think that the problem we are 
trying to solve is affecting a couple of XEPs and many people are 
concerned.

Thanks
Goffi


More information about the Standards mailing list