XMPP Council - 2021-08-11

Hi

I've heard it's that special date and time again, but I'm still on the run

My gosh, is this the time?

Do we have a jonas’?

Hiya.

Dun dun duuun

1) Roll Call

sorry

thanks Zash for poking me

Here. Full house?

I was sunken deeply in the horrifying lecture which is https://counterexamples.org/

either way, welcome everyone

2) Agenda Bashing

this time, it was not a late agenda, which is good and surprising given the chaotic day I had yesterday. I don't even remember much of writing it :)

please complain about anything which might be missing inline and asap

3) Editor's Update

Pubsub Caching Hints have been accepted as New as per council vote

also, the moved 2.0 protoxep has been merged into '283 and authorship has been transferred to MattJ as discussed

4) Items for Voting

None, as far as I know.

5) Pending votes

- Georg on ProtoXEP https://xmpp.org/extensions/inbox/disco-feature-attachment.html

I note that there has been some discussion on list about this

I think Stephen makes some valid points

but there was also more discussion in xsf@ and my personal take away is that the proposal isn't really sensible after all

"the proposal" = the protoXEP or what was posted to the list?

both!

fwiw i never "liked" the XEP. but i think it's speced out well enough to deserve being an experimental xep

I thought it seemed quite sensible for RSM (and needed), and I was willing to see how the Generic version played out.

just be careful with implementing it and more careful with referencing it from other xeps

-1, my rationale being the following, but I can be persuaded: - Any disco#info feature needs to be backed by some kind of implementation text - Even though for some combination of features the implementation may be obvious, it should still be written down somewhere, because obvious doesn't really work - If there is text backing the implementation of a combination of two features, that is the obvious place to declare a disco#info feature string - If there is a place where a disco#info string is written down which needs to be read by implementors anyway, there is no benefit from having a way to construct such a string; an opaque string match is required in the implementation anyway.

and to bring this to the point which IMO makes this -1-worthy: it misleads implementations and specification authors to think that they can just slap together two feature strings and it will be immediately clear what is supposed to happen there.

i (mostly?) agree with your points. to me this doesn’t necessarily warent a -1

I'm with jonas’, plus introducing @ as a special character in an otherwise opaque identifier is kinda evil

but i respect your choice to veto

daniel, I may be over the line here, however, I think this may be actievly harmful

at the same time, I acknowledge that we need to solve the issue that an entity declaring RSM and an entity declaring e.g. MAM or PubSub or '0030 is not clear about how and where RSM is supported

I think the discussion in xsf@ about this has been guiding in the sense that it became clear in which documents those specific cases need to be addressed (if at all -- I think MAM clearly references RSM already and hard-depends on it, so MAM feature implies RSM anyway)

Yeah, it creates a precedent for a really bad practice. In the end, somebody will add a matrix of all possible combinations of main feature × supporting feature

Well, certainly this could be solved more immediately by a set of RSM+Pubsub (etc) features.

So the root problem is signaling optional dependencies?

fair. (it once again boils down to what experimental means)

Zash, I think so

Zash, because for mandatory dependencies it doesn't matter.

in the end, RSM should never have had a feature string :)

Or by requiring MAM to support RSM without a distinct disco feature

Yeah, you don't need to advertise something that is implied by e.g. the MAM feature.

I'm going with -0, because I may be wrong about this and Experimental may still be a place for it. I'll post my concerns on the list so that others can weigh in.

Ge0rG, your vote please.

Maybe this should be turned into an Informational XEP, as I think was mentioned in xsf@

Zash, even that is not useful in my opinion

Zash: I don't like that idea

Zash, I don't think that really solves anything.

I am finding myself swayed by your arguments,here, jonas’ + Ge0rG.

jonas’: -0 from me as well, because I fully agree that we need explicit wording for optional dependencies, where we easily can define their own feature string ✏

General guidelines for advertising support for optional use of other XEPs, whether by "X@Y" or "Y#x"

Zash: maybe that's something where an editor can easily change the strings during submission?

I think introducing some kind of "syntax" is useful for the humans in the XMPP stack.

even if no code can make automated decisions based on the syntax

I think this is a problem that needs addressing for RSM, for sure. But the generic nature of this approach is a bit of a risk.

okay

proposal

Somebody would have to go through all of our existing XEPs to check for prior art

it seems that this discussion has become a bit complicated. shall we prolong our voting period by another week?

I am currently typing a long email in response to the thread to involve the author in this

SO I'm wondering about switching to veto, with a resolution of removing the generic nature of this - that is, make it explicitly about RSM and making each feature explicitly defined, and then I think that addresses all our concerns "for now"?

Also there is the mess called 0045

Dave Cridland, that's kind of what I'm going to propose on-list anyway, so go for it IMO

Ge0rG, what's got '45 to do with this?

Combinations of things?

I'll change to veto then. I think that leaves open a generic solution if one seems needed.

ACK thx

jonas’: inconsistently named optional features

Ge0rG, doesn't matter, opaque strings ;)

but yeah

okay, last call for votes on this protoxep because we all did a lot of switcheroo here

daniel, Zash, any changes?

Good arguments, so -0 I think?

Or hold until the list discussion comes to a conclusion

yeah. it doesn’t matter; but i'm fine with rejecting it after hearing the arguments

it=my vote

okay

thanks all

I'm going to write an extensive email into the thread to explain all this to the author and also to singpolyma

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1w wfm

+1W WFM

7) AOB

anything?

Not from me.

nobody else is moving so

8) Ite Meeting Est

thanks everyone

I'm going to write the email in the thread and compile minutes :)

thanks jonas’

Thanks jonas’ !

mail sent in that thread, minutes sent, thanks everyone.

Bag? You bought them? I thought your growing them in the woods.

mdosch, and how do you collect them if not in a bag?

Hmm, true. ✏

FWIW, I think veto was the right call, and Jonas has roughly repeated the points I tried to make in xsf@ the other day, more elloquently

(Jonas than me)