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-unsubscr...@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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
