[Standards] Council Minutes 2020-04-01

Dave Cridland dave at cridland.net
Tue Apr 14 21:32:13 UTC 2020

On Wed, 1 Apr 2020 at 17:31, Tedd Sterr <teddsterr at outlook.com> wrote:

> http://logs.xmpp.org/council/2020-04-01?p=h#2020-04-01-679b0ee4558ba19a
> *1) Roll Call*
> Present: Zash, Georg, Jonas, Daniel
> Apologies: Dave
> *2) Agenda Bashing*
> Nothing to add.
> *3) Editor's Update*
> * Expired calls: None
> * Calls in progress: XEP-0357 and XEP-0280.
> * New ProtoXEP: MUC Presence Versioning
> * More activity on OMEMO
> * XEP-0402 advanced to Draft
> * XEP-0435 (Reminders) accepted
> *4a) Proposed XMPP Extension: MUC Presence Versioning* -
> https://xmpp.org/extensions/inbox/muc-presence-versioning.html
> Jonas: [on-list] (haven't read it yet)
> Daniel: +1
> Zash: +1 (interesting and seemed Good Enough™ for Experimental)
> Georg: +1
> Dave: [pending]
An odd one. In principle, I see the attraction, but I suspect that this is
both most useful at scale, and also least implementable at scale.

But hey, I don't see it'll do any harm to try it out, so +1.

That said, I would be very interested to take §5 and write a larger XEP
around it on scaling MUC.

> *4b) PR #913 - XEP-0068: Clarify that FORM_TYPE does not need to be
> type='hidden' in submission forms* - https://github.com/xsf/xeps/pull/913
> Georg asks whether this has implications for legacy forms - Jonas thinks
> it does in theory, as forms which weren't previously under the XEP-0068
> (Field Standardization for Data Forms) regime now are, but doesn't think
> it's critical. Zash thinks that for type=submit, one would likely already
> have the form prototype, and so the form type is already known.
> Georg: +1
> Jonas: +1 (the 'clarification' is good)
> Zash: +1
> Daniel: [on-list]
> Dave: [pending]
I hate to do this because it's so late, but some of Florian's arguments are
sound, and the implications rather more so.

We know that while many implementations ignore whether a FORM_TYPE is
hidden when submitting, some presumably do not and were conforming.

We also know many implementations didn't specify type="hidden" when
sending, and we wish to note this.

So far, so good, and therefore I agree with the essentials of the change -
though I agree with Florian's comment that some note on rationale is useful.

But it seems to me that we probably don't want to simply omit whether
submitting entities should or should not include type="hidden", and the
current proposed text appears to imply that they should not, whilst
avoiding any 2119 language which would clarify.

I *think* we ought to be saying SHOULD send type="hidden" on submit, but
MUST NOT require it when processing a submission. Honestly, I could be
persuaded otherwise, but we're changing a MUST into a HANDWAVE and that
seems worrying in an Active specification. Florian also notes this
obliquely with suggesting a MAY here, which caused me to think along these

Therefore I'd like to see more clarification on mandated behaviour (whether
or not it's as I suggest above), and sadly I have to throw in a last-minute
-1, for which I truly apologise.

(Also, I'm surprised this is Informational, it feels a bit Standards Track
to me, but that's a whole other story).

> *5) Outstanding Votes*
> Jonas notes the two remaining votes on XEP-0184 for Zash and himself,
> though it has already been vetoed; Jonas votes +0 (following Dave's
> argument); Zash votes +0.
> Georg asks whether there was further clarification from the authors of
> 0184 - Jonas says Peter said he'd help, so coordinate with him about which
> tasks are to be done - Georg will do so.
> *6) Date of Next*
> 2020-04-08 1500 UTC
> [DST is now in full swing.]
> *7) AOB*
> Zash has fond memories of vCard4.
> *8) Close*
> Thanks everyone.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200414/3147f3c2/attachment-0001.html>

More information about the Standards mailing list