XSF Discussion - 2019-03-14

One question about that `XMPP WG`, what would be the difference between the XSF and that?

Or would it be just like a bridge?

zinid was questioning the usefulness of the XSF (to him)

You'd have to read yesterday's logs

I was paying attention

Still, if he pursues to have that group be reopened, would the XSF and that group clash?

I don't think so. Who do you think would be in that group?

Also, it seems he's left these channels.

If there is benefit from having an IETF XMPP WG, we should consider doing it.

It was hard to deduce the arguments, though.

dwd mentioned something yestersay, unrelated to zinid, I think

I've read one: marketing. People would be more inclined to work on XMPP when it is affiliated with the IETF, as that's more well known that the XSF.

That he thought might be useful to have the WG for again.

No it was work already done at IETF

I don't think that the marketing angle in itself is enough to warrant this. XMPP already is an IETF protocol.

I got the impression that the suggested move to the IETF had more to do with him not finding the XSF to be effective, and wanting to go around that.

a) I disagree, and b) you'd likely end up with the same people and similar processes at IETF>

a) I disagree, and b) you'd likely end up with the same people and similar processes at IETF.

Aftear reading him I couldn't get an idea of what was the problem. I understood that he feels the image of the XSF does not help him enough when contacting customers, but the image of the IETF would.

And also that he would expect the XSF to be more active regarding the direction of the protocol, writing XEPs and so on

The latter was Andrews wish/opinion/point of view, I think, not Zinids. I think it's unrelated to the IETF WG discussin.

The latter was Andrews wish/opinion/point of view, I think, not Zinids. I think it's unrelated to the IETF WG discussion.

Well, it was not clear enough the point of the discussion in my opinion :D

I think that using an IETF workgroup is to foster more interaction with people outside of our community, to align with existing efforts for encryption, authentication, alternative bindings (like QUIC), etc.

As we spend a good deal of time on this, I've heard barely any arguments, and I've not heard anyone else express the same wish, I think it'd be good to pause this discussion.

ralphm i believe to suggestion was: "replace XSF with an IETF workgroup". The XSF working with IETF is something that I think we've been doing, and should consider doing so.

Yes, what ralphm mentions is what I though dwd was explaining

ralphm i believe the suggestion was: "replace XSF with an IETF workgroup". The XSF working with IETF is something that I think we've been doing, and should consider doing so.

ralphm i believe the suggestion was: "replace XSF with an IETF workgroup". The XSF working with IETF is something that I think we've been doing, and should keep doing.

You can't form an XMPP WG in the IETF without some fairly explicit work to do (in IETF parlance, a charter).

Charters give the scope of the Working Group, and also a set of milestones - witth dates - that they try to meet.

Sounds efficient :O

There's an interesting discussion to be had around charters, since I think both Andrew and Evgeny expressed concern at the timeframe of MIX, for example.

I feel that we've been spending an imbalanced amount of time on this, based on the malcontent of _one_ (maybe two) persons. Let's drop this, until we have indication that the membership wants to pursue this further.

Guus, FWIW, I would suggest we (the XSF) look into establishing a formal liaison with the IETF.

dwd what would that look like in practice?

Guus, Beyond that, the rest is a Council issue of what work we think might be better redirected to the IETF.

Guus: I'm talking about what I consider good reasons to attempt to reestablish a WG. Since zinid did not make a convincing case, and literally said he wanted to end the conversation, I am not going to spend much time on his supposed reasons.

Guus, https://www.ietf.org/about/liaisons/

And also what would we need to do

dwd: yes, that's definitely interesting.

Seve, Write a charter, and get a relevant AD to be interested. That's all a WG needs.

And people

I wonder if setting up and maintaining an IETF liaison would be more trouble than it's worth. I'm not seeing the two motivations for having a liaison apply to us much ("Prevent inadvertent duplication of effort, without obstructing either organization from pursuing its own mandate", "Provide authoritative information of one organization’s dependence on the other’s work")

