XMPP Council - 2022-09-28


  1. jonas’

    o/

  2. larma

    đź‘‹

  3. jonas’

    $ unicode đź‘‹ U+1F44B WAVING HAND SIGN

  4. jonas’

    daniel, moparisthebest?

  5. jonas’

    Ge0rG,?

  6. jonas’

    anyone?

  7. daniel

    Here. Sorry

  8. daniel

    1) roll call

  9. jonas’

    https://www.youtube.com/watch?v=Xb6ZdLm8rnI maybe that triggers Ge0rG

  10. jonas’

    I am here, fwiw

  11. larma

    Me too ;)

  12. jonas’

    I get the impression we might've lost daniel again?

  13. daniel

    2) Agenda bashing

  14. daniel

    nothing to bash

  15. jonas’

    I'm more of a zsh type anyway

  16. daniel

    3) Editors update * UPDATED: XEP-0440 (SASL Channel-Binding Type Capability) https://xmpp.org/extensions/xep-0440.html

  17. daniel

    go implement it by the way. channel binding is cool

  18. jonas’

    ISTR I implemented SCRAM-PLUS some time

  19. daniel

    and with tls-exporter we also have all the building blocks now

  20. daniel

    4) Items for voting

  21. daniel

    a) Proposed XMPP Extension: Events (https://xmpp.org/extensions/inbox/events.html)

  22. jonas’

    I found the title very confusing

  23. daniel

    +1 I'm not really into calendar stuff so I can’t speak to whether or not it covers everything one would expect. but as an experimental xep it looks good enough to me

  24. jonas’

    it notably is not about type='headline' "events" telling you about new items

  25. daniel

    yes I agree. I was also expecting some system notification event thing before I read it

  26. daniel

    but I also don’t really have a better name

  27. jonas’

    I'm certain it does not, because it's not iCal, and everything which is not that abomination will not be able to cover all corner cases :-)

  28. jonas’

    I'm not sure that introducing a protocol break here is really sensible, and it might be seen as an easy way out of having to deal with iCal, which will only cause pain and sorrow down the road

  29. jonas’

    then again, I have no stakes in that game, so +0

  30. daniel

    is xcal still a thing?

  31. Zash

    xcal is an RFC yes

  32. jonas’

    the XEP mentions https://xmpp.org/extensions/xep-0097.html

  33. Zash

    https://www.rfc-editor.org/rfc/rfc6321

  34. larma

    I would love if the XEP would at least have some guidelines on how to translate the format to others like xcal or iCal - similar as all the Jingle XEPs have some SDP translation

  35. daniel

    yeah like i said my barrier for becoming a XEP has been reached by this. but I'd personally would probalby go with something xcal or ical

  36. daniel

    larma, do you want to cast a vote?

  37. larma

    Even with those issues mentioned I'm still +1 because it's good enough for experimental and likely is going to advance XMPP

  38. daniel

    ok. moving on

  39. daniel

    5) Pending votes

  40. daniel

    none

  41. daniel

    6) Date of next

  42. jonas’

    +1w wfm

  43. daniel

    I might only be available on mobile next week. but i think that'll be fine

  44. daniel

    +1w wfm

  45. larma

    +1w wfm

  46. daniel

    7) AOB

  47. daniel

    I don’t see anyone sending typing notifications so I guess none

  48. daniel

    8) Close

  49. daniel

    thank you all

  50. jonas’

    o/

  51. jonas’

    thanks!

  52. Ge0rG

    I'm sorry for having missed the Meeting. I'm seeing similar issues with Events as discussed by you, and probably a better title would be Calendar Events. However, my gut tells me that reinventing a subset of existing calendar specifications is going to fail in hard and non obvious ways, be it timezone info on the event's location, recurring events or dozens of other problems already solved in existing formats and their implementations. It would be better to sort out how and why existing calendar formats are bad / why the integration in xmpp failed, and to come back with that. My opinion is that this XEP at least needs a very strong rationale for why not to use existing specification, and "We implement RSVP and access permissions" isn't it. You surely can add RSVP for iCal over XMPP and store iCal in pubsub. Therefore am informal -0 from me that I can repeat in the next Meeting or on list some time early next week

  53. Ge0rG

    (I'll change to a hesitant +1 if this rationale is added)

  54. moparisthebest

    Sorry about that, re: events, I'll note example 8 has bad XML and it needs security considerations, regardless I'm a +1 I share everyone else's concerns, seems the calendar format everything else uses should just be used, for example this is missing recurring events and probably many other things, why isn't iCal good enough? Anyway none of that changes that it's good enough for experimental in my opinion

  55. daniel

    I recorded both your votes

  56. Ge0rG

    There are probably very few developers sufficiently dedicated to xmpp to fully implement a new proprietary calendar format.

  57. daniel

    Yes I agree. I follow the jmap calendar development a little bit (I'm not participating just reading the list) and calendar stuff is super complex

  58. larma

    Ge0rG: I disagree with "There are probably very few developers sufficiently dedicated to xmpp to fully implement a new proprietary calendar format." This new format is probably much easier to implement and use than a fully correct iCal implementation. I haven't found two complete and compatible iCal implementations yet, they either lack features or differ so much in how they realize things, that an iCal crested using one library will be parsed to something different in another.

  59. larma

    Ge0rG: I disagree with "There are probably very few developers sufficiently dedicated to xmpp to fully implement a new proprietary calendar format." This new format is probably much easier to implement and use than a fully correct iCal implementation. I haven't found two complete and compatible iCal implementations yet, they either lack features or differ so much in how they realize things, that an iCal created using one library will be parsed to something different in another.

  60. Ge0rG

    larma: like with instant messaging, I argue that the complexity of the format is a consequence of the complexity of the problem domain, and that any re-invented format will ultimately arrive at the same complexity, or come with significant drawbacks.

  61. larma

    I will go with the significant drawbacks here.

  62. Ge0rG

    larma: so you are saying it's impossible to find a set of iCal implementations that cover the common ground in a compatible way, but it's reasonable to expect xmpp developers to create such a set of compatible implementations from scratch?

  63. moparisthebest

    I once needed to create a calendar view of events but instead just spit out an .ics file and opened it with Thunderbird, worked great

  64. larma

    You could probably describe a limited feature set of iCal instead and then find a larger set of compatible implementations. However people ARE going to use existing libraries and ARE going to use more features than the restricted feature set defined and then implementations WILL be incompatible

  65. moparisthebest

    larma: like muc or pubsub ?

  66. larma

    More like XHTML

  67. moparisthebest

    Or jingle or anything else that is complicated

  68. jonas’

    larma: lacking implementations is rectified much easier than lacking standards

  69. jonas’

    your argument is actually swaying me toward the negative, but I'll leave my vote as is and raise my concerns on lost instead

  70. jonas’

    your argument is actually swaying me toward the negative, but I'll leave my vote as is and raise my concerns on list instead

  71. larma

    jonas’: not actually getting your point. Fact is, we lack a proper standard. iCal is mostly defined as "whatever Outlook supports"

  72. Zash

    Actual actual reality: People will just use Facebook to plan gatherings. :(

  73. moparisthebest

    https://datatracker.ietf.org/doc/html/rfc5545 sure looks like a standard

  74. moparisthebest

    https://en.wikipedia.org/wiki/ICalendar links all the RFC updates

  75. moparisthebest

    > 3.3.3. Calendar User Address > Value Name: CAL-ADDRESS > Purpose: This value type is used to identify properties that contain > a calendar user address. > Format Definition: This value type is defined by the following > notation: > cal-address = uri > Description: The value is a URI as defined by [RFC3986] or any other > IANA-registered form for a URI. When used to address an Internet > Desruisseaux Standards Track [Page 31] > RFC 5545 iCalendar September 2009 > email transport address for a calendar user, the value MUST be a > mailto URI, as defined by [RFC2368]. No additional content value > encoding (i.e., BACKSLASH character encoding, see Section 3.3.11) > is defined for this value type. > Example: > mailto:jane_doe@example.com

  76. moparisthebest

    So, original iCal already supports XMPP addresses and RSVP etc, really seems like a terrible idea to re-invent the wheel