I've heard jonas’ is on holiday, and I'm still in a phone conference.
daniel
he is on holiday but didn’t mention that in the agenda he sent yestarday?
flow
and is see a "+1w wfm" from him in the backlog
daniel
I can chair but with only Zash and me being here that's going to be a boring meeting anyway
jonas’
ehh
jonas’
yeah
jonas’
as promised, I got totally thrown off in my schedule by vacation
jonas’
sorry for the delayed start
jonas’
1) Roll Call
Zash←
jonas’
re-pinging daniel, Zash, and Ge0rG
daniel
i'm still here
Ge0rGis still not quite here
jonas’
thanks
jonas’
2) Agenda Bashing
Zash
I got thrown off by my vacation ending
jonas’
any modifications?
daniel
none here
Zash
No
jonas’
3) Editor’s Update
- Advanced XEP-0338 to Draft
jonas’
4) Items for voting
jonas’
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.
jonas’
technically, we probably need to vote on each one individually, but we should discuss them together
jonas’
note that XEP-0004 is final
Zash
I agree with the comment about "clarify"
jonas’
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.
daniel
if we were talking about an experimental XEP i'd find 972 to be the better, more explicit option
jonas’
I agree with daniel
daniel
but we aren't
jonas’
does anyone want to discuss anything else before I start the votes?
Zash
Does flow wanna explain the rationale behind changing normative language?
jonas’
there was some discussion about that in https://logs.xmpp.org/xsf/2020-07-21#2020-07-21-5b9e98899766b145 ++
flow
Zash, sure, which change to you refer to?
Zash
972, the one where jonas’ notes that it changes MUSTs and such
jonas’
flow, why not all of them, given that this is a Final spec.
jonas’
but the most crucial one (which goes beyond clarification) would be the change for type="form" from SHOULD to MUST for @type✎
jonas’
but the most crucial one (which goes beyond clarification) would be the change for type="form" from SHOULD to MUST for field@type ✏
jonas’
(for me anyways)
adiaholic_has left
flow
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
flow
it's merly a clarification
flow
(field type annotations for fields other than text-single that is)
jonas’
flow, so you’re trying to second-guess the intentions of the original authors?
flow
reading a spec, you always "guess" the intentions of authors
jonas’
the intent of using RFC 2119 language is to reduce the guessing
jonas’
I think you need a pretty strong argument beyond "it might’ve been the intention" when changing RFC 2119 language in a Final spec.
flow
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
flow
and now is no longer
jonas’
I fail to see how this is a matter of reading. It is 100% clear that there is a SHOULD and not a MUST.
jonas’
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.
jonas’
I don’t see any wiggle-room to interpret this text by itself so that `MUST` was intended.
jonas’
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.
Zash
SHOULD is still pretty strong
flow
Zash, not sure if "pretty strong" is any better than, "may or may be not annotated"
MattJ
Not sure of the context, but indeed 'SHOULD' is more or less equivalent if you're a consumer of the protocol
jonas’
equivalent to what?
MattJ
'MUST', sorry
jonas’
MattJ, for your context: https://github.com/xsf/xeps/pull/972/files vs. https://github.com/xsf/xeps/pull/971/files
jonas’
anyways, we spent 1/3 of the normal meeting timeframe on this.
jonas’
I’ll call for votes now, if you see further need for discussion, please take it to the list
jonas’
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.
jonas’
4a I) PR#972: XEP-0004: Clarify that 'result' forms must have explicit field types
Zash
on-list
flow
I think this distracts from the real motivation of the PR: should 'submit' type forms require type annotations? I'd like to hear the opinion of the council members (and others of course)✎
jonas’
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.
jonas’
flow, we can discuss this in AOB if you like
vanitasvitaehas left
danielwas briefly confused by the change of order
daniel
-1
flow
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) ✏
jonas’
daniel, rationale?
daniel
not significant enough to change the normative language of a final xep
jonas’
daniel, thanks
jonas’
4a II) PR#971: XEP-0004: Clarify field type omission for 'submit' and 'result' form field types
jonas’
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.
Zash
also on-list
daniel
on list
Zashfiddles with xep-to-markdown convertsion, in order to get a nicer comparison
jonas’
thanks
jonas’
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
Zash
Mmmm, an interdiff would be nice
jonas’
note that the diff between #926 and #969 is only s/recommended/advisable/ in that one line
vanitasvitaehas joined
jonas’
I am +1 on that one
Zash
+1
adiaholic_has joined
daniel
+1
jonas’
thanks
jonas’
5) Pending Votes
jonas’
dwd has some
jonas’
6) Date of Next
jonas’
+1w wfm
jonas’
(this time, no vacation, so I’m less likely to forget :))
daniel
+1w wfm
Zash
+1w wfm
jonas’
\o/
jonas’
7) AOB
jonas’
flow has some, maybe
jonas’
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
flow
well as #972 is rejected, I assume that nobody wants the requirement that 'result' forms have to carry type annotations
vanitasvitaehas left
flow
which comes not unexpected, I think I wrote somewhere that I too fear that the ship has sailed
Zash
Sure, but no promises of being fully awake.
jonas’
flow, I don’t want the requirement for type='form'
jonas’
because it’s clearly written as being SHOULD
jonas’
have to read up on type='result'
flow
I hear you, and that appears to the the actualy discussion
flow
which is suprising to me, because I believe that this would be consens
flow
and that this is the intention of the text currently written, although I also see that it could be interpreted otherwhise✎
flow
and that this is the intention of the text currently written, although I also see that it could be interpreted otherwise ✏
jonas’
ok, so, for type='result', it is currently a MAY
flow
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");
jonas’
raising that to a MUST would at least cause issues for new implementations✎
flow
that is the sentence in question
jonas’
raising that to a MUST would at least cause issues for new receiving implementations ✏
jonas’
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.
Zash
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.
jonas’
(I’m more on the line of "keep it there always" because it’s easier to do validation then, but ok)
flow
jonas’, right, let's focus on 'form' type form and if their fields are required to have type annotations
jonas’
flow, you were asking about 'result' earlier tho
jonas’
which is it?
flow
as I wrote, the ship has sailed now that #972 was vetoed
jonas’
because for 'form' I think the matter is 100% clear that they SHOULD have annotations, which is not a MUST, nor a MAY
jonas’
but #972 was vetoed (from my side) because of 'form', not anything else
flow
sorry, I meant #971
jonas’
#971 wasn’t vetoed
jonas’
everyone is on-list about #971
jonas’
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
jonas’
8) Ite meeting est
jonas’
Thanks everyone, and sorry for being late. Next time when I’m on vacation, I’ll try to set up an alarm clock.