XMPP Council - 2020-05-13

.

not yet, dwd

It's probably ok to let dwd in here at other times than meetings, under careful adult supervision.

Kev: I'm not sure we have anybody who could provide that kind of supervision.

Fair.

But maybe the . is just a compensating measure for a client that lacks XEP-0410?

It was demonstrating XMPP to a(virtual) room full of people.

So your replies were excellent timing.

:D

were those Very Important People?

Colleagues. Included both CTO and one of our CEOs, but we're a small company and it was hardly a formal setting.

:)

as long as you didn’t want to prove the point that the XSF is a Super Serious Organization

I usually describe it as a Drinking Club with a Standards problem.

Pedantics Anonymous?

As a strict non-alcoholic, I don’t feel included in that definition ;P

as things stand, the other meeting will start only at 16:00Z, so I’ll be able to chair today.

Yay!

Hello everyone

1) Roll Call

Here

I would’ve thought that daniel would arrive, too

Hi

excellent

2) Agenda Bashing

anything to add to the agenda I sent?

(though now I wonder whether dwd will also join us)

Me too

I'm not opposed to keeping it short

me neither

3) Editor’s Update

- Calls in progress: - LC for XEP-0320 (ends at 2020-05-19) - LC for XEP-0339 (ends at 2020-05-19) - LC for XEP-0393 (ends at 2020-05-26)

4) Items for voting

4a) PR#943 Title: XEP-0068: Clarify FORM_TYPE field type on 'submit' type forms URL: https://github.com/xsf/xeps/pull/943

this is a re-do of #913, which was vetoed for $reasons by dwd

(digging up $reasons)

from https://mail.jabber.org/pipermail/standards/2020-April/037251.html: > I hate to do this because it's so late, but some of Florian's arguments are sound, and the implications rather more so.

and a lot more

RFC 2119 reasons?

I think I still have a nit to pick with the text

> Data forms with the type "submit" are free to omit any explicit field type declaration (as per &xep0004; § 3.2), as the type is implied by the corresponding "form"-type data form. As consequence, implementations MUST treat a FORM_TYPE field without an explicit type attribute, in data forms of type "submit", as the FORM_TYPE field with the special meaning defined herein.

I wonder if the following wouldn’t be more appropriate: > Data forms with the type "submit" are free to omit any explicit field type declaration (as per &xep0004; § 3.2), as the type is implied by the corresponding "form"-type data form. As consequence, implementations MUST treat a FORM_TYPE field without an explicit type attribute, in data forms of type "submit", as the FORM_TYPE field with the special meaning defined herein if the corresponding "form"-type form had the field "hidden".

(addition to the last sentence only)

but I’m not going to block based on this, so +1 ✏

on-list

On list

As I read the new text, it doesn't address Dave's remark about clarifying what a sending entity is expected to do.

But I'd leave this for Dave to sort out (Sorry, Dave), and go +1

alright

5) Outstanding Votes

except the new ones, none.

phew.

(except on things which have been vetoed already)

also, thanks to Tedd for providing me with a voting summary the other day :)

6) Date of Next

Soryr, mildly distracted yet here. 4a) +1, it seems clearer.

Looks like my reading of dwd's counterargument disagrees with dwd, then.

+1w wfm

likely; however, I might get a thing in which will make me unable to chair, again ✏

for that case, it’d be good to have a contigency plan

> +1w wfm 👍

+1W WFM

+1w wfm

of course, you’ll get an agenda ahead of time :)

no takers?

Ok

thanks

7) AOB

None here

I've got nothing.

me neither

jonas’: any news on the IM-NG-WG?

I sent an email, didn’t I?

so far, only people who did *not* volunteer to contribute last week replied to me ;)

I can confirm that you did

*hint hint*

jonas’: I assumed that participation from me and Daniel is automatically implied?

Ge0rG, saying so on-list would be good, since I actively avoided to name any names.

But maybe it would be a good thing to write down the corner cases that I have in my collection of weird issues.

that, too

as I said in the email, I’ll work out details / scheduling at the end of the week to give interested parties some time to announce their interest

any other AOB?

taking this as a "no"

and with that:

8) Ite Meeting Est

thanks all, thanks tedd

Thanks jonas’, Tedd, and everyone!

jonas’: done

somebody might want to translate that into an agenda on the wiki

Ge0rG, go ahead ;)

somebody *else*

I'm out for today.

Ge0rG> As I read the new text, it doesn't address Dave's remark about clarifying what a sending entity is expected to do. I think it does, but I am happy to add clarifications if something is missing

Ge0rG, the new text includes "Note that as per &xep0004; the form field "type" attribute may be omitted in data forms of type "submit", anything you miss in particular?

flow: I'm referring to > I *think* we ought to be saying SHOULD send type="hidden" on submit, but MUST NOT require it when processing a submission. ✏

"may be omitted" is not a recommendation.

ahh, I do not think that it is sensible to recommend adding type='hidden' on submit to ver='FORM_TYPE' fields: the 'ver' attribute is already unique within the data form, and xep4 already says that you do not need to explicitly state the type in 'submit' forms

hence recommending adding an explicit form field type declaration only for FORM_TYPE feels like special casing, which you usually want to avoid, for no gain

Usually if you submit a form, the receiver already knows the type of the field, so it would be redundant.

Zash, ha, that brings me to the next question: are form fields registered by their field name only, or, by their name and their including form FORM_TYPE ✏

I think it is field name + FORM_TYPE, but I am not sure if this is spelled out somewhere in the xeps

That sounds sensible.

I.e. it's like xmlns and tag name, the touple is the identity of the thing.

right, but then on a very philosophical layer, so please ignore the following, one could argue that the receiving entity does not know if the FORM_TYPE field it looks at, is the FORM_TYPE field

Zash, yep, I also noticed that this is and should be akin to xmlns and element name

Which is really weird and different syntax.

Ge0rG, sure. It's like a limited XML-in-XML thing.

also some things break if you give them multiple dataforms

Like in disco?

yeah

Their bug then.

right, i just recently squashed a few of the buggy "that stanza surely has only one data form" assumption sites in smack