XMPP Council - 2023-05-31

o/

is it the time?

you're one minute early

I am indeed

.

1) roll call

Here 👋️

o/

Ge0rG is on vacation. is moparisthebest around?

2) Agenda bashing

nothing to bash

3) Editors update

no updates

4) Items for voting

we have some old items from the issue tracker that the editor pointed us to

a) Update BCP 14 language to comply with RFC 8174 https://github.com/xsf/xeps/pull/706

+1

I think I’m -1 on this unless someone convinces me otherwise. this changes the normative language in existing xeps

in case someone wrote must instead of MUST

for me this files under "clarification"

if someone wrote must instead of MUST, I wouldn't have interpreted it as BCP 14 language

if we were to start from scratch i agree that we should use MUST

> I wouldn't have interpreted it as BCP 14 language i would

.oO(we SHOULD use MUST...? ;))

How often did it happen that people use lowercase bcp 14 language?

daniel, great!

so we're in a situation of ambiguity already

larma, we don’t know I guess

hence me not wanting to change the meaning of random xeps

conversely, not applying #706 would seem to imply that lowercase versions may be BCP 14 in fact

which'd be weird for things like: xep-0212.xml 111: <p>Some of the protocol specifications referenced herein have their own dependencies; developers must refer to the relevant specifications for further information.</p>

or the requirements section of '390 ✏

XEPs traditionally predate the "MUST MUST be MUST"s, FWIW.

`ag -s must` is way too much to audit though

So I think it's a case by case basis what the author meant.

Kev, this means usually people mean MUST when they write must?

is there a middle-ground we can find?

It'd be good to have it for future specifications which are accepted into any new state

I think it means it's very muddy, as some people have always thought it needs to be uppercase even when the specs didn't say so.

I don’t have super hard feelings on this. I'd be willing to vote 0 instead of -1

like anything which transitions to Stable now, or which enters Experimental

(but honestly I'd just prefer to merge #706 as-is and fix whatever is broken when we come across it; I'm with Kev here)

I agree that we might want to pay closer attation to accidental usages of keyswords

and enforce the upper case rule

fwiw, I cannot recall a place where there was a "must" instead of a "MUST"

I count more than 200 XEPs that contain lowercase keywords

(or similar for the other words)

I note that there's multiple questions to answer here.

in general I'd prefer that xep authors not use those keyswords if they don’t mean those keywords

One is whether we want 8174 instead of 2119. One is whether we want to backdate that for all existing specs (possibly changing their meaning). One is whether it's ok to make that change to all XEPs without a version bump.

no matter if upper case or not

I'm fairly firmly against changing the meanings of XEPs (which merging this would) without a version bump of the version. Not that I get a vote.

daniel, I think that makes wording stuff very complex

324 XEPs contain " may "

daniel, look at the requirements section of XEP-0390.

using MUST there is wrong, because it's not an interop thing, it's a thing which frames the document

replacing MUST with "have to" or something like that would be possible, of course, but more confusing to authors and readers than the MUST/must distinction, I think.

I feel we should migrate to RFC 8174 for clarity, but we probably want to do it in a way that does not change the meaning of existing XEPs

> replacing MUST with "have to" or something like that would be possible, of course, but more confusing to authors and readers than the MUST/must distinction, I think I mean in the end it's a matter of personal preference. but i disagree and think finding synonymes if you have to isn’t super hard

and less confusing if you read out the text (to discuss it and/or screen readers maybe)

daniel, fair

I'm very late, trying to catch up

> and less confusing if you read out the text (to discuss it and/or screen readers maybe) "Sorry, did you say must or must?" :)

I think my ideal, for the little it's worth, would be to see the words available for 2119/8174 only used normatively, and only in upper case. But that's not necessarily where we are right now.

IMO what we need or should do is flag XEPs at source level if they're 2119 or 8174. New XEPs and new revisions of existing XEPs should always be 8174

I tend to think we can update this to make it clear and if it "breaks" things can fix them on a case by case basis

larma, that'd work too, require just a few more changes to xep.xsl and xep.dtd I guess

I'd be +1 on that too

kind of like rust editions

> IMO what we need or should do is flag XEPs at source level if they're 2119 or 8174. New XEPs and new revisions of existing XEPs should always be 8174 If we can do that, and combine it with "Don't use lowercase language in any future changes", happy days.

I like that idea but who will do the leg work, meaning xsl/DTD updates

i'd be in favor of using 8174 for new xeps

> I like that idea but who will do the leg work, meaning xsl/DTD updates I'm definitely not volunteering, I have no spare cycles.

i think council can make that recommendation irregardless of how we implement it

I think the current direction is "Don't merge PR as-is", is that correct?

Recommendation yes, I hesitate to vote "it MUST be like this" with no one to implement it though, like editor verifying this manually would be terrible

anyone else wants to vote on that PR?

I think I'll vote -0 also :)

Kev, thus far no one has really convinced me of changing my -1 to a 0

I think I'm -1 on the PR as well, I fear it changes things in too many stable/final XEPs.

ok. moving on

b) XEP-0001: Make only editorial changes affect Deferred state https://github.com/xsf/xeps/pull/780

+1

+1

+1

+1

c) XEP-0166: Relax transport element requirement https://github.com/xsf/xeps/pull/793

I‘m -1 on that. as far as i'm aware author didn’t really like it. i'm not remembering a big standards discussion on that

if it becomes important again the relevant parties can bring it up again

I'm gonna say -1 for the sameish reason, if someone really wanted it they would have brought it up again and still can

i'm voting this mostly so that we can close the PR because of a lack of context/discussion

I'm -1 because it is breaking and we already have more than a dozen implementations of the stable XEP in production

the thread would've been here I guess: https://mail.jabber.org/pipermail/standards/2019-June/036204.html

which iiiiissss connection refused I guess

do you have the title so i can search for it locally?

I'll see

no, actually I don't, but I'll search my own archive now

i'd be willing to bump it so more people can make their arguments if they have them

Sounds good to me

daniel, [Standards] PR #793 - XEP-0166: Relax transport element requirement

thanks

any other votes?

we are a bit over time but i think we can wrap this up quickly

5) Pending votes

none

6) Date of next

+1w wfm

+1w wfm

+1w wfm

ooh

may not work for me

all day thing at work, not sure if that finishes in time

+1w wfm

ok. i'll keep that in mind

7) AOB

none from me

8) Close

thank you all

thanks daniel o/

thanks daniel

Thanks for clearing out the Editor stuff.

Re bcp14, let me tell you about https://datatracker.ietf.org/doc/html/rfc2181#section-3

Read that section and be horrified 💀️

I have read it before. Why would you make me remember it? :'(

> Re bcp14, let me tell you about https://datatracker.ietf.org/doc/html/rfc2181#section-3 https://burtrum.org/up/e241a154-7d5c-43b7-830a-d8dd25d61925/but-why-meme.jpg ↺

As a warning for the future on how *not* to do it

"This specification does not use the oft used expressions. In some sections, it may seem that one meaning is intended.That is not correct. Anywhere that the Author intended that meaning be inferred, that is to be considered a fundamental aspect of this specification, regardless of the words they used."