edhelasi was wondering what other extensions you had in mind when forging the XEP ?
edhelas(this extension will allow Movim users to configure per-room notifications, between none, when quoted and all)
Link Mauvehas joined
Dele Olajidehas left
Dele Olajidehas joined
Steve Killehas left
Steve Killehas joined
HolgerOh it was renamed.
Viktor Lindberghas joined
HolgerThis was Bookmarks 2, no?
HolgerAh, months ago.
eta> 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.
jonas’MattJ, https://github.com/xsf/xeps/pull/922 is that intentionally still Draft?
MattJI hadn't noticed it was draft, not used to that workflow :)
Link Mauveedhelas, don’t use urn:movim, it isn’t a registered URN name.
edhelasah :p what should I use then ?
MattJThis should be an FAQ somewhere
Link MauveI use xmpp:linkmauve.fr/feature-foo, but you can use any URI you’re in control of.
Link MauveHTTP is a popular one.
KevHTTPS, please. More secure.
jonas’MattJ, can you change the revision block to a more recent date?
jonas’... it’ll save us some trouble.
MattJCan do, maybe later or possibly tomorrow
jonas’MattJ, ok, ping me
Steve Killehas left
Steve Killehas joined
flowhow does a s2s "receiving" server know that the initating server supports the dialback "same certificate" shortcut (xep344 § 2.7)?
flowor will the receiving server just tolerate the initating server not taking the shortcut, even though the initating server just received a 'valid' db result?
flowand if so, shouldn't the xep state that?
jonas’flow, note that your description of #972 on the ML is incomplete; it also changes the SHOULD for type="submit" to a MUST.
flowjonas’, 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
jonas’flow, sorry, I was typing that from memory.
jonas’I meant for type="form", not for type="submit"
flowahh that SHOULD
flowthat 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?
flowI tried to get rid of that ambiguity in the text, but I am not sure how successful I was
flows/does it may/does it mean/
jonas’flow, can you reformulate the ambiguity?
jonas’flow, I think it means both
jonas’I’m not sure how the parts to the left and right of your "or" contradict each other
flowit's not really a contradicition, the latter obviouisly allows the former, but the former does not allow the latter
jonas’it does, depending on how strict you read SHOULD
flowthe difference is, with one interpretation text-multi fields always have an 'type' attribute, with the other not
jonas’flow, for as much as things "always" happen with SHOULD (as opposed to MUST)
jonas’my reading is clearly that they SHOULD have the type attribute set
jonas’I don’t see how you can find another, more lax interpretation from the text, but I’d be curious to hear
flowmine too, but that does not mean it's clear to everybody
jonas’but you must’ve had some reason to believe why one might read it differently?
flowSure, 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
jonas’how is that ambiguous?
flowthat sentence allone reads like you could (but you shouldn't) have 'form' type forms without any type annotations, even for text-multi
jonas’yes, that is clear so far
flowbut that is my point, I think this is not what the XEP tries to state (nor what should be the case)
jonas’what do you think it’s trying to state instead?
Zashflow: 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
flowjonas’, that it should have field type annotations unless the field is text-single
ZashI will however assumet that you are as confused as me when looking at that XEP, everything is weird and worded backwards.
flowbecause text-single is the default, and hence you can elide those
flowZash, but in the shortcase case there was no db:result by the initating server, nor a db:verify by the receiving one✎
flowZash, but in the shortcut case there was no db:result by the initating server, nor a db:verify by the receiving one ✏
jonas’flow, right, even so, I don’t think that a MUST is a clarification there, but an outright change
flowjonas’, 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
flowjonas’, as I said, I may not be that successful with my attempt to clarify it
jonas’I fail to see how changing SHOULD -> MUST is a clarification in any world
flowjonas’, but again it is now "MUST possess unless it is text-single"
jonas’and what if it is text-single? that is unclear now
jonas’(while that "@type defaults to 'text-single'" is clear.)
flowthe "default is text-single" statement is still there
flowwhich could be probably be more elaborated
flowjonas’, 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
flowbut I am happy about any suggestions on how to improve the wording
jonas’flow, sure, I’d like to avoid that too
jonas’but that goes beyond a clarification
jonas’changes normative language in a Final document? yes.
jonas’that’s never a clarification, period.
flowI assumed there is consensus that 'form' type fields need type annotations for fields other than text-single
flowAnd if this is true, then I think this is nothing but a clarification