[Standards] Proposed XMPP Extension: Events
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
> 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
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.
More information about the Standards