XMPP Council - 2020-07-22

  1. daniel


  2. eta

    hi daniel :p

  3. vanitasvitae


  4. flow


  5. eta

    oh is there a meeting

  6. eta


  7. flow

    we are about to find out :)

  8. Zash

    dun dun duuuuuun

  9. Ge0rG

    good morning

  10. flow

    let's see who of council is missing? jonas’ dwd

  11. flow

    ahh, a wild Ge0rG awakes

  12. Ge0rG

    I've heard jonas’ is on holiday, and I'm still in a phone conference.

  13. daniel

    he is on holiday but didn’t mention that in the agenda he sent yestarday?

  14. flow

    and is see a "+1w wfm" from him in the backlog

  15. daniel

    I can chair but with only Zash and me being here that's going to be a boring meeting anyway

  16. jonas’


  17. jonas’


  18. jonas’

    as promised, I got totally thrown off in my schedule by vacation

  19. jonas’

    sorry for the delayed start

  20. jonas’

    1) Roll Call

  21. Zash

  22. jonas’

    re-pinging daniel, Zash, and Ge0rG

  23. daniel

    i'm still here

  24. Ge0rG is still not quite here

  25. jonas’


  26. jonas’

    2) Agenda Bashing

  27. Zash

    I got thrown off by my vacation ending

  28. jonas’

    any modifications?

  29. daniel

    none here

  30. Zash


  31. jonas’

    3) Editor’s Update - Advanced XEP-0338 to Draft

  32. jonas’

    4) Items for voting

  33. jonas’

    4a) PR#971 vs. PR#972 URL: https://github.com/xsf/xeps/pull/971 URL: https://github.com/xsf/xeps/pull/972 Summary: The first one is truly an (editorial) clarification (AFAICT), the second one is a normative change to the presence of type fields in certain form types.

  34. jonas’

    technically, we probably need to vote on each one individually, but we should discuss them together

  35. jonas’

    note that XEP-0004 is final

  36. Zash

    I agree with the comment about "clarify"

  37. jonas’

    I am firmly against changing normative wording in '4 (a final spec), especially when there’s evidence that implementations already do what the change would forbid.

  38. daniel

    if we were talking about an experimental XEP i'd find 972 to be the better, more explicit option

  39. jonas’

    I agree with daniel

  40. daniel

    but we aren't

  41. jonas’

    does anyone want to discuss anything else before I start the votes?

  42. Zash

    Does flow wanna explain the rationale behind changing normative language?

  43. jonas’

    there was some discussion about that in https://logs.xmpp.org/xsf/2020-07-21#2020-07-21-5b9e98899766b145 ++

  44. flow

    Zash, sure, which change to you refer to?

  45. Zash

    972, the one where jonas’ notes that it changes MUSTs and such

  46. jonas’

    flow, why not all of them, given that this is a Final spec.

  47. jonas’

    but the most crucial one (which goes beyond clarification) would be the change for type="form" from SHOULD to MUST for @type

  48. jonas’

    but the most crucial one (which goes beyond clarification) would be the change for type="form" from SHOULD to MUST for field@type

  49. jonas’

    (for me anyways)

  50. flow

    well, if you believe that 'form' type form fields must always have had field type annotations, then the change from SHOULD to MUST is not really a change in the spec

  51. flow

    it's merly a clarification

  52. flow

    (field type annotations for fields other than text-single that is)

  53. jonas’

    flow, so you’re trying to second-guess the intentions of the original authors?

  54. flow

    reading a spec, you always "guess" the intentions of authors

  55. jonas’

    the intent of using RFC 2119 language is to reduce the guessing

  56. jonas’

    I think you need a pretty strong argument beyond "it might’ve been the intention" when changing RFC 2119 language in a Final spec.

  57. flow

    if your reading is different than mine, then yes, this means that it was previously allowed that fields other than text-single in 'form' type forms come without type annotation

  58. flow

    and now is no longer

  59. jonas’

    I fail to see how this is a matter of reading. It is 100% clear that there is a SHOULD and not a MUST.

  60. jonas’

    there is no ambiguity in the language I can see here. Yes, it is unfortunate that omission of the field@type is allowed, but that’s the text-as-written and it wasn’t caught in either the CFE or the LC leading up to the XEPs Final state.

  61. jonas’

    I don’t see any wiggle-room to interpret this text by itself so that `MUST` was intended.

  62. jonas’

    the only way to justify the replacement based on an "intention" argument would be to get input from the original authors, but *even then* I don’t think that we should change a Final spec when we can very easily see opposite behaviour.

  63. Zash

    SHOULD is still pretty strong

  64. flow

    Zash, not sure if "pretty strong" is any better than, "may or may be not annotated"

  65. MattJ

    Not sure of the context, but indeed 'SHOULD' is more or less equivalent if you're a consumer of the protocol

  66. jonas’

    equivalent to what?

  67. MattJ

    'MUST', sorry

  68. jonas’

    MattJ, for your context: https://github.com/xsf/xeps/pull/972/files vs. https://github.com/xsf/xeps/pull/971/files

  69. jonas’

    anyways, we spent 1/3 of the normal meeting timeframe on this.

  70. jonas’

    I’ll call for votes now, if you see further need for discussion, please take it to the list

  71. jonas’

    I’m going to start with the (probably) simpler one. Noting that if council accepts both PRs, the Editor will ask for a way to resolve the resulting conflict.

  72. jonas’

    4a I) PR#972: XEP-0004: Clarify that 'result' forms must have explicit field types

  73. Zash


  74. flow

    I think this distracts from the real motivation of the PR: should 'submit' type forms require type annotations? I'd like to hear the opinion of the council members (and others of course)

  75. jonas’

    I am -1 on PR#972, because it changes a strongly-worded RFC 2119 business rule without sufficient rationale and while evidence of behaviour, which would then be non-compliant, exists.

  76. jonas’

    flow, we can discuss this in AOB if you like

  77. daniel was briefly confused by the change of order

  78. daniel


  79. flow

    I think this distracts from the real motivation of the PR: should 'result' type forms require type annotations? I'd like to hear the opinion of the council members (and others of course)

  80. jonas’

    daniel, rationale?

  81. daniel

    not significant enough to change the normative language of a final xep

  82. jonas’

    daniel, thanks

  83. jonas’

    4a II) PR#971: XEP-0004: Clarify field type omission for 'submit' and 'result' form field types

  84. jonas’

    I think I’m going to be on-list for that one, since I can’t read the diff well and I need to do this closely.

  85. Zash

    also on-list

  86. daniel

    on list

  87. Zash fiddles with xep-to-markdown convertsion, in order to get a nicer comparison

  88. jonas’


  89. jonas’

    4b) PR#969: XEP-0045 v1.33.0 URL: https://github.com/xsf/xeps/pull/969 Abstract: Clarify that the 307 status code should not be used alongside 333 for user disconnects (re-do of PR#926) See-Also: https://github.com/xsf/xeps/pull/926

  90. Zash

    Mmmm, an interdiff would be nice

  91. jonas’

    note that the diff between #926 and #969 is only s/recommended/advisable/ in that one line

  92. jonas’

    I am +1 on that one

  93. Zash


  94. daniel


  95. jonas’


  96. jonas’

    5) Pending Votes

  97. jonas’

    dwd has some

  98. jonas’

    6) Date of Next

  99. jonas’

    +1w wfm

  100. jonas’

    (this time, no vacation, so I’m less likely to forget :))

  101. daniel

    +1w wfm

  102. Zash

    +1w wfm

  103. jonas’


  104. jonas’

    7) AOB

  105. jonas’

    flow has some, maybe

  106. jonas’

    but first I’d like to ask daniel and Zash if they’re ok with extending by at least 5 minutes to make up for my lateness, or longer if we need to

  107. flow

    well as #972 is rejected, I assume that nobody wants the requirement that 'result' forms have to carry type annotations

  108. flow

    which comes not unexpected, I think I wrote somewhere that I too fear that the ship has sailed

  109. Zash

    Sure, but no promises of being fully awake.

  110. jonas’

    flow, I don’t want the requirement for type='form'

  111. jonas’

    because it’s clearly written as being SHOULD

  112. jonas’

    have to read up on type='result'

  113. flow

    I hear you, and that appears to the the actualy discussion

  114. flow

    which is suprising to me, because I believe that this would be consens

  115. flow

    and that this is the intention of the text currently written, although I also see that it could be interpreted otherwhise

  116. flow

    and that this is the intention of the text currently written, although I also see that it could be interpreted otherwise

  117. jonas’

    ok, so, for type='result', it is currently a MAY

  118. flow

    For data forms of type "form", each <field/> element SHOULD possess a 'type' attribute that defines the data "type" of the field data (if no 'type' is specified, the default is "text-single");

  119. jonas’

    raising that to a MUST would at least cause issues for new implementations

  120. flow

    that is the sentence in question

  121. jonas’

    raising that to a MUST would at least cause issues for new receiving implementations

  122. jonas’

    flow, not ßquite, the important part for type='result' is missing: > […]; fields provided in the context of other forms types MAY possess a 'type' attribute as well.

  123. Zash

    In general, if you are confident that the receiver of the form, regardless of type, knows the "schema", then including that metadata seems redundant, and thus okay to leave out.

  124. jonas’

    (I’m more on the line of "keep it there always" because it’s easier to do validation then, but ok)

  125. flow

    jonas’, right, let's focus on 'form' type form and if their fields are required to have type annotations

  126. jonas’

    flow, you were asking about 'result' earlier tho

  127. jonas’

    which is it?

  128. flow

    as I wrote, the ship has sailed now that #972 was vetoed

  129. jonas’

    because for 'form' I think the matter is 100% clear that they SHOULD have annotations, which is not a MUST, nor a MAY

  130. jonas’

    but #972 was vetoed (from my side) because of 'form', not anything else

  131. flow

    sorry, I meant #971

  132. jonas’

    #971 wasn’t vetoed

  133. jonas’

    everyone is on-list about #971

  134. jonas’

    but I note that I didn’t get any feedback from either Zash or daniel about extending the meeting, so I’m going to close now; we can continue discussion in xsf@ or on-list

  135. jonas’

    8) Ite meeting est

  136. jonas’

    Thanks everyone, and sorry for being late. Next time when I’m on vacation, I’ll try to set up an alarm clock.

  137. Zash