XMPP Council - 2019-08-28


  1. Kev

    Migraine, so very likely not about this afternoon.

  2. Ge0rG

    Looks like I'll be in a train station at meeting time today, only equipped with my phone.

  3. jonas’

    .

  4. dwd

    Afternoon. This doesn't look promising, then.

  5. Ge0rG

    I'd still like a meeting to happen, even if only for the sake of having a real meeting after two misses

  6. pep.

    Link Mauve has been serverless for a few days. He might show up under a jabberfr jid, or not.

  7. Ge0rG

    Also my AOBs are still largely unresolved. I'm thinking of making message errors a first class citizen, and of The Right Way to reference messages.

  8. Ge0rG

    pep.: maybe we need to send a push notification?

  9. dwd

    OK, we'll give it a shot.

  10. dwd

    1) Roll Call

  11. pep.

    Ge0rG: he doesn't run android nor iOS

  12. jonas’

    I’m here

  13. Ge0rG

    pep.: send a direct message to his jabberfr JID please.

  14. pep.

    (Nor any other OS that provides this kind of things, I assume. I'm gone now)

  15. dwd

    OK, we have three, so that counts for Quorum purposes.

  16. Ge0rG is there, more or less

  17. pep.

    I poked him.

  18. dwd

    So we can hold a meeting if we want. Do we want?

  19. Ge0rG

    dwd: are there any new things to vote on?

  20. dwd

    Well, let's:

  21. dwd

    2) AGenda Bashing

  22. Ge0rG

    The agenda is great!

  23. dwd

    I didn't get to an agenda this week, sorry. I'm also unaware of anything in particular, though I believe there was soething in Last Call which has - presumably - become due for a vote.

  24. jonas’

    yeah

  25. jonas’

    no feedback though

  26. Ge0rG

    Didn't we have something regarding jingle?

  27. jonas’

    XEP-0300 and XEP-0353

  28. Ge0rG

    In LC, that is

  29. jonas’

    yes, Jnigle Message Initiation (XEP-0353)

  30. Ge0rG

    Was that the one where we requested feedback from the informal Jingle SIG?

  31. Ge0rG

    jonas’: I had feedback on Table 1 in 0300

  32. Ge0rG

    I'm not sure if that went to standards, though

  33. jonas’

    other than that, I’m not aware of anything to vote on

  34. dwd

    OK, so yes, indeed, both those Last Calls are long-since expired. We can do a vote on both.

  35. dwd

    3) Current Activity

  36. dwd

    I don't think we've anything currently in Last Call or anything? I did notice a bunch of updated XEPs though.

  37. mathieui

    link mauve is coming, fyi, I pinged him by sms

  38. dwd

    jonas’, Anything of note here?

  39. jonas’

    the official release of that new XEP

  40. jonas’

    XEP-0421

  41. jonas’

    XEP-0421: Anonymous unique occupant identifiers for MUCs

  42. linkmauve

    Sorry I'm late!

  43. jonas’

    and obsoletion of the '18 compliance suites

  44. dwd

    Right, thanks.

  45. dwd

    4) Items for a vote.

  46. dwd

    a) XEP-0300 to DRAFT

  47. Ge0rG

    On list

  48. jonas’

    I think I’m +1

  49. dwd

    I think I'm +1 here.

  50. jonas’

    unless Ge0rG tells me a good reason not to be with his Table 1 feedback ;)

  51. Ge0rG

    jonas’: I think that table doesn't belong into 0300, but into an informational XEP or a registry

  52. dwd

    Ge0rG, I think the ideal solution would be to go register the names with IANA, actually.

  53. jonas’

    Ge0rG, one could infer that table to refer to the registry which belongs to that xep

  54. Ge0rG

    dwd: wasn't the reason for that table that IANA isn't there yet?

  55. Ge0rG

    I'm not sure whether that table is subject to change, ever

  56. dwd

    Ge0rG, No, I think it was pure expediency.

  57. Ge0rG

    If it's guaranteed to remain as is, I'm +1 on the XEP.

  58. dwd

    linkmauve, Got a vote for us?

  59. jonas’

    IANA has this: https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml getting something in there seems.... tricky

  60. jonas’

    requires an RFC updating 3279

  61. linkmauve

    I haven't reviewed the latest version of 0300, I'll be on list.

  62. dwd

    That'll be why we went for expediency.

  63. dwd

    Moving on:

  64. dwd

    b) XEP-0353 to DRAFT

  65. Ge0rG

    On list

  66. jonas’

    on-list with default to -0

  67. dwd

    I'm +1 for this. Seems widely deployed and sensible.

  68. Ge0rG

    jonas’: is there a specific reason for that default?

  69. jonas’

    Ge0rG, there was no feedback on-list and I have no idea about jingle.

  70. linkmauve

    Sorry, I'm not used to phone keyboards.

  71. Ge0rG

    I need to review it for MAM and Carbons side effects

  72. jonas’

    I don’t think that me reviewing it will give me anything which helps me decide

  73. jonas’

    dwd, widely deployed? I would’ve expected feedback in the month this has been in LC then.

  74. dwd

    jonas’, Well, that's a matter of low energy and engagement.

  75. Ge0rG

    Even a short message about it being widely deployed

  76. Ge0rG

    XMPP Low Energy.

  77. dwd

    linkmauve, Any vote/opinion?

  78. linkmauve

    0353 I'm on list too with a default of +1.

  79. jonas’

    I’ll send a mail about that to the list.

  80. dwd

    OK.

  81. dwd

    5) Outstanding votes

  82. dwd

    I think the previous ones have all now expired.

  83. Ge0rG

    Yes

  84. dwd

    6) Next Meeting

  85. dwd

    +1W?

  86. jonas’

    wfm

  87. Ge0rG

    +1W looks good on my calendar

  88. linkmauve

    Wait I have an aob.

  89. dwd

    linkmauve, Hang on.

  90. dwd

    It's not AOB yet.

  91. dwd

    7) AOB

  92. linkmauve

    About message retraction.

  93. dwd

    linkmauve, Uh-oh. Do tell.

  94. linkmauve

    Multiple people noticed that the previous council forgot about it.

  95. linkmauve

    It has the same issues as reactions though.

  96. dwd

    :-(

  97. pep.

    Yeah, Ge0rG jokingly commented on that in xsf@

  98. pep.

    (Or maybe it was serious? :p)

  99. linkmauve

    As in, message attachment is blocking it.

  100. dwd

    I agree it's all an interesting mesh of issues. I'm not sure it's something for Council to do much with beyond evaluating a proposal.

  101. Ge0rG

    dwd: what's the alternative for Council, then? Just reject everything with references, until someone comes up with The Right Way?

  102. linkmauve

    Oh, my connection will drop in a few minutes, I'm in the U-Bahn.

  103. dwd

    Ge0rG, Well, individuals on Council can propose something of course.

  104. pep.

    If I may, from the floor, I would very much like to get these accepted before we figure out the answer to the ultimate question [..]

  105. Ge0rG

    dwd: I think this is something where multiple council members might combine efforts to move things forward

  106. dwd

    Ge0rG, Well, sure, but it really doesn't have to be council members, is what I'm saying.

  107. Ge0rG

    Somebody over in xsf@ even questioned the authority of Council members to reject a proto XEP on those grounds.

  108. jonas’

    it is duplicating existing protocol

  109. jonas’

    (in theory that would be an applicable reason)

  110. jonas’

    I tend to agree with the general sentiment

  111. Ge0rG

    dwd: yes, but currently there are some proposals (and their authors) blocked on this issue

  112. jonas’

    can we reach out to the client devs who are invested in this and work closely with them to figure out a solution?

  113. jonas’

    I mean they need to be on board anyways

  114. dwd

    jonas’, Definitely. It'd be nice to get a bunch of them to agree on a solution. Maybe if they discussed it on a mailing list or a chatroom and proposed a XEP.

  115. jonas’

    that’d be ideal

  116. dwd

    jonas’, Do we have a mailing list or a chatroom people could use?

  117. jonas’

    and also get some of them to apply for council next term

  118. jonas’

    dwd, I’m not sure if you’re being rhetorical here

  119. pep.

    Standards@? jdev@?

  120. Ge0rG

    I can only imagine that somebody who just got their first XEP rejected on formal grounds might not be very inclined to do the work required to resolve those formal issues

  121. jonas’

    xsf@ even

  122. pep.

    Or that

  123. dwd

    jonas’, Either rhetorical or sarcastic. It's hard for even me to tell these days.

  124. Ge0rG

    The <s> tag stands for "serious".

  125. Ge0rG

    Can I summarize this debate as "we have agreed to keep everything as is"?

  126. jonas’

    I’ll reach out to them

  127. dwd

    Ge0rG, For what it's worth, I wanted to accept the Reactions one.

  128. linkmauve

    It's not that much of a formal issue, but a factoring issue.

  129. dwd

    Anyway.

  130. dwd

    We're over time - anyone got anything to add before I close?

  131. jonas’

    not me

  132. dwd

    8) Ite, Meeting Est

  133. Ge0rG

    please on-list your opinion regarding message errors.

  134. dwd

    Ge0rG, You'll need to remind me on the details - was it broadcast in Carbons, etc?

  135. dwd

    Ge0rG, Only, I've got a use-case for sending them through MUC, now.

  136. Ge0rG

    dwd: it was about that, yes. Also about putting errors into MAM and offline storage

  137. Ge0rG

    I'm worried about the side effects of carbonated message errors on protocols I'm not aware of.

  138. dwd

    Ge0rG, Right. So my problem is to do with sending messages with out of band media, and wanting to clearly indicate to the sender if downloading the media failed.

  139. Ge0rG

    For MUC errors, Carbon-copying is certainly problematic

  140. dwd

    Ge0rG, No, not MUC errors, errors from messages passing through MUC. The current implementations would simply boot the user who sent the error.

  141. Ge0rG

    dwd: yes, that's a different issue

  142. dwd

    Ge0rG, Yes, but I think it's related.

  143. Ge0rG

    dwd: I'm not very sure about that.

  144. dwd

    Ge0rG, In as much as most entities are bad about generating and handling errors, and that's in part because of our stipulated handling.

  145. Ge0rG

    dwd: yes, but we are speaking of two orthogonal problems with the stipulated handling.

  146. Ge0rG

    maybe occupants should send errors and receipts via PM anyway?

  147. dwd

    Ge0rG, Absolutely. Same area, distinct issues.

  148. dwd

    Ge0rG, That's an interesting suggestion.

  149. Ge0rG

    dwd: obviously not good for read markers, because somebody thought it's fancy to keep track of who read how much of what, individually.

  150. dwd

    Ge0rG, Yes... It's quite a way to amplify traffic though.

  151. Ge0rG

    I wonder if you can trigger read-markers with empty messages.

  152. Ge0rG

    But then again, DoS on XMPP clients is as challenging as taking away candy from children.

  153. dwd

    Ge0rG, True. It's not about DoS, just efficiency.

  154. Ge0rG

    dwd: sending a MUC-PM error is perfectly fine, unless PMs are forbidden by the MUC

  155. dwd

    Ge0rG, Do those go through?

  156. Ge0rG

    I _think_ so

  157. dwd

    Ge0rG, I think they'd appear to be normal bounces (similar to a delivery failure) and thus kick the offending client.

  158. Ge0rG

    Let's test.

  159. Ge0rG

    dwd: I just sent you a message error PM. I hope

  160. dwd

    [16:56:51] ‎Ge0rG‎: Let's test. ‎[17:00:52] ‎message ―――――――――――――――――――― ‎[17:01:03] ‎Ge0rG‎: dwd: I just sent you a message error PM. I hope

  161. dwd

    That's... Interesting.

  162. Ge0rG

    <message to="council@muc.xmpp.org/dwd" type="error"><error type="cancel"><not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>This is a severe error.</text></error></message>

  163. Ge0rG

    I wasn't kicked by either MUC or server.

  164. Ge0rG

    dwd: what client was that, btw?

  165. Ge0rG

    Error> council@muc.xmpp.org/Ge0rG: cancel: This is a severe error. ...is what I get on self-PM

  166. dwd

    Gajim.

  167. Ge0rG

    Somebody with a faster uplink should add PMs to https://wiki.xmpp.org/web/index.php?title=Client_Test_Cases