Ge0rGGood morning. I'm here but will be probably interrupted in the middle of things.
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.
Ge0rGI'd be okay to changing it to a MUST without a version bump, because the protocol doesn't make sense otherwise.
Ge0rGStill here. For now.
KevDave sent apologies.
Ge0rGSamWhited: no need to be sorry for being here
SamWhitedon phone, got stuck in traffic. May be slow to respond.
KevI didn't get a chance to review before the meeting, will onlist (for this and the following two)
Ge0rGI only just realized the three PRs 15mins ago
SamWhitedahh, switching between things is now very painful on Android 9
Ge0rGOL as well, but with my lacking knowledge of PubSub I'll probably bring this up next meeting with further questions
Ge0rG-1 as written above, right before the meeting start
> -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.
Ge0rGI'd like to hear what other Council members think of making the 'id' a MUST
Ge0rG...and doing so without a bump.
Ge0rGand *if* we bump 0184, I'd also add multi-ACKs
danielA version or a name space bump?
danielWhat's the problem with version bumps
Ge0rGdaniel: is there a difference between version and namespace bumps?
Ge0rGthe version is encoded in the namespace, isn't it?
KevEvery change to the XEP has a version bump, most don't touch the namespace.
danielBut you mean NS bump then
danielYeah I wouldn't want to bump the ns
Ge0rGI'm indifferent to bumping the version of the XEP document.
Ge0rGThat's not what causes interop to break ;)
peterIIRC 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.
KevIt's fairly meaningless otherwise, or I'm being dense. 50:50.
Link MauveThis is already implied by <request/> being optional in a message, btw.
Ge0rGthe alternative would be something like "a receipt without an 'id' is an acknowledge for all messages received so far OMG RACE CONDITIONS!!!"
Link MauveIn 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.
peterAnd 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.
KevI suppose you could build a synchronous system using receipts without ids.
Kevpeter: The argument for the bump would be that previously you'd be compliant without the id, but now you wouldn't be.
KevI 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.
Link MauveAck, I’ll update the PR with such a note.
KevLink Mauve: Ta muchly.
Ge0rGLink Mauve: 👍
SamWhitedIf 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?
KevSamWhited: That's what the note would alert you to.
Ge0rGhas to go off
SamWhitedoh right; sorry, need to catch up.
KevYou can't really do anything useful with a receipt without an id anyway, even now.
KevUnless you're really building a synchronous system that can't have multiple messages in flight before an ack.
KevBut I still need to OL to check it properly.
Kev5) Date of next
danielShould 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
danielNone from me
SamWhitedI apologize for being behind (on last week still too); I will try to catch up. Probably today, at the latest before Friday.
KevRight, I think we're done then. Thanks all :)
peterBTW 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.
peterI'm working on very different things these days (e.g., payments), but I'm always happy to help where needed.
jonaswpeter, while I have you here, have you received my email to trademark@?
peterI don't recall seeing it.
peterThose messages redirect to board@ and maybe it's in a queue.
jonaswit’s from 2018-07-29
Kevboard@ is members-only, drop everything else, IIRC.
jonaswthat would be unfortunate if trademark@ redirects there.
peterNope, we have an admin queue for that list.
peterI clear it out every week or so.
KevSo if trademark@ is redirecting there I suspect it's being less helpful than it might be.
KevI remember changing stuff for Laura a few years ago, but I guess we changed it back.
peterjonasw: please resend
peterI think I deleted it in error
jonaswdid just now, peter
peterjonasw: received and approved (sorry about the delay, I was in a meeting)