[Standards] Proposed XMPP Extension: Events

Goffi goffi at goffi.org
Fri Sep 30 19:43:18 UTC 2022


Le vendredi 23 septembre 2022, 17:48:38 CEST Jonas Schäfer a écrit :
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Events
> Abstract:
> This specification describe how to handle events with XMPP.
> 
> URL: https://xmpp.org/extensions/inbox/events.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
> 

Hi,

I've read council logs, and about the title, I was about to propose "Calendar 
Events" and I saw that Ge0rG did the same, thus if the protoXEP is accepted, I 
will modify the title accordingly.

This protoXEP is the result of my own experience (I've implemented events with 
a custom protocols for years), and adaptation of metadata seen on ActivityPub 
(Mobilizon) as I've implemented an AP gateway handling events.

About why iCal has not been used directly, here are the rationales:

- iCal uses its own formats which is conflicting with XMPP. For instance, 
binaries are either using base64 encoding or URLs, when we already have things 
well suited for XMPP (stateless file sharing with XEP-0447).
What if an attachment is available via Jingle FT (XEP-0234) for instance? For 
localisation we would have to parse iCal way when we already have XEP-0080. 
Same for datetimes with XEP-0082. In general, using iCal is re-doing many 
thing that we already have.

- iCal is made for emails (even if it's independent of transport), and many 
URL must be "mailto" (e.g. organiser). Thus we would have to hack "it's iCal 
but we're not following the standard because we must adapt it to XMPP"

- when XEP dependencies are already implemented, my proposal is super easy to 
implement. With an iCal format, you would end-up by looking for an iCal 
parser, with potential dragons there.

- from my experience with blogging (XEP-0277, which uses Atom), it's not 
necessarily a good idea to re-use verbatim an existing protocol. You end-up 
doing hacks to adapt it to XMPP (XEP-0277 talks about XHTML-IM for instance, 
which is not even used in practice in existing implementations), weird stuff 
(when there is not title, content is put to title to match Atom constraints), 
and people using stuff not specified in the XEP in potentially different ways 
(for instance Movim is looking for the presence of an http "alternate" link to 
determine if it can use the post in its discovery feature, but that's not 
specified in the XEP).

If I were to redesign XMPP blog, I would probably not use Atom.

- iCal has its own (ugly) extension mechanism, with non-standard properties, 
while proper extension is one of the major strengths of XMPP. We should not 
end up in a state were each project add its own proprietary stuff and we have 
to check other codes to know what to do (that's what is happening in 
ActivityPub world due to loose specs, and I think that XMPP way is better).

- there are external features that iCal handles like TODO or Alarm, and I have 
the feeling that those must be put in separated XEPs with proper disco 
advertising. Using iCal verbatim makes the thing more complicated.

- my proposal is adapted to event organisation/sharing, iCal is only doing 
part of this. Heading picture is supported, RSVP takes profits of existing 
pubsub features (with automatic summary) and can be simply extended to ask for 
extra information (e.g. allergy information for dinner), invitee list are 
handled and uses pubsub permissions, comments can be added, as well as a blog. 
All those feature are not possible with iCal alone.

- my proposal is not reinventing the wheel, quite the opposite actually: it's 
re-using existing XMPP feature instead of trying to adapt something else.

- and last but not least, iCal metadata can actually be used, that's what the 
"extra data" (https://xmpp.org/extensions/inbox/events.html#extra) is for. We 
just need to map explicitly iCal metadata to the propose data form field type. 
Thus nothing is lost here


Thanks for the feedbacks, and I hope that my points make sense to everybody.

King regards
Goffi




More information about the Standards mailing list