go implement it by the way. channel binding is cool
jonas’
ISTR I implemented SCRAM-PLUS some time
daniel
and with tls-exporter we also have all the building blocks now
daniel
4) Items for voting
daniel
a) Proposed XMPP Extension: Events
(https://xmpp.org/extensions/inbox/events.html)
jonas’
I found the title very confusing
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
jonas’
it notably is not about type='headline' "events" telling you about new items
daniel
yes I agree. I was also expecting some system notification event thing before I read it
daniel
but I also don’t really have a better name
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 :-)
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
jonas’
then again, I have no stakes in that game, so +0
daniel
is xcal still a thing?
Zash
xcal is an RFC yes
jonas’
the XEP mentions https://xmpp.org/extensions/xep-0097.html
Zash
https://www.rfc-editor.org/rfc/rfc6321
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
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
daniel
larma, do you want to cast a vote?
larma
Even with those issues mentioned I'm still +1 because it's good enough for experimental and likely is going to advance XMPP
daniel
ok. moving on
daniel
5) Pending votes
daniel
none
daniel
6) Date of next
jonas’
+1w wfm
daniel
I might only be available on mobile next week. but i think that'll be fine
daniel
+1w wfm
larma
+1w wfm
daniel
7) AOB
daniel
I don’t see anyone sending typing notifications so I guess none
daniel
8) Close
daniel
thank you all
jonas’
o/
jonas’
thanks!
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
Ge0rG
(I'll change to a hesitant +1 if this rationale is added)
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
daniel
I recorded both your votes
Ge0rG
There are probably very few developers sufficiently dedicated to xmpp to fully implement a new proprietary calendar format.
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
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
pprrkshas left
pprrkshas joined
sonnyhas left
sonnyhas joined
MSavoritias (fae,ve)has left
MSavoritias (fae,ve)has joined
Kevhas left
pprrkshas left
pprrkshas joined
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.✎
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. ✏
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.
larma
I will go with the significant drawbacks here.
pprrkshas left
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?
pprrkshas joined
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
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
moparisthebest
larma: like muc or pubsub ?
larma
More like XHTML
moparisthebest
Or jingle or anything else that is complicated
MSavoritias (fae,ve)has left
MSavoritias (fae,ve)has joined
pprrkshas left
pprrkshas joined
pprrkshas left
pprrkshas joined
jonas’
larma: lacking implementations is rectified much easier than lacking standards
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✎
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 ✏
Tobiashas left
Tobiashas joined
larma
jonas’: not actually getting your point. Fact is, we lack a proper standard. iCal is mostly defined as "whatever Outlook supports"
Zash
Actual actual reality: People will just use Facebook to plan gatherings. :(
Tobiashas left
Tobiashas joined
moparisthebest
https://datatracker.ietf.org/doc/html/rfc5545 sure looks like a standard
moparisthebest
https://en.wikipedia.org/wiki/ICalendar links all the RFC updates
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
Tobiashas left
Tobiashas joined
moparisthebest
So, original iCal already supports XMPP addresses and RSVP etc, really seems like a terrible idea to re-invent the wheel