flowlet's see who of council is missing? jonas’ dwd
flowahh, a wild Ge0rG awakes
Ge0rGI've heard jonas’ is on holiday, and I'm still in a phone conference.
danielhe is on holiday but didn’t mention that in the agenda he sent yestarday?
flowand is see a "+1w wfm" from him in the backlog
danielI 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
danieli'm still here
Ge0rGis still not quite here
jonas’thanks
jonas’2) Agenda Bashing
ZashI got thrown off by my vacation ending
jonas’any modifications?
danielnone here
ZashNo
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
ZashI 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.
danielif we were talking about an experimental XEP i'd find 972 to be the better, more explicit option
jonas’I agree with daniel
danielbut we aren't
jonas’does anyone want to discuss anything else before I start the votes?
ZashDoes 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 ++
flowZash, sure, which change to you refer to?
Zash972, 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
flowwell, 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
flowit'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?
flowreading 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.
flowif 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
flowand 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.
ZashSHOULD is still pretty strong
flowZash, not sure if "pretty strong" is any better than, "may or may be not annotated"
MattJNot 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
Zashon-list
flowI 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
flowI 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?
danielnot 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.
Zashalso on-list
danielon 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
ZashMmmm, 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
flowwell as #972 is rejected, I assume that nobody wants the requirement that 'result' forms have to carry type annotations
vanitasvitaehas left
flowwhich comes not unexpected, I think I wrote somewhere that I too fear that the ship has sailed
ZashSure, 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'
flowI hear you, and that appears to the the actualy discussion
flowwhich is suprising to me, because I believe that this would be consens
flowand that this is the intention of the text currently written, although I also see that it could be interpreted otherwhise✎
flowand 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
flowFor 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✎
flowthat 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.
ZashIn 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)
flowjonas’, 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?
flowas 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
flowsorry, 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.