On 2022/09/23, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Events > Abstract: > This specification describe how to handle events with XMPP.
Thanks Jonas! Thanks Goffi! I have skimmed over the spec, and here are a few comments that shouldn't pose any issue for the move to experimental. > § 5. Events Nodes > [..] > Otherwise, a node may be published on any pubsub service. An events node > SHOULD be prefixed with 'urn:xmpp:events:0/', which SHOULD be followed > by an unique identifier. I suggest using XEP-0462[0] (PubSub Type Filtering) instead, as it's exactly what it is here to do. Fill in `pubsub#type` with `urn:xmpp:events:0` and use an opaque unique identifier as a node name. I would also argue this should be used for nodes on PEP, but I agree advantages are less obvious when node name equals ns. > § 6.4.1 > If the online location is on an XMPP MUC, an <x/> element qualified by > the 'jabber:x:conference' namespace as described in Direct MUC > Invitations (XEP-0249) can be used. Shouldn't this “can” be a MAY or SHOULD instead? in case of a MUC. I wonder how else the information that it is a MUC would be transmitted, as I only see elements to describe HTTP addresses. I understand your main use-case is to convert from AP, which happens in the HTTP world, but maybe there should be a way to add a URI instead of just a URL? > § 6.5 > The <rsvp> element MUST contain form as specified in Data Forms > (XEP-0004) “a form”. It's obvious in the sentence below that it's a single form, but this one is ambiguous. > Example: Romeo Submit his RSVP Answer > <value>>urn:xmpp:events:rsvp:0</value> Contains an additional ">". That's it. Thanks a lot for the work on the AP gateway!
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
