-
daniel
Hi
-
eta
hi daniel :p
-
vanitasvitae
Hello!
-
flow
huhu
-
eta
oh is there a meeting
-
eta
oops
-
flow
we are about to find out :)
-
Zash
dun dun duuuuuun
-
Ge0rG
good morning
-
flow
let's see who of council is missing? jonas’ dwd
-
flow
ahh, a wild Ge0rG awakes
-
Ge0rG
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
- Ge0rG is 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)
-
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
- daniel was 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
- Zash fiddles 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
-
jonas’
I am +1 on that one
-
Zash
+1
-
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
-
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.
-
Zash
Thanks