[Standards] Council Minutes 2020-08-05
teddsterr at outlook.com
Tue Aug 11 12:09:16 UTC 2020
Georg agreed to Chair in Jonas's absence.
1) Roll Call
Present: Zash, Georg, Daniel
2) Agenda Bashing
Georg wanted to add a follow-up to PR #854, but will postpone it for another Council meeting.
Jonas provided some more context on PR #971, which could be discussed.
3) Editor's Update
Georg dons his Jonas Hat (the resemblance is uncanny).
* XEP-0048 (Bookmarks) deprecated in favour of XEP-0402 (PEP Native Bookmarks)
* Ongoing Calls:
- Last Call for XEP-0352 (Client State Indication), ends on 2020-08-18
- Last Call for XEP-0411 (Bookmark Conversion), ends on 2020-08-18
4) Discuss PR #971 (XEP-0004: Clarify field type omission for 'submit' and 'result' form field types) - https://github.com/xsf/xeps/pull/971
Georg notes this recurring topic is expiring today; Jonas vetoed on-list, with some advice on how to improve the wording  - Zash thought it sounded sensible.
Georg was confused as to how removing words could increase clarity, but still isn't sure it improves the situation given the underspecification for error-type forms, and it might be improved through rewording.
Georg votes -1.
Zash votes -1 (what Jonas said).
Daniel votes -1 (what Jonas said).
5) Pending Votes
Georg votes +1 on PR #963, bringing the grand total of his pending votes to zero.
6) Date of Next
2020-08-12 1500 UTC
Georg takes the opportunity to discuss PR #854 (XEP-0045: Direct messages SHOULD be used over PMs in non-anonymous rooms) after all.
Georg would like to add a rationale to the effect of "if you send a PM to somebody who's also your contact, it might be rendered as coming from a separate person", but fails to find wording as befits the formal grandeur of an standards document.
Zash suggests this might be better suited to ModernXMPP  - Georg thinks that might be less than optimal for discoverability - Zash isn't sure hiding it within the depths of XEP-0045 is optimal for discoverability either. Georg expects that being able to point to an Official™ XSF Standards Document will have more clout than pointing to a website. MattJ doesn't think it's more discoverable, and this concerns UX rather than protocol - Georg says the focus is on protocol considerations arising from UX.
Daniel thinks 'SHOULD NOT' might be too strong for a retroactive recommendation - Georg adds that 'SHOULD' was discouraged the last time this was brought up. Zash suggests, then, an implementation note may be more appropriate, though ModernXMPP seems a marginally better option. Daniel thinks there is too much 'SHOULD' and 'SHOULD NOT', regardless.
Daniel suggests adding it to ModernXMPP in the first instance, and revisiting the topic if that doesn't yield the desired result - Georg notes that it's already there .
Georg resolves to raise this on The List™ .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards