[Standards] Council Minutes 2020-07-22

Tedd Sterr teddsterr at outlook.com
Tue Jul 28 22:29:11 UTC 2020


https://logs.xmpp.org/council/2020-07-22?p=h#2020-07-22-39e86b9401b53a9e

1) Roll Call
100% Present: Zash, Jonas, Daniel
3% Present: Georg
0% Present: Dave

2) Agenda Bashing
No modifications.

3) Editor's Update
* Advanced XEP-0338 to Draft

4a) PR #971 (XEP-0004: Clarify field type omission for 'submit' and 'result' form field types) versus PR #972 (XEP-0004: Clarify that 'result' forms must have explicit field types) - https://github.com/xsf/xeps/pull/971 | https://github.com/xsf/xeps/pull/972
The author, Flow, has noted that these two PRs effectively contradict each other.
Jonas notes that #971 seems to be only an editorial change, while #972 is a normative change; also, that they should be discussed together, but voted on separately (with attention to the fact that XEP-0004 is Final.)
Jonas is firmly against changing normative wording in a Final XEP, especially with evidence of implementations already doing what the change would forbid. Daniel would prefer #972 if XEP-0004 were Experimental - Jonas agrees.
Zash requests an explanation of the rationale behind changing normative language. Flow explains that if one believes fields (other than text-single) in forms of type 'form' must have always had field-type annotations then the change to MUST is merely a clarification - Jonas isn't convinced, and expects a stronger argument than second-guessing the authors' intended meaning - Flow suggests reading is always a matter of 'guessing' the authors' intentions, but the alternative interpretation would be that the fields are allowed to omit the type annotation. Jonas agrees that the omission of types is unfortunate, but that is the text as-written, and there is no indication that MUST was intended; input from the authors may be able justify the replacement, but even that could be problematic given that it's a change to a Final XEP. Zash adds that 'SHOULD' is still a strong requirement; MattJ adds that 'SHOULD' is largely equivalent to 'MUST' in most cases.
Jonas would like to get to voting at some point today, so further discussion will have to continue elsewhere. If Council votes to accept both PRs then the Editor shall ask for a way to resolve the conflict.

4a i) PR #972 (XEP-0004: Clarify that 'result' forms must have explicit field types) - https://github.com/xsf/xeps/pull/972
Zash: [on-list]
Jonas: -1 (changes a strongly-worded RFC 2119 business rule without sufficient rationale and while evidence exists of behaviour which would then be non-compliant)
Daniel: -1 (not significant enough to change the normative language of a final xep)
Georg: [pending]
Dave: [pending]

4a ii) PR #971 (XEP-0004: Clarify field type omission for 'submit' and 'result' form field types) - https://github.com/xsf/xeps/pull/972
Jonas: [on-list]
Zash: [on-list]
Daniel: [on-list]
Georg: [pending]
Dave: [pending]

4b) PR #969 (XEP-0045 v1.33.0) - https://github.com/xsf/xeps/pull/969
Jonas: +1
Zash: +1
Daniel: +1
Georg: [pending]
Dave: [pending]

5) Pending Votes
Three for Dave, expiring today.

6) Date of Next
2020-07-29 1500 UTC

7) AOB
With #972 being rejected, Flow assumes that nobody wants the requirement for 'result' forms to carry type annotations - Jonas doesn't want the requirement for 'form' forms because it's already explicitly written as a SHOULD; and it currently says MAY for 'result' forms, so raising that to MUST would probably cause issues for new receiving implementations. Flow still thinks the intention was for a MUST, but can see how it could be interpreted otherwise.
Zash notes that if the sender is confident that the form recipient knows the 'schema' (regardless of form type) then the metadata is redundant and thus okay to leave out.

8) Close
Jonas thanks everyone and apologises for being late - will try to remember to set an alarm the next time he's on vacation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200728/fd904364/attachment.html>


More information about the Standards mailing list