Guus, ralphm - I note that some guy called Matt Miller is already a Liaison Manager, it might be worth asking him on his opinion.

I'm not rejecting the thought outright, though.

oh, that's interesting 🙂

dwd: why would we contact this random individual?

🤣

Or should I say, (-:

Previously the... Board? COuncil? decided that we had enough folks who regularly worked within the IETF not to bother, but I think most of our heavywieght IETFers have drifted away from the XSF in their day tto day work (including M&M, Joe, StPeter).

dwd: indeed

That's interesting but on the other hand, as it was explained to Zinid, XEPs are made by the community, and so on. Looks like we would need to set a some kind of internal `charter` in order to approach them.

The standards JIG has a charter. It just doesn't have specific goals in terms of direction or timelines.

Seve, Oh, gosh no. The IETF works much the same as the XSF. It has a little more process and a lot of people involved, but it's still just a bunch of tch people.

Haha ok :)

Seve setting up a liaison relation with the IETF would not in any way make the IETF produce XMPP stuff. It's more about knowing about eachother, and keeping track of what the other is doing.

Guus, yes yes, that is what I understood. But I also thought we would need to provide some work we would like to do, let's say. Like what ralphm mentioned about, encryption or whatever the topic is.

Seve, It would have meant the XSF being formally notified about the SACM/MILE work using XMPP, for example. We might choose to notify them in return about Zinid's RELOAD work.

Thank you :)

dwd maybe make your case on the members list?

Seve, Moving work to the IETF is a different matter - though a liaison statement might help a bit, we'd really just have a bunch of interested people go do the work there.

I think this is a matter for the standards list, to be honest. Members is too narrow and e.g. zinid and Andrew aren't members, right?

I was under the impression that the IETF is aware of the XSF and that it's the body responsible for XMPP. Is a liaison giving us more than that?

If someone would really want to charter the work on MIX, they can propose a SIG for it. We've had those before. Not sure if it is a good idea.

Ge0rG: a more formalized relationship

No

But yes, good idea to move it to the standards list, ralphm.

I think this is more of an organisational list than a standards discussion </pedantic>

Guus: well, that list happens to be the venue for all XEPs, including procedural ones

... we're going to use a XEP for this?

Guus, true :)

That's not what I said, but I think that a) this topic is wider than just the membership, b) the primary objective is to establish a liaison for standards development.

Doing it as a XEP doesn't seem like a bad idea, to me, though.

I disagree, but don't object.

A XEP is just our typical vehicle for formalizing protocols, best of practices, and things like SIGs, beyond what's in our bylaws.

Even though the last P current stands for Protocol, I think that the previous meaning of Proposal was more apt.

Because it is closer to how we've used them.

E.g. if you want to know what a SIG is and how to form one, I'd direct you to XEP-0002.

If you want to know what the Registrar does: XEP-0053.

although tempted to discuss this further, I think we should first decide on the color of the shed in which bikes are stored temporarily. 🙂

I'm not really discussing, I'm just relaying how things have been done.

There are procedures for creating new functions and where to discuss them.

Even if the proposal would say: Board appoints, having that written down in a short XEP, instead of hidden in Board minutes that are made intermittently, seems like a smart (but existing) idea.

ralphm, btw I've considered that xep-385 issue I raised with backwards compatibility. Solution is quite simple: all links in <body> can be hidden with a special "hide" reference. Problem is, 385 is based upon 372 which is deferred and looks half baked

Yeah, and XEP-0385 doesn't even reference XEP-0372 (no pun intended).

I agree XEP-0372 needs quite some love.

I think the people involved have been focussing more on MIX, discussions on which caused References to be specified during last year's Summit.

References is a nice idea, but it lacks any description of how to practically implement it

"We welcome your PR"

As I said, the document needs work. I might pick it up.

Converse has the mention bit, which I like.

it's used with @<tabcomplete> (or when clicking on a user name)

Does it mark that up some way?

sure ralphm

