XMPP Council - 2020-07-22

Hi

hi daniel :p

Hello!

huhu

oh is there a meeting

oops

we are about to find out :)

dun dun duuuuuun

good morning

let's see who of council is missing? jonas’ dwd

ahh, a wild Ge0rG awakes

I've heard jonas’ is on holiday, and I'm still in a phone conference.

he is on holiday but didn’t mention that in the agenda he sent yestarday?

and is see a "+1w wfm" from him in the backlog

I can chair but with only Zash and me being here that's going to be a boring meeting anyway

ehh

yeah

as promised, I got totally thrown off in my schedule by vacation

sorry for the delayed start

1) Roll Call

re-pinging daniel, Zash, and Ge0rG

i'm still here

thanks

2) Agenda Bashing

I got thrown off by my vacation ending

any modifications?

none here

No

3) Editor’s Update - Advanced XEP-0338 to Draft

4) Items for voting

4a) PR#971 vs. PR#972 URL: https://github.com/xsf/xeps/pull/971 URL: https://github.com/xsf/xeps/pull/972 Summary: The first one is truly an (editorial) clarification (AFAICT), the second one is a normative change to the presence of type fields in certain form types.

technically, we probably need to vote on each one individually, but we should discuss them together

note that XEP-0004 is final

I agree with the comment about "clarify"

I am firmly against changing normative wording in '4 (a final spec), especially when there’s evidence that implementations already do what the change would forbid.

if we were talking about an experimental XEP i'd find 972 to be the better, more explicit option

I agree with daniel

but we aren't

does anyone want to discuss anything else before I start the votes?

Does flow wanna explain the rationale behind changing normative language?

there was some discussion about that in https://logs.xmpp.org/xsf/2020-07-21#2020-07-21-5b9e98899766b145 ++

Zash, sure, which change to you refer to?

972, the one where jonas’ notes that it changes MUSTs and such

flow, why not all of them, given that this is a Final spec.

but the most crucial one (which goes beyond clarification) would be the change for type="form" from SHOULD to MUST for field@type ✏

(for me anyways)

well, if you believe that 'form' type form fields must always have had field type annotations, then the change from SHOULD to MUST is not really a change in the spec

it's merly a clarification

(field type annotations for fields other than text-single that is)

flow, so you’re trying to second-guess the intentions of the original authors?

reading a spec, you always "guess" the intentions of authors

the intent of using RFC 2119 language is to reduce the guessing

I think you need a pretty strong argument beyond "it might’ve been the intention" when changing RFC 2119 language in a Final spec.

if your reading is different than mine, then yes, this means that it was previously allowed that fields other than text-single in 'form' type forms come without type annotation

and now is no longer

I fail to see how this is a matter of reading. It is 100% clear that there is a SHOULD and not a MUST.

there is no ambiguity in the language I can see here. Yes, it is unfortunate that omission of the field@type is allowed, but that’s the text-as-written and it wasn’t caught in either the CFE or the LC leading up to the XEPs Final state.

I don’t see any wiggle-room to interpret this text by itself so that `MUST` was intended.

the only way to justify the replacement based on an "intention" argument would be to get input from the original authors, but *even then* I don’t think that we should change a Final spec when we can very easily see opposite behaviour.

SHOULD is still pretty strong

Zash, not sure if "pretty strong" is any better than, "may or may be not annotated"

Not sure of the context, but indeed 'SHOULD' is more or less equivalent if you're a consumer of the protocol

equivalent to what?

'MUST', sorry

MattJ, for your context: https://github.com/xsf/xeps/pull/972/files vs. https://github.com/xsf/xeps/pull/971/files

anyways, we spent 1/3 of the normal meeting timeframe on this.

I’ll call for votes now, if you see further need for discussion, please take it to the list

I’m going to start with the (probably) simpler one. Noting that if council accepts both PRs, the Editor will ask for a way to resolve the resulting conflict.

4a I) PR#972: XEP-0004: Clarify that 'result' forms must have explicit field types

on-list

I am -1 on PR#972, because it changes a strongly-worded RFC 2119 business rule without sufficient rationale and while evidence of behaviour, which would then be non-compliant, exists.

flow, we can discuss this in AOB if you like

-1

I think this distracts from the real motivation of the PR: should 'result' type forms require type annotations? I'd like to hear the opinion of the council members (and others of course) ✏

daniel, rationale?

not significant enough to change the normative language of a final xep

daniel, thanks

4a II) PR#971: XEP-0004: Clarify field type omission for 'submit' and 'result' form field types

I think I’m going to be on-list for that one, since I can’t read the diff well and I need to do this closely.

also on-list

on list

thanks

4b) PR#969: XEP-0045 v1.33.0 URL: https://github.com/xsf/xeps/pull/969 Abstract: Clarify that the 307 status code should not be used alongside 333 for user disconnects (re-do of PR#926) See-Also: https://github.com/xsf/xeps/pull/926

Mmmm, an interdiff would be nice

note that the diff between #926 and #969 is only s/recommended/advisable/ in that one line

I am +1 on that one

+1

+1

thanks

5) Pending Votes

dwd has some

6) Date of Next

+1w wfm

(this time, no vacation, so I’m less likely to forget :))

+1w wfm

+1w wfm

\o/

7) AOB

flow has some, maybe

but first I’d like to ask daniel and Zash if they’re ok with extending by at least 5 minutes to make up for my lateness, or longer if we need to

well as #972 is rejected, I assume that nobody wants the requirement that 'result' forms have to carry type annotations

which comes not unexpected, I think I wrote somewhere that I too fear that the ship has sailed

Sure, but no promises of being fully awake.

flow, I don’t want the requirement for type='form'

because it’s clearly written as being SHOULD

have to read up on type='result'

I hear you, and that appears to the the actualy discussion

which is suprising to me, because I believe that this would be consens

and that this is the intention of the text currently written, although I also see that it could be interpreted otherwise ✏

ok, so, for type='result', it is currently a MAY

For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data (if no 'type' is specified, the default is "text-single");

that is the sentence in question

raising that to a MUST would at least cause issues for new receiving implementations ✏

flow, not ßquite, the important part for type='result' is missing: > […]; fields provided in the context of other forms types MAY possess a 'type' attribute as well.

In general, if you are confident that the receiver of the form, regardless of type, knows the "schema", then including that metadata seems redundant, and thus okay to leave out.

(I’m more on the line of "keep it there always" because it’s easier to do validation then, but ok)

jonas’, right, let's focus on 'form' type form and if their fields are required to have type annotations

flow, you were asking about 'result' earlier tho

which is it?

as I wrote, the ship has sailed now that #972 was vetoed

because for 'form' I think the matter is 100% clear that they SHOULD have annotations, which is not a MUST, nor a MAY

but #972 was vetoed (from my side) because of 'form', not anything else

sorry, I meant #971

#971 wasn’t vetoed

everyone is on-list about #971

but I note that I didn’t get any feedback from either Zash or daniel about extending the meeting, so I’m going to close now; we can continue discussion in xsf@ or on-list

8) Ite meeting est

Thanks everyone, and sorry for being late. Next time when I’m on vacation, I’ll try to set up an alarm clock.

Thanks