XSF Discussion - 2020-07-21

can soeone help me set up my pidgon?

someone*

intosi

I see I missed the opportunity to handle a user support ticket for Pidgin.

hi folkds

so i'm working on XEP-402 implementation

with a small extension for Movim

<notifications xmlns="urn:movim:notifications:0" notify="all"/>

i was wondering what other extensions you had in mind when forging the XEP ?

(this extension will allow Movim users to configure per-room notifications, between none, when quoted and all)

Oh it was renamed.

what was?

0402

This was Bookmarks 2, no?

yeah

Ah, months ago.

> This specification was originally entitled "Bookmarks 2: This Time It's Serious". Any implication of a sense of humour has been removed with the change in title.

MattJ, https://github.com/xsf/xeps/pull/922 is that intentionally still Draft?

No, fixed

I hadn't noticed it was draft, not used to that workflow :)

edhelas, don’t use urn:movim, it isn’t a registered URN name.

ah :p what should I use then ?

This should be an FAQ somewhere

I use xmpp:linkmauve.fr/feature-foo, but you can use any URI you’re in control of.

HTTP is a popular one.

HTTPS, please. More secure.

or urn:uuid:!

:3

MattJ, can you change the revision block to a more recent date?

... it’ll save us some trouble.

Can do, maybe later or possibly tomorrow

MattJ, ok, ping me

how does a s2s "receiving" server know that the initating server supports the dialback "same certificate" shortcut (xep344 § 2.7)?

or will the receiving server just tolerate the initating server not taking the shortcut, even though the initating server just received a 'valid' db result?

and if so, shouldn't the xep state that?

flow, note that your description of #972 on the ML is incomplete; it also changes the SHOULD for type="submit" to a MUST.

jonas’, I see how one could come to that conclusion, but if I am not mistaken there is no explicit statement about what to do for 'submit' type forms

flow, sorry, I was typing that from memory.

I meant for type="form", not for type="submit"

ahh that SHOULD

that is also ambiguous: does it may 'form' type forms SHOULD contain type annotation unless it's type-single (which is the default), *or*, does it mean that you can send/receive 'form' type forms without any type annotation at all?

I tried to get rid of that ambiguity in the text, but I am not sure how successful I was

s/does it may/does it mean/

flow, can you reformulate the ambiguity?

flow, I think it means both

I’m not sure how the parts to the left and right of your "or" contradict each other

it's not really a contradicition, the latter obviouisly allows the former, but the former does not allow the latter

it does, depending on how strict you read SHOULD

the difference is, with one interpretation text-multi fields always have an 'type' attribute, with the other not

flow, for as much as things "always" happen with SHOULD (as opposed to MUST)

my reading is clearly that they SHOULD have the type attribute set

I don’t see how you can find another, more lax interpretation from the text, but I’d be curious to hear

mine too, but that does not mean it's clear to everybody

but you must’ve had some reason to believe why one might read it differently?

Sure, I read the sentence and found it ambiguous. The sentence is " For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data" without the subordinate clause in the braces

how is that ambiguous?

that sentence allone reads like you could (but you shouldn't) have 'form' type forms without any type annotations, even for text-multi

yes, that is clear so far

but that is my point, I think this is not what the XEP tries to state (nor what should be the case)

what do you think it’s trying to state instead?

flow: re dialback, no need to know that. the verifying server could do the verification any way it wanted, either by doing the actual dialing-back, checking the certificate, or flipping a coin

jonas’, that it should have field type annotations unless the field is text-single

I will however assumet that you are as confused as me when looking at that XEP, everything is weird and worded backwards.

because text-single is the default, and hence you can elide those

Zash, but in the shortcut case there was no db:result by the initating server, nor a db:verify by the receiving one ✏

flow, right, even so, I don’t think that a MUST is a clarification there, but an outright change

jonas’, I somehow assumed that it is consens that 'form' type forms must have field type annotations for all fields that are not text-single. If you think otherwise, then we should clarify this too

jonas’, as I said, I may not be that successful with my attempt to clarify it

I fail to see how changing SHOULD -> MUST is a clarification in any world

jonas’, but again it is now "MUST possess unless it is text-single"

and what if it is text-single? that is unclear now

(while that "@type defaults to 'text-single'" is clear.)

the "default is text-single" statement is still there

which could be probably be more elaborated

jonas’, I think if I would simply s/MUST/SHOULD/ in the diff, then I would actually allow 'form' type fields without no type annotations, even for non text-single fields. And that is something I'd like to avoid

but I am happy about any suggestions on how to improve the wording

flow, sure, I’d like to avoid that too

but that goes beyond a clarification

does it?

changes normative language in a Final document? yes.

that’s never a clarification, period.

I assumed there is consensus that 'form' type fields need type annotations for fields other than text-single

And if this is true, then I think this is nothing but a clarification