https://xmpp.igniterealtime.org:7483/httpfileupload/bd8842ef-c82c-4f96-b237-5d1fd9bbb328/bBjZEL-3SNmF8Wyavhkcgg.jpg

In protocol, I mean

but the mention bit is probably the most straightforward

Other than what's described in the XEP you mean, ralphm ?

The message above: <body>Other than what's described in the XEP you mean, ralphm ?</body><active xmlns="http://jabber.org/protocol/chatstates"/><reference xmlns="urn:xmpp:reference:0" begin="49" end="55" type="mention"/>

Oh, you are already using References?

Nice

yes, Converse does.

It doesn't contain a reference to who is mentioned?!

That seems to be true

probably because it's used for markup only.

I'll raise an issue

Because the markup is the easy part. How to actually reference other entities is the hard part.

https://github.com/conversejs/converse.js/issues/1495

Guus: you can get the xml colored by using ```xml as the block prefix 😁

you underestimate my level of lazyness, Ge0rG .

but, there

it made me add newlines too

Guus: oh, sorry! 😉

One obvious thing would be an xmpp URI to the real JID

Unless in an anonymous MUC

There are no anonymous MUCs. But you can obviously reference the full JID of the occupant

Except this is prone to the same problems we can't solve with LMC already, where occupant identity may change in between

which for references might be less of a problem, as it's a reference that's valid only at the time the reference was made.

(not that that buys you anything)

The interesting thing is what to do with such an occupant reference.

And the really really interesting question is how to reference other messages.

Right unique IDs for messages, and some way to, probably, embed that in URIs

With MAM, we could use the archive ID. But that only works for rooms, not for private chats...

And obviously we need a URI scheme for messages

All the important things that are missing from the XEP

I'm not sure if the definition of the construction of URIs to point to individual messages should be in this spec. The topic of message IDs in itself is already complicated.

But, again, I agree that the References spec is in its early stages.

M-M-M-M-M-M-M-M-M-M-M-M-Monstermeet!

</unreal-tournament-voice>

Oh the memories

0. Welcome + Agenda

Who? What?

me

what's on trello

(maybe MattJ, Seve mentioned he'd try to make it but was unsure, nyco apologized)

waiting for number 3

Which is kind of why I mentioned candidates by name.

I guessed

Hey

\o/

1. Minute taker

Who can do this? Someone from the floor?

hargh. I just got called by daycare - my kid has a fever, need to pick her up in a few moments.

ok, no worries

I can stick around for one or two short topics, but 10 minutes max

2. Server outage

I guess I'll start with this one then

Guus asked for a post-mortem on the outage over the weekend.

There's been some back and forth about this on the iteam and board mailinglists

I'm grateful for everyone that pitched in to help resolve the issue.

A few questions come to mind. * Should we worry about this? * Is the Infrastructure Team happy with the current setup, or would it like to consider things along the lines Peter sketched? * Do we have sufficient monitoring in case things go awry? * What can Board to help out the Infrastructure Team?

Guus: indeed

Most of that depends on how important we deem the continuous availability of services to be.

Sure

if we can live with unexpected outages, then I don't see a need (maybe a desire, but no need) to change things.

I think generally having our website be available at all times is a need, we lost GSoC because of it one year

It depends. We once missed out on GSoC because of an outage, but other than that it is mostly inconvenient.

If this situation had been worse, or similarly timed, it could have had the same effect

Right

the GSoC issue was horrible, but also a very unlikely combination of things

Well, that was the wiki, rather than the website.

Kev, same server, no?

The website is trivially mirrorable.

The wiki would be more work to make resilient.

Kev: sure, but unfortunately Guus didn't get an answer on what was affected, yet, so we're shooting in the dark a bit.

as far as "website is always available" you could just slap cloudflare in front of it :'(

Everything except mail, pretty much.

Kev: right

So what can we do to help?

moparisthebest I think everyone can think of possible improvements. Let's first see if improvements (which take effort to realise) are needed.

Help depends what we want out of it vs. the effort.

The 'gsoc outage' was a case of us doing something daft.

Namely?

This one, as far as we've seen, was an unexplained server wibble.

Kev: sure, but it could be that you have already made plans, but lack time, or money, or skills.

Oh, you mean the backups, not bringing the server down

Running unchecked code on a production machine.

xmpp.net brought it down during the gsoc outage. But that's another story.

We did, a little while ago, have an indication that (previous) Board was going to get sponsorship from someone in terms of sysadmin to help maintain all our systems, but I think that fell through.

iirc the xmpp.net server used to be separate (?)

I agree that this is part of a broader issue with iteam currently

No, the observatory was on the same server as the wiki, and brought the server down by DoS, essentially.

e.g. we used to have a list of XSF infrastructure. That list still exists, but is years out of date.

apart from trying to improve things: what is the state of our hardware? Is it in need of replacement?

I don't think we have a central record of who has (or should have) access to what systems

I think our most critical bit of infrastructure is the website.

or disaster recovery plans

If atlas went down, I'm not sure where we'd begin with replacing it

If we're willing to throw a little money at it, or othersponsorship, or whatever, we could easily docker swarm that so it's resilient.

But I'm more or less out of action today, ill, so I'd be better having that discussion another time.

Why docker swarm when there are numerous easier ways to host a static website?

Or those.

Kev: that's ok. Do you want to schedule a time for a next chat on this topic?

Which brings us to Peter's questions

I'd be happy to talk to Edwin tonight (around our rehearsal) to see what we could do.

One thing that I'd like to discuss (later)

if we do deem at least part of the infrastructure critical, then I'd prefer if we could find a way to not depend on the availability of volunteers to do disaster recovery.

Shall I take this up this (broad) topic together with iteam?

Sure.

(instead of all of Board)

ok

I do need to leave now

Thanks Guus

afk

thanks!

In that case, with Seve half around, I'm not sure if that counts as quorum.

I'm fine with ending

2. AOB

There's one thing I'd like to mention.

There was some heated debate yesterday about a bunch of topics, including the usefulness of the XSF itself. I'm not sure if it helps going into this right now fully.

But I learned that zinid is no longer persuing https://xmpp.org/extensions/inbox/eax-car.html with the XSF.

And chose another approach.

I think that means it is no longer going to be resubmitted, so the Editors are aware of this.

That's it for me.

Same here

2. Date of Next

+1W

(this is item 3)

4. Close

Thanks all!

Thanks ralphm

Hey guys, sorry, the train was going through a tunnel and lost connection

Long tunnel

ralphm: I didn't press enter and I realized now :(

> Long tunnel Or slow train.

anyway what I was saying earlier, I'm not the biggest fan of this approach, but the lowest effort thing that can be done to keep the website available is to put it behind cloudflare, it's almost just clicking a button

could also just host it on github pages and let them worry about it, still using xmpp.org domain

The main issue with github pages is https. Unless LE has changed things like that.

HTTPS works with Github pages, if you satisfy some requirements around DNS

which is to use a CNAME, or an A/AAAA specifically, I forget which - it's in their docs

and depends on whether you want them to serve the whole domain or a specific subdomain, and weirdly whether that subdomain is called 'www' or not

Can't CNAME xmpp.org

yea I know github pages can do https, haven't looked at the details

-> iteam room

https://coggle.it/diagram/XIpAaxc5Aoy4z505/t/-

Drew a simple diagram how xmpp standards depend on each other

Didn't list all xeps, just those mentioned in compliance suites , and some we're currently interested in

Service isn't best, does not allow to paint arrows the way I like. I'd prefer arrows to dependencies being colored according to parent status.

But still, picture doesn't look pretty. Probably, if we list only "strong" dependencies, it'll look more clear.

You may want to try doing this with graphviz/dot.

Maybe there's already a script in the xeps repo

Well I was looking for a fancy tool for my managers and to test started drawing the first thing that came to mind.

Got carried away a big 😂

Hehe

But there are obvious formal problems, like 0280 carbons dependency on deferred 0296

Andrew Nenakhov, why is that a (formal) problem?

Because when you build a set of rules, subsequent rules must be based on valid predecessors.

What makes xep296 invalid?

It's not invalid, it's deferred

It is not like that it is marked as such or obsolte

Deferred kinda means 'not ok'

Andrew Nenakhov, I don't think that this is the case

It just means nobody worked on it in a while

Huh

It's not even listed by default when you go to extensions page.

Is that meant to be XEP-0297?

Ie Stanza Forwarding

Carbons uses that, but it's not listed in the dependencies

Andrew Nenakhov, possibly, but that doesn't change the meaning of "deferred"

Zash, yeah, looks like a off-by-one

flow, English is not my native language, and vocabulary gives translation to Russian that is roughly similar to rejected.

Andrew Nenakhov, think of "postponed"

Oxford defined it as "Put off (an action or event) to a later time; postpone."

Postponed, like, indefinitely )

Possibly, but that only means that it was not explicitly marked as obsolete

Anyway I don't think it's ok when subsequent XEPs have deferred dependencies. Also very bad marketing.

This all does not look clear at all.

I understand that there are "strong" and "weak" dependencies of course

Maybe if we get rid of weak not too important links, graph would be easier to digest

I think we had this discussion already, about not being able to advance XEPs that depend on Experimental or Deferred. And then https://xmpp.org/extensions/xep-0297.html was made Draft

I think it is ok, but I also believe that the terms of XEP states could be improved. Some people wonder why 'Draft' is an XEP which got past experimental

Yes, Draft does not look like very advanced stage of standard lifecycle from the outside

https://github.com/xsf/xeps/commit/7d4f99b5a66187aacd289cb210d6636f3b1185cd

Sure looks like a typo and it was meant to be 297

Lol )

I thought it was weird, yes )

Andrew Nenakhov: on the other hand, SMTP, currently at RFC 5321, is Draft, too.

thankfully we use numbers to reference the XEPs…

There are only very few documents that IETF has beyond that.

ralphm, surely just because someone else (IETF) does it the same way isn't a good argument?

if you look at it that way, we only have a handfull of internet standards

ralphm, true. But matrix's documentation is nearing 1.0.0! See the difference? )

The main difference is that the IETF gives documents a new RFC number when they advance

the rest are just documents waiting for comments :)

Zash: well, there's a level beyond Draft and that's Internet Standard.

Isn't it Internet-Draft (number of iterations) -> Proposed Standard (given RFC number) -> Internet-Draft (thing-bis) (iterations) -> Internet Standard (new RFC number)

Where we do ProtoXEP -> Experimental (iterations) -> Draft -> Final

And the number is issued earlier

Zash: it's about the label, not that it is a new document

ralphm: Hm?

Zash, nearly, as far as I understand there is an additional step after RFC number assignment, which makes it an Internet Standard

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

Andrew Nenakhov: hah, we've had XMPP 1.0 since 2004.

Zash, ahh wait, you are right

there appears to be a new number requirement

Zash: that Andrew was talking more about the 'weight' of the status of a spec. Experimental, Draft, Final, etc.

For marketing purposes

ralphm: So it boils down to the word "draft" not being as obvious on Draft Standard RFCs?

since words mean nothing, or rather, different things to different people anyway, maybe we should just create made up ones for different statuses :D

Wait

3920 and 6120 are both "Proposed Standard"?

Zash: depending on how you look at it, IRC is either Experimental or Infirmational

So, it seems no one really cares.

The way I looked at it, the IRC RFC was a dissapointment. Writing a server seemed to require more trial and error and squinting at packet captures to implement than XMPP.

My point it is 25 years old and definitely a standard.

ralphm: Sure. People also consider expired, independently submitted internet-drafts to be IETF Approved™