XMPP Council - 2022-09-28

o/

👋

$ unicode 👋 U+1F44B WAVING HAND SIGN

daniel, moparisthebest?

Ge0rG,?

anyone?

Here. Sorry

1) roll call

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

I am here, fwiw

Me too ;)

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

2) Agenda bashing

nothing to bash

I'm more of a zsh type anyway

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

go implement it by the way. channel binding is cool

ISTR I implemented SCRAM-PLUS some time

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

4) Items for voting

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

I found the title very confusing

+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

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

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

but I also don’t really have a better name

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 :-)

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

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

is xcal still a thing?

xcal is an RFC yes

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

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

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

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

larma, do you want to cast a vote?

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

ok. moving on

5) Pending votes

none

6) Date of next

+1w wfm

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

+1w wfm

+1w wfm

7) AOB

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

8) Close

thank you all

o/

thanks!

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

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

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

I recorded both your votes

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

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

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. ✏

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.

I will go with the significant drawbacks here.

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?

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

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

larma: like muc or pubsub ?

More like XHTML

Or jingle or anything else that is complicated

larma: lacking implementations is rectified much easier than lacking standards

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

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

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

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

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

> 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

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