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.

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to