XMPP Council - 2020-06-10

'tis time

1) Roll Call

Here

here

quorum!

do we get a Ge0rG or a dwd maybe?

EHLO

Yes we do!

Full house!

500 Missing Hostname

wrong protocol

Oh. Shit.

2) Agenda Bashing ✏

I assume none

3) Editor’s update - Expiring calls - CFE for XEP-0050 (ended on 2020-06-09)

4) Items for Voting

I did not include the advancement vote of '0050 in here, because I presume that we’ll have more discussion about that in 4b. If anyone wants to have the vote on advancing '0050 to Final in this meeting either way, please speak up now.

assuming no, but you can still raise your voice until we’ve gotten past 4b

moving on

4a) PR#959: XEP-0156: reorganize stating XRD/JRD requirements URL: https://github.com/xsf/xeps/pull/959 Abstract: The reference to RFC 6120 was incorrect, what this really meant is RFC 6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to reorganize stating the requirements of XRD and JRD a little.

+1

I’m not quite sure if this adds new requirements on implementations, or if those are already implicit in RFC 6415

On list.

like what?

I'm not sure because it removes a "REQUIRED" and adds a "SHOULD

daniel, XML MUST, JSON SHOULD

I can’t read. ✏

so, yeah, it moves from MUST XML to SHOULD XML, and SHOULD JSON to MAY JSON.

I’m not quite sure what the point of that is

flow, are you around?

this seems odd to me, because now clients have to effectively support both since a service may opt to do no XML but JSON.

fair. I retract my +1. I didn’t see that

barring a magical appearance of flow, I’m on-list

any word from dwd?

around

I'm also on-list then. I suppose that if we fix the new language to keep the old MUST/SHOULD, I'd be fine

same as Ge0rG from my side

> I suppose that if we fix the new language to keep the old MUST/SHOULD, I'd be fine yes

flow, ah, good, can you comment?

reading the change

Yeah, I'll do a -1 on the basis that we've changed normative requirements.

ahh I see

(But I can be argued out of it).

dwd, without context, that sounds odd and I think you wanted to add a "without good reason" :)

can change

jonas’, Sorry, in full:

flow, excellent, then we’ll postpone this to next week

and I’ll cancel the vote

but given that there is no feature negotion about this

a MUST did not appears necessary

https://tools.ietf.org/html/rfc6415#section-3 reads like a MUST for XML

what I wanted to express is that you are not allowed to do JRD alone, without XRD

jonas’, -1 on the basis that we have changed normative requirements such that it is unclear what a consumer of the record need to implement to ensure interoperability.

but a MUST is probably clearer

flow, that is not at all clear from the text, please fix that

okay, moving on

4b) PR#598: XEP-0050: Try to clarify usage of 'execute' URL: https://github.com/xsf/xeps/pull/598 Abstract: The "execute" dilemma of XEP-0050.

I added wording to the PR compared to last week using my editor superpowers

specifically, I added this: https://github.com/xsf/xeps/pull/598/commits/fc14df1d8d49a065115cb4549e66e243db4b6ce3 (note that this only shows a subset of the total changes the PR introduces)

(full changes are here: https://github.com/xsf/xeps/pull/598/files )

I think this is the best we can do and I am +1 on this as-is.

on list

on list

+1

I think I'm +1 on this. Though we're deep into "least harm" territory, and I'll be interested in what others have to say.

agreed

since we’re considering adopting this, the advancement vote shall be postponed with another CFE later inbetween.

5) Outstanding votes

Ge0rG, I think you have quite a few, unless I’m behind on the mailing list mails.

oh, I am actually

jonas’: remember my inquiry about the origins of *bold* and _underline_ earlier today?

jonas’, Just on '50, I'm not sure that we *can* advance until people think (at least) that they implement the new version.

jonas’: I catched up with two-weeks-ago, and I'm not sure there were any votes last week

dwd, yes, hence, later :)

Ge0rG, no, you’re good, I’ve got everything from you now

phew.

thank you for that

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1W WFM

excellent

7) AOB

I have one regarding the Message Routing stuff.

I've heard that pep. and flow have an AOB

jonas’: I still didn't manage to do the doodle.

First I need to say mea culpa, because I got massively confused with dates and now more than half of the proposed timing lots is over.

Ge0rG, good thing is you only need to fill out like three days now.

Ge0rG, you have the nice opportunity to just pick one of the greenish slots onw

today would’ve worked great, but that’s not an option anymore, so I think Friday at 16:00 CEST is the only one we have left

Ge0rG, well I'm not sure :x

Ge0rG, would that work for you?

jonas’: +1 for Friday 16:00 CEST

I'd like to sort out the hanging PR about 0157 for sure. I don't know what to take off the list thread

ok, I’ll try to send out an email after this meeting.

pep.: I read the thread as a generally vague +1 with a hint to add a .well-known mapping

on the '157: My opinion is that dwd is absolutely correct and we should extend '68 to allow validation information.

(and also that dwd is correct in that we need a fixed registry)

somebody should fix it

yeah, somebody should

hm, I should ping MattJ if we can set up old-eos as a build worker for docker images...

anyways

pep., flow, I think the best way forward would be to update '68 and then update '157

I like to suggest that we see registry and their entries as extensible, instead of explicitly marking them

the '157 PR can then stay as-is and we can apply it once '68 is patched.

I mean this is a general thing, not limited to data forms

I’m hesitant about that, but an extended discussion should be continued on-list as pep suggested indeed.

We will in the future most likely run into situations where an xep extends another xep, and its elements, which are potentially found in a registry

any other AOB?

flow, Registries aren't interoperable protocols, they're documents of record, and as such have different rules.

dwd, sure, but what does that mean?

flow, Same argument, after all, applies the the XEP format itself.

(jonas’, is that what I suggested? :p)

pep., in fact, no, but I misread what you said, apologies

I’m not good at reading tonight

I still think that this is better suited for xsf@ or the list.

sure

assuming no other AOB:

7) Ite Meeting Est

jonas’, Thanks!

thanks all, thanks Tedd

Tanks all

please move further discussion about the registry things to xsf@

Thanks!

(or the list)

FYI, i've updated the PR of 4a