-
waffles417
can soeone help me set up my pidgon?
-
waffles417
someone*
-
waffles417
intosi
-
intosi
I see I missed the opportunity to handle a user support ticket for Pidgin.
-
edhelas
hi folkds
-
edhelas
so i'm working on XEP-402 implementation
-
edhelas
with a small extension for Movim
-
edhelas
<notifications xmlns="urn:movim:notifications:0" notify="all"/>
-
edhelas
i 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)
-
Holger
Oh it was renamed.
-
jonas’
what was?
-
Holger
0402
-
Holger
This was Bookmarks 2, no?
-
eta
yeah
-
Holger
Ah, 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?
-
MattJ
No, fixed
-
MattJ
I hadn't noticed it was draft, not used to that workflow :)
-
Link Mauve
edhelas, don’t use urn:movim, it isn’t a registered URN name.
-
edhelas
ah :p what should I use then ?
-
MattJ
This should be an FAQ somewhere
-
Link Mauve
I use xmpp:linkmauve.fr/feature-foo, but you can use any URI you’re in control of.
-
Link Mauve
HTTP is a popular one.
-
Kev
HTTPS, please. More secure.
- Kev ducks
-
MattJ
or urn:uuid:!
-
Link Mauve
:3
-
jonas’
MattJ, can you change the revision block to a more recent date?
-
jonas’
... it’ll save us some trouble.
-
MattJ
Can do, maybe later or possibly tomorrow
-
jonas’
MattJ, ok, ping me
-
flow
how does a s2s "receiving" server know that the initating server supports the dialback "same certificate" shortcut (xep344 § 2.7)?
-
flow
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?
-
flow
and 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.
-
flow
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
-
jonas’
flow, sorry, I was typing that from memory.
-
jonas’
I meant for type="form", not for type="submit"
-
flow
ahh that SHOULD
-
flow
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?
-
flow
I tried to get rid of that ambiguity in the text, but I am not sure how successful I was
-
flow
s/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
-
flow
it'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
-
flow
the 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
-
flow
mine 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?
-
flow
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
-
jonas’
how is that ambiguous?
-
flow
that 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
-
flow
but 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?
-
Zash
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
-
flow
jonas’, that it should have field type annotations unless the field is text-single
-
Zash
I will however assumet that you are as confused as me when looking at that XEP, everything is weird and worded backwards.
-
flow
because text-single is the default, and hence you can elide those
-
flow
Zash, but in the shortcase case there was no db:result by the initating server, nor a db:verify by the receiving one✎ -
flow
Zash, 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
-
flow
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
-
flow
jonas’, 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
-
flow
jonas’, 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.)
-
flow
the "default is text-single" statement is still there
-
flow
which could be probably be more elaborated
-
flow
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
-
flow
but 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
-
flow
does it?
-
jonas’
changes normative language in a Final document? yes.
-
jonas’
that’s never a clarification, period.
-
flow
I assumed there is consensus that 'form' type fields need type annotations for fields other than text-single
-
flow
And if this is true, then I think this is nothing but a clarification