XSF Discussion - 2020-07-21

  1. waffles417

    can soeone help me set up my pidgon?

  2. waffles417


  3. waffles417


  4. intosi

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

  5. edhelas

    hi folkds

  6. edhelas

    so i'm working on XEP-402 implementation

  7. edhelas

    with a small extension for Movim

  8. edhelas

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

  9. edhelas

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

  10. edhelas

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

  11. Holger

    Oh it was renamed.

  12. jonas’

    what was?

  13. Holger


  14. Holger

    This was Bookmarks 2, no?

  15. eta


  16. Holger

    Ah, months ago.

  17. 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.

  18. jonas’

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

  19. MattJ

    No, fixed

  20. MattJ

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

  21. Link Mauve

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

  22. edhelas

    ah :p what should I use then ?

  23. MattJ

    This should be an FAQ somewhere

  24. Link Mauve

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

  25. Link Mauve

    HTTP is a popular one.

  26. Kev

    HTTPS, please. More secure.

  27. Kev ducks

  28. MattJ

    or urn:uuid:!

  29. Link Mauve


  30. jonas’

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

  31. jonas’

    ... it’ll save us some trouble.

  32. MattJ

    Can do, maybe later or possibly tomorrow

  33. jonas’

    MattJ, ok, ping me

  34. flow

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

  35. 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?

  36. flow

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

  37. jonas’

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

  38. 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

  39. jonas’

    flow, sorry, I was typing that from memory.

  40. jonas’

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

  41. flow

    ahh that SHOULD

  42. 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?

  43. flow

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

  44. flow

    s/does it may/does it mean/

  45. jonas’

    flow, can you reformulate the ambiguity?

  46. jonas’

    flow, I think it means both

  47. jonas’

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

  48. flow

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

  49. jonas’

    it does, depending on how strict you read SHOULD

  50. flow

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

  51. jonas’

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

  52. jonas’

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

  53. jonas’

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

  54. flow

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

  55. jonas’

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

  56. 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

  57. jonas’

    how is that ambiguous?

  58. flow

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

  59. jonas’

    yes, that is clear so far

  60. flow

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

  61. jonas’

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

  62. 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

  63. flow

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

  64. Zash

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

  65. flow

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

  66. flow

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

  67. flow

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

  68. jonas’

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

  69. 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

  70. flow

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

  71. jonas’

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

  72. flow

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

  73. jonas’

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

  74. jonas’

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

  75. flow

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

  76. flow

    which could be probably be more elaborated

  77. 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

  78. flow

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

  79. jonas’

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

  80. jonas’

    but that goes beyond a clarification

  81. flow

    does it?

  82. jonas’

    changes normative language in a Final document? yes.

  83. jonas’

    that’s never a clarification, period.

  84. flow

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

  85. flow

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