XMPP Council - 2018-08-08

Good morning. I'm here but will be probably interrupted in the middle of things.

-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.

It's time.

1) Rolls

Here

Still here. For now.

Dave sent apologies.

daniel, SamWhited.

here, sorry

SamWhited: no need to be sorry for being here

Hi

on phone, got stuck in traffic. May be slow to respond.

2) https://github.com/xsf/xeps/pull/693

I didn't get a chance to review before the meeting, will onlist (for this and the following two)

+1

I only just realized the three PRs 15mins ago

onlist

On last

*List

ahh, switching between things is now very painful on Android 9

3) https://github.com/xsf/xeps/pull/692

OL again.

OL

OL as well, but with my lacking knowledge of PubSub I'll probably bring this up next meeting with further questions

daniel?

On list

4) https://github.com/xsf/xeps/pull/690

Ol

On list

-1 as written above, right before the meeting start

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.

I'd like to hear what other Council members think of making the 'id' a MUST

...and doing so without a bump.

OL

and *if* we bump 0184, I'd also add multi-ACKs

A version or a name space bump?

What's the problem with version bumps

daniel: is there a difference between version and namespace bumps?

Yes.

the version is encoded in the namespace, isn't it?

Every change to the XEP has a version bump, most don't touch the namespace.

But you mean NS bump then

Yeah I wouldn't want to bump the ns

I'm indifferent to bumping the version of the XEP document.

That's not what causes interop to break ;)

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.

It's fairly meaningless otherwise, or I'm being dense. 50:50.

This is already implied by <request/> being optional in a message, btw.

the alternative would be something like "a receipt without an 'id' is an acknowledge for all messages received so far OMG RACE CONDITIONS!!!"

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.

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.

I suppose you could build a synchronous system using receipts without ids.

peter: The argument for the bump would be that previously you'd be compliant without the id, but now you wouldn't be.

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.

Sure.

Ack, I’ll update the PR with such a note.

Link Mauve: Ta muchly.

Link Mauve: 👍

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?

SamWhited: That's what the note would alert you to.

oh right; sorry, need to catch up.

You can't really do anything useful with a receipt without an id anyway, even now.

Unless you're really building a synchronous system that can't have multiple messages in flight before an ack.

But I still need to OL to check it properly.

5) Date of next

SBTSBC?

WFM

6) AOB?

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

None from me

I apologize for being behind (on last week still too); I will try to catch up. Probably today, at the latest before Friday.

Right, I think we're done then. Thanks all :)

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.

Thanks Peter.

I'm working on very different things these days (e.g., payments), but I'm always happy to help where needed.

peter, while I have you here, have you received my email to trademark@?

I don't recall seeing it.

mmm

Those messages redirect to board@ and maybe it's in a queue.

it’s from 2018-07-29

board@ is members-only, drop everything else, IIRC.

that would be unfortunate if trademark@ redirects there.

Nope, we have an admin queue for that list.

I clear it out every week or so.

So if trademark@ is redirecting there I suspect it's being less helpful than it might be.

Ah, ok.

I remember changing stuff for Laura a few years ago, but I guess we changed it back.

jonasw: please resend

I think I deleted it in error

did just now, peter

jonasw: received and approved (sorry about the delay, I was in a meeting)

thank you :)