I don't think I'll make it, but I'm +1 on the CS2021 XEP
Ge0rG
And on-list for the other items
dwdhas joined
jonas’
1) Roll Call
Zash
Here
daniel
Hi
dwd
Hello
jonas’
Hi everyone
jonas’
Ge0rG sent apologies, so moving on
jonas’
2) Agenda Bashing
jonas’
Assuming nothing
jonas’
3) Editor’s Update
jonas’
- New ProtoXEP: Compliance Suites 2021
- LC for XEP-0411 extended until 2020-10-14 after the original extension got lost in the void.
jonas’
yeah, no idea what went wrong with that email, this one seems to have passed through
jonas’
4) Items for Voting
jonas’
(sorry for being terse today)
jonas’
4a) PR#986: XEP-0277: pubsub#type MUST be set in bare PubSub
URL: https://github.com/xsf/xeps/pull/986
jonas’
I am on-list, I didn’t have the chance to read into what pubsub#type even is :)
Zash
I saw daniel comment that this is Experimental and thus not our thing to approve
daniel
what Zash said what I said
Zash
(actually Deferred, but still)
jonas’
right, so this is not an item for vote, but an AOB
jonas’
since pep. explicitly asked for guidance
jonas’
let’s move it there and discuss it then, thanks for the hint
Zash
ack
jonas’
4b) PR#988: XEP-0060: Add integer-or-max datatype to use with Data Forms Validation
URL: https://github.com/xsf/xeps/pull/988
Note: The idea behind is to formally define the behaviour of the max-items field in PubSub.
pep.
!
daniel
As I said on the list; I'd be willing to +1 this unless someone really wants to put this somewhere 60-agnostic
daniel
but i'm not even fully sure that 122 is a better place
Zash
Assuming the schema magic is sane, +1.
It would be nice if the registry was working ;)
so the only way to make it it agnostic is a brand new XEP?
jonas’
Zash, seems like overkill if I ever saw one
daniel
which is overkill. so 60 it is?
pep.
I did think about making it a new XEP just to define the type, and then edit 0060 to use it :/
jonas’
I’m on-list nevertheless, I want to understand if that schema stuff is right first
pep.
Not sure what's best
jonas’
I got the gut feeling that it isn’t
Zash
jonas’: oh glob
daniel
anyway have my official +1
pep.
jonas’, got it from https://www.w3.org/TR/xmlschema-2/#union-datatypes
daniel
and then have someelse block it if they feel like it
jonas’
I would’ve expected dwd to have a strong opinion here (subtle ping)
dwd
pep., Your thought is that it needs an edit to '60 either way? I think that's probably right, so we might as well have the registration there too.
dwd
On the schema, it looks right to me.
pep.
yeah 0060 needs editing in any case I'd say. Because I need to give meaning to the type
pep.
For each field using it
Zash
If you want it Generic, shouldn't it have a 'min' enum too?
dwd
pep., Yes, seems right.
dwd
Zash, Is min not equivalent to zero in any case?
Zash
dwd: only if it's unsigned
pep.
Zash, not against adding it, but yeah I'd say it's likely to be 0
pep.
right..
Zash
Is it?
dwd
Oh.
pep.
'integer' is
pep.
signed.
pep.
Sorry
dwd
Is there an unsigned integer type?
daniel
I can’t think of a use case for 'min' and I rather not add something unless we have an explicit use
pep.
and infinite..
pep.
dwd, we can make one
pep.
But I'd think there is one already
dwd
Ugh.
Zash
And the semantics here is that 'max' is always whatever the acutal max is, even if you reconfigure it in the thing defining it?
pep.
daniel, if I split the thing into its own XEP I guess it might make sense
daniel
Zash yes
dwd
This feels like the sort of grinding down in detail that would be best done on the list. But anyway, I'm +1, but if you find improvements that's also good.
daniel
which is actually what I like about that
jonas’
Zash, want to cast a vote?
Zash
+1
dwd
I'm also fine with this not needing a "min". If we want to expand later we can by having an integer-or-min-or-max or something.
jonas’
let’s move on then
jonas’
4c) Proposed XMPP Extension: Compliance Suites 2021
URL: https://xmpp.org/extensions/inbox/cs-2021.html
Abstract: ... you know it ...
jonas’
+1
daniel
+1
dwd
(I apologise for not having the strong opinions jonas’ hoped for).
dwd
+1
Zash
+1
jonas’
swift
jonas’
5) Pending Votes
jonas’
a few on #983 from last week
jonas’
me including, but then again, two people vetoed already
jonas’
any need for discussion about that one?
jonas’
oh, it’s the URI one
adityaborikarhas joined
jonas’
the author agreed in the meantime that URI encoding should be used and we’re done
jonas’
6) Date of Next
dwd
You effectively pre-veto'd it.
jonas’
+1w wfm
daniel
let me check
dwd
+1 to +1w wfm.
jonas’
dwd, and by that you can see how awake I am today :D
Zash
+1w wfm
pprrkshas left
daniel
+1w wfm
jonas’
neat
jonas’
7) AOB
pprrkshas joined
neoxhas left
jonas’
let’s insert the PR#986
jonas’
-> https://github.com/xsf/xeps/pull/986
jonas’
my stance doesn’t change (I need to read into this before I can provide guidance), but maybe someone else can
Zash
Opinion: This is good.
daniel
as I already said in the comments. _seems_ good to me. but i'm not an expert on microblogging. maybe someone else out there is using this on a different node for reasons?
daniel
it should really be left to the authors imho
jonas’
note that pubsub#type is *not* the node ID
jonas’
most of the authors I haven’t seen much around here lately
pep.
Yeah that's on purpose. The node ID is generally set to a UUID I think in Movim and/or Sàt
dwd
I think it's maybe a SHOULD and not a MUST. But I'd be curious as to what the authors say, as well as the Movim guys who (I think) use this heavily.
pep.
When not on PEP
Zash
edhelas seemed to approve: https://logs.xmpp.org/xsf/2020-09-30?p=h#2020-09-30-030be57f8039269d
Zash
and pep. said goffi did too
dwd
Oh, that's good then.
daniel
right. yes. just shows how not of an expert on microblogging I am
daniel
but if the two only implementors agree…
Zash
The #type field isn't super-well-defined tho
dwd
But experimental, so if those who want this want it this way, that's fine by me.
jonas’
what is the benefit of using the pubsub#type?
pep.
Zash, true
jonas’
is that something you can filter on when finding pubsub nodes?
dwd
jonas’, Discovery I guess.
pep.
The only thing that's normative about pubsub#type is "payload type"
pep.
The rest is somewhere in an example
Zash
AIUI it's meant to be an URI / namespace representing the payload type
pep.
jonas’, I don't think so, it's just that there might be multiple nodes using microblog on the same pubsub component
pep.
So you can't set them all to the same value
jonas’
… to the same node ID
jonas’
makes sense
jonas’
but how does it help any entity then?
Zash
Theoretical filtering abilitity?
jonas’
right
jonas’
and maybe for showing stuff in a pubsub node directory or something
Zash
jonas’: microblog support for search.jabber.network !
jonas’
of course :)
daniel
in that case a SHOULD should be fine?
dwd
If we ever did disco#search, it'd be useful.
Wojtekhas joined
jonas’
yeah, so, I have little idea about microblogging. we’ll have to ping the authors anyway, but if the implementors agree, that’s already a good thing
Zash
Yeah, RFC 2119 expert comment on the MUST plz
jonas’
daniel, any concrete reason why a MUST would not be desirable?
pep.
daniel, I feel that if it's a SHOULD in microblog, it makes this change moot. I said to Zash earlier "the XEP becomes unusable without the MUST the second another spec uses pubsub + atom"
dwd
Well, is it an absolute requirement for interoperability?
pep.
(because no, microblog is not just pubsub+atom)
jonas’
how about we delegate that MUST/SHOULD debate to the authors?
pep.
hah
daniel
jonas’, i got the impression that it is a discovery/search thing? so if i don’t need it to be found
dwd
I mean, my gut feeling is SHOULD, but I'm not the expert here, and if those who are think if this is missing there's concrete interop harm then MUST it is.
daniel
but i'm really what ever on that
Zash
jonas’: sounds reasonable
dwd
daniel, I'm thinking if it's on the well-known node ID then it probably doesn't add value.
daniel
dwd, yes
jonas’
then I’d like to move on to 7b
dwd
But I susp[ect this is bikeshed.
jonas’
dwd, daniel, note that the text says that it’s not needed if on the well-known node ID
jonas’
only if it isn’t
jonas’
either way
jonas’
pinging authors, moving on
dwd
I'm right then in my previous assertion. :-)
daniel
there might be other well knowns
jonas’
7b) Message Styling
It was not advanced and the author disagrees with Council. What to do next?
nice, pipermail doesn’t let you click next on that one
jonas’
https://mail.jabber.org/pipermail/standards/2020-June/037496.html this may do
dwd
So if Sam, as author, is in the rough here, then he gets to say "I told you so", and not much else. But if there's no clear(ish) consensus, rough or otherwise, from the group on the way forward then that's not much help.
Zash
Because it goes into June
daniel
right. if I recall that thread correctly there wasn’t a clear community consensus
daniel
some (rightfully) hate the xep a lot for not being xhtml-im
daniel
but it also doesn’t try to be
jonas’
quick question: can we extend by +10min to bring this to a more useful ending?
daniel
i personally probably would not vote to reject it
daniel
yes
Zash
shure
Kev
(Interjecting) ISTR there were some quite sensible suggestions made to make this a better imperfect solution to an impossible problem, which should probably have serious thought. Around opt-ins and the like.
Kevreturns to his corner
jonas’hands Kev some cookies
daniel
right. those changes (if we want them to) could be made by simply taking the XEP over instead of rejecting it
pep.
I also wasn't ready for this :P
jonas’
pep., nobody ever is for a re-iteration of message {styling,theming,formatting}
pep.
Iirc even the opt-in/out mechanisms wouldn't really help
daniel
not making an argument for or against those signaling/opt-in/opt-out changes
jonas’
daniel, yes
Kev
pep.: IIRC, the mechanisms couldn't make this a perfect solution to the impossible problem.
Kev
But did solve some of the issues.
Kev
But I don't have this swapped in at the moment, sadly.
jonas’
nobody has
eta
one thing not addressed is "how do I have both a styled version and a fallback without adding ugly * everywhere"
eta
for example, spectrum2-discord currently makes user @mentions bold with xhtml-im
jonas’
eta, this is not about completely re-doing Styling
eta
right
jonas’
we have about one month left to properly bring this to a close.
eta
I mean as an informational document '393 is pretty good
Kev
Oh, that's an interesting thought.
jonas’
the best way forward I can come up with is if everyone of us (council) wades through that thread and tries to extract the community consensus and then we act on the mean of that
jonas’
the Informational track has been proposed before for '393
pep.
eta, I want to disagree :p
Kev
Sorry, I'm forgetting things in my old age.
jonas’
I do not recall who strongly opposed that though; might’ve been sam, might’ve been me.
jonas’
(which really says something)
pep.
I'd rather have that somewhere hidden / locked-away never to be seen again
Kev
I think I've aged about a decade in the last 6 months (I suspect I'm not alone)
daniel
I think someone said we can’t change tracks
eta
I mean it is a hack
jonas’hands more 🍪 to Kev
eta
but it's a relatively okay one
daniel
but i'd be fine with keeping it informational and roughly as is
eta
like vcard-temp
jonas’
daniel, we can do everything, if we ask board for a '1 override (and they grant it)
Zash
eta: oh no u didn't!!1
dwd
I honestly don't know that there's community consensus, even rough, to do anything at all. Including doing nothing.
daniel
i mean we can try to go through the thread again. but something something vocal miniority and haters gonna hate and stuff
daniel
so at some point we probably just have to decide something
Kev
Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think.
daniel
or let the next council deal with it :-)
jonas’
OK, so, I’ll set up a bunch of votes for next week:
1. Should we find a way to move '393 to Informational and keep it there?
2. If the previous vote should fail, should we take ownership from Sam and rewrite '393 with a mandatory and explicit opt-in?
3. If the previous vote should fail, should we accept '393 as-is?
4. If the previous vote should fail, should we reject '393 as is or accept it as Draft?
daniel
> Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think.
+1
dwd
I don';t think there was consensus for explicit opt-in, actually.
jonas’
can we agree on that list? and also on everyone swapping this in so that we can bring it to a close?
Zash
Gonna need to stock up on 🍪
daniel
yes
pep.
dwd, there wasn't indeed :/
dwd
Also popcorn.
jonas’
I’m not sure if the positive response is to popcorn or my list
daniel
my 'yes' was regarding your list
dwd
I *think* there might be (very) rough consensus to have it with an explicit opt-out, and publishing it. Though whether as Informational or Standards Track, I don't know.
jonas’
I put the votes on next week’s agenda
Kev
(Don't want to derail the meeting, so ignore this for the moment, but I think there is a strong argument for having a this-is-marked-up, which is not necessarily used for opt-in, because it allows you to strip the formatting, knowing that's what it is, ending up with something more $OTHER_MESSENGER (and more useful, I believe) - maybe not a hill to die on, but I think there isn't a reason it would be bad to tell people it's marked up)
jonas’
and now I’d like to step away from this, and I also think that we can’t find a solution right now and here
jonas’
any other AOB?
pep.
Kev, yes, and an argument for opt-in
dwd
Kev, https://mail.jabber.org/pipermail/standards/2020-June/037506.html I found reasonably compelling.
Kev
dwd: I *think* he's looking at using an opt-in, there, which has pros and cons, as opposed to simply an announcement that something is marked up?
jonas’
I’m taking this as a no
jonas’
8) Ite Meeting Est
jonas’
thanks everyone
daniel
Thank you jonas’
pep.
There were questions in #988, but I guess I'll poke people on xsf@ later on
Kev
Ah, no, he does address the third state towards the end.
pep.
Re datatype prefix
Kev
dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point for clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt.✎
Kev
dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point more clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt. ✏
pep.
I guess I'm less annoyed about the XEP but more about its adoption. Devs thinking this is actually a good solution
dwd
Kev, A point you indeed raised in the thread.
Kev
Oh, did I? How refreshing for me to be consistent :)
jonas’
move that to xsf@ maybe?
daniel
pep.: isn't the adoption one client
pep.
yours?
daniel
And one client that copy pasted the code
dwd
Kev, I'm basically finding myself on the same rollercoaster I suspect I was on when I first read the thread.
dwd
Kev, And also, June feels like years ago.
Kev
What the ... that was THIS YEAR?
daniel
Which is actually slightly frustrating because Dino and Gajim render it slightly different
daniel
But not different enough
jonas’
Time flies like an arrow (fruit flies like a banana, though).
daniel
(unless either of them 'fixed' this recently)
dwd
daniel, IIRC, Psi implemented (basically) this about a decade ago.
daniel
With emphasis on _basically_
pep.
You mean yet another variant?
eta
XHTML-IM wasn't that bad
etaducks
Kev
I think Psi was the first XMPP client to do this.
Zash
Gajim also had something like this since time immemorial
dwd
pep., Part of Sam's intent here was to unify the variants, in fairness.
Kev
eta: That's the upsetting thing, XHTML-IM *wasn't* that bad.
daniel
The idea is the same. But the exact implementations vary
daniel
Which can be annoying in certain cornor cases
dwd
eta, The problem with XHTML-IM was that virtually every implementation had security flaws.
Kev
https://mail.jabber.org/pipermail/standards/2020-June/037514.html
I think the point I made there still stands, basically, although I had no idea it was only two months ago I raised it.✎
Kev
https://mail.jabber.org/pipermail/standards/2020-June/037514.html
I think the point I made there still stands, basically, although I had no idea it was only three months ago I raised it. ✏
pep.
dwd, I think my bitterness about 393 is mostly due to the fact that this came up right after XHTML-IM was "killed", and proposed as some kind of replacement that it isn't
daniel
I don't recall the time line being in that order
Zash
And the irony in literally everything else (outside XMPP) uses something like XHTML-IM, but embedded in JSON
pep.
yeah
eta
yeah exactly
Kev
Zash: Ah, although with one major difference, I think.
eta
dwd: this is only because people just shoved the XHTML into a webview or something stupid
Kev
Zash: Not duplicating the body (maybe that's only a concern for us, but it's a major concern when you have two different representations that could have completely different content, shown to different users)
eta
like if you tree walk the XHTML you don't have this problem
Zash
Kev: Matrix duplicates the body.
Kev
eta: I think it's more than that. You can be trying quite hard to not be stupid, and still fall foul of things.
Zash
And also tripples it if you make a correction iirc.
daniel
I think the fault here is that xhtml-im was too broad and invited doing exactly that (putting it in a web view)
pep.
daniel, too broad? there's a nice whitelist there
daniel
Or more limited scope (same feature set as 393) could have prevented that
eta
Kev: yeah, okay, stupid is an unnecessarily caustic word :)
dwd
eta, Yes, but while we know what people are meant to do, and even designed XHTML-IM to support same, nobody did it that way at first.
daniel
pep.: it has css
Zash
daniel: tbf, the css also has a whitelist
pep.
CSS1 yeah
daniel
But I'm not gonna write an css parser
eta
but something that is actually XML based instead would be bettee
eta
r*
jonas’
I strongly suggest to move this to xsf@
eta
like even if it's <bold>whatever</>
daniel
When the alternative of putting it an a web view is so easy