Ge0rGI've heard it's that special date and time again, but I'm still on the run
ZashMy gosh, is this the time?
danielDo we have a jonas’?
ZashDun dun duuun
jonas’1) Roll Call
jonas’thanks Zash for poking me
ZashHere. Full house?
jonas’I was sunken deeply in the horrifying lecture which is https://counterexamples.org/
jonas’either way, welcome everyone
jonas’2) Agenda Bashing
jonas’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 :)
jonas’please complain about anything which might be missing inline and asap
jonas’3) Editor's Update
jonas’Pubsub Caching Hints have been accepted as New as per council vote
jonas’also, the moved 2.0 protoxep has been merged into '283 and authorship has been transferred to MattJ as discussed
jonas’4) Items for Voting
jonas’None, as far as I know.
jonas’5) Pending votes
jonas’- Georg on ProtoXEP
jonas’I note that there has been some discussion on list about this
jonas’I think Stephen makes some valid points
jonas’but there was also more discussion in xsf@ and my personal take away is that the proposal isn't really sensible after all
Zash"the proposal" = the protoXEP or what was posted to the list?
danielfwiw i never "liked" the XEP. but i think it's speced out well enough to deserve being an experimental xep
Dave CridlandI thought it seemed quite sensible for RSM (and needed), and I was willing to see how the Generic version played out.
danieljust be careful with implementing it and more careful with referencing it from other xeps
jonas’-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.
jonas’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.
danieli (mostly?) agree with your points. to me this doesn’t necessarily warent a -1
Ge0rGI'm with jonas’, plus introducing @ as a special character in an otherwise opaque identifier is kinda evil
danielbut i respect your choice to veto
jonas’daniel, I may be over the line here, however, I think this may be actievly harmful
jonas’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
jonas’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)
Ge0rGYeah, 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
Dave CridlandWell, certainly this could be solved more immediately by a set of RSM+Pubsub (etc) features.
ZashSo the root problem is signaling optional dependencies?
danielfair. (it once again boils down to what experimental means)
jonas’Zash, I think so
jonas’Zash, because for mandatory dependencies it doesn't matter.
jonas’in the end, RSM should never have had a feature string :)
Ge0rGOr by requiring MAM to support RSM without a distinct disco feature
ZashYeah, you don't need to advertise something that is implied by e.g. the MAM feature.
jonas’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.
jonas’Ge0rG, your vote please.
ZashMaybe this should be turned into an Informational XEP, as I think was mentioned in xsf@
jonas’Zash, even that is not useful in my opinion
Ge0rGZash: I don't like that idea
Dave CridlandZash, I don't think that really solves anything.
Dave CridlandI am finding myself swayed by your arguments,here, jonas’ + Ge0rG.
Ge0rGjonas’: -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 during✎
Ge0rGjonas’: -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 ✏
ZashGeneral guidelines for advertising support for optional use of other XEPs, whether by "X@Y" or "Y#x"
Ge0rGZash: maybe that's something where an editor can easily change the strings during submission?
jonas’I think introducing some kind of "syntax" is useful for the humans in the XMPP stack.
jonas’even if no code can make automated decisions based on the syntax
Dave CridlandI 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.
Ge0rGSomebody would have to go through all of our existing XEPs to check for prior art
jonas’it seems that this discussion has become a bit complicated. shall we prolong our voting period by another week?
jonas’I am currently typing a long email in response to the thread to involve the author in this
Dave CridlandSO 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"?
Ge0rGAlso there is the mess called 0045
jonas’Dave Cridland, that's kind of what I'm going to propose on-list anyway, so go for it IMO
jonas’Ge0rG, what's got '45 to do with this?
ZashCombinations of things?
Dave CridlandI'll change to veto then. I think that leaves open a generic solution if one seems needed.
Ge0rGjonas’: inconsistently named optional features
jonas’Ge0rG, doesn't matter, opaque strings ;)
jonas’okay, last call for votes on this protoxep because we all did a lot of switcheroo here
jonas’daniel, Zash, any changes?
ZashGood arguments, so -0 I think?
ZashOr hold until the list discussion comes to a conclusion
danielyeah. it doesn’t matter; but i'm fine with rejecting it after hearing the arguments
jonas’I'm going to write an extensive email into the thread to explain all this to the author and also to singpolyma
jonas’6) Date of Next
Dave Cridland+1w wfm
Dave CridlandNot from me.
jonas’nobody else is moving so
jonas’8) Ite Meeting Est
jonas’I'm going to write the email in the thread and compile minutes :)
Dave CridlandThanks jonas’ !
jonas’mail sent in that thread, minutes sent, thanks everyone.
jonas’dives back into "Counterexamples"
Zashdives into a bag of potatoes
mdoschBag? You bought them? I thought your growing them in the woods.
jonas’mdosch, and how do you collect them if not in a bag?