Good morning. I'm here but will be probably interrupted in the middle of things.
peterhas joined
Ge0rG
-1 to https://github.com/xsf/xeps/pull/690 because the change makes the schema inconsistent with the text. We should fix that by making 'id' mandatory in both places, but I really don't want to version-bump over this.
Ge0rG
I'd be okay to changing it to a MUST without a version bump, because the protocol doesn't make sense otherwise.
Kev
It's time.
Kev
1) Rolls
Kev
Here
Ge0rG
Still here. For now.
Kev
Dave sent apologies.
Davehas left
Kev
daniel, SamWhited.
SamWhited
here, sorry
Ge0rG
SamWhited: no need to be sorry for being here
daniel
Hi
SamWhited
on phone, got stuck in traffic. May be slow to respond.
Kev
2) https://github.com/xsf/xeps/pull/693
Kev
I didn't get a chance to review before the meeting, will onlist (for this and the following two)
SamWhited
+1
Ge0rG
I only just realized the three PRs 15mins ago
Ge0rG
onlist
daniel
On last
daniel
*List
SamWhited
ahh, switching between things is now very painful on Android 9
Kev
3) https://github.com/xsf/xeps/pull/692
Kev
OL again.
SamWhited
OL
Ge0rG
OL as well, but with my lacking knowledge of PubSub I'll probably bring this up next meeting with further questions
Kev
daniel?
daniel
On list
Kev
4) https://github.com/xsf/xeps/pull/690
Kev
Ol
daniel
On list
Ge0rG
-1 as written above, right before the meeting start
Ge0rG
For Tedd:
> -1 to https://github.com/xsf/xeps/pull/690 because the change makes the schema inconsistent with the text. We should fix that by making 'id' mandatory in both places, but I really don't want to version-bump over this.
> I'd be okay to changing it to a MUST without a version bump, because the protocol doesn't make sense otherwise.
Ge0rG
I'd like to hear what other Council members think of making the 'id' a MUST
Davehas left
Ge0rG
...and doing so without a bump.
SamWhited
OL
Ge0rG
and *if* we bump 0184, I'd also add multi-ACKs
daniel
A version or a name space bump?
daniel
What's the problem with version bumps
Ge0rG
daniel: is there a difference between version and namespace bumps?
Kev
Yes.
Ge0rG
the version is encoded in the namespace, isn't it?
Kev
Every change to the XEP has a version bump, most don't touch the namespace.
daniel
But you mean NS bump then
daniel
Yeah I wouldn't want to bump the ns
Ge0rG
I'm indifferent to bumping the version of the XEP document.
Ge0rG
That's not what causes interop to break ;)
peter
IIRC we didn't want to assume that everyone would want to do tracking, but I'd be OK with saying that if you send a <received/> element you MUST include an 'id' attribute.
Kev
It's fairly meaningless otherwise, or I'm being dense. 50:50.
Link Mauve
This is already implied by <request/> being optional in a message, btw.
Ge0rG
the alternative would be something like "a receipt without an 'id' is an acknowledge for all messages received so far OMG RACE CONDITIONS!!!"
Link Mauve
In this PR I did interpret SHOULD as MUST, because it doesn’t make any sense otherwise. I can change it to the MUST it should always have been, in a future version.
peter
And I don't see a need for a namespace bump - an entity who gets a <received/> back might now get more information, which is nice but AFAICS doesn't break anything in the field.
Kev
I suppose you could build a synchronous system using receipts without ids.
Kev
peter: The argument for the bump would be that previously you'd be compliant without the id, but now you wouldn't be.
Kev
I don't think the disruption is warranted here, but I think a note to the effect that you might receive one without because of previous versions would be sane.
peter
Sure.
peternods
Link Mauve
Ack, I’ll update the PR with such a note.
Kev
Link Mauve: Ta muchly.
Ge0rG
Link Mauve: 👍
SamWhited
If it's just about compliance then that seems fine, but I think a NS bump might be necessary because you couldn't rely on their being IDs despite it being a MUST, no?
Kev
SamWhited: That's what the note would alert you to.
Ge0rGhas to go off
SamWhited
oh right; sorry, need to catch up.
Kev
You can't really do anything useful with a receipt without an id anyway, even now.
Kev
Unless you're really building a synchronous system that can't have multiple messages in flight before an ack.
Kev
But I still need to OL to check it properly.
Kev
5) Date of next
Kev
SBTSBC?
SamWhited
WFM
Kev
6) AOB?
daniel
Should work for me. That's the day I'm coming back from vacation. But my plane is scheduled to land a few hours before the meeting
daniel
None from me
SamWhited
I apologize for being behind (on last week still too); I will try to catch up. Probably today, at the latest before Friday.
Kev
Right, I think we're done then. Thanks all :)
Davehas left
peter
BTW if you ever think that my participation is needed (as XEP author), feel free to poke me via email or at-mention me at GitHub.
Kev
Thanks Peter.
peter
I'm working on very different things these days (e.g., payments), but I'm always happy to help where needed.
jonasw
peter, while I have you here, have you received my email to trademark@?
Davehas left
peter
I don't recall seeing it.
jonasw
mmm
peter
Those messages redirect to board@ and maybe it's in a queue.
jonasw
it’s from 2018-07-29
Kev
board@ is members-only, drop everything else, IIRC.
jonasw
that would be unfortunate if trademark@ redirects there.
peter
Nope, we have an admin queue for that list.
peter
I clear it out every week or so.
Kev
So if trademark@ is redirecting there I suspect it's being less helpful than it might be.
Kev
Ah, ok.
Kev
I remember changing stuff for Laura a few years ago, but I guess we changed it back.
peter
jonasw: please resend
peter
I think I deleted it in error
jonasw
did just now, peter
kasper.dementhas joined
Davehas left
Davehas left
Davehas left
guus.der.kinderenhas left
guus.der.kinderenhas joined
Davehas left
martinhas left
kasper.dementhas joined
Davehas left
Davehas left
kasper.dementhas joined
Davehas left
Davehas left
Davehas left
Davehas left
Davehas left
Davehas left
peter
jonasw: received and approved (sorry about the delay, I was in a meeting)