jonas’Kev, IIRC, you wanted amendments to https://github.com/xsf/xeps/pull/784, can you please confirm that the changes Ge0rG made are okay with you?
jonas’Kev, and the same for https://github.com/xsf/xeps/pull/778
Ge0rGis semi present
dwd1) Roll Call.
jonas’Link Mauve ?
Link MauveHi, I’m here.
dwdI see Georg's partial presence.
dwd2) Agenda Bashing
jonas’board wants us to talk about https://github.com/xsf/xeps/pull/780
KevWas there an agenda?
dwdThere was not. So, Kev, you remember that nice little Yaris I used to have before it got hit by an HGV yesterday? Well, something happened to it, see if you can guess why I got distracted. :-/
KevYou driving? Ok?
dwdMy son driving - actually not so much driving, sicne the handbrake was on. No injuries, walking pace collision, but the car has received substantial unexpected remodelling.
jonas’oh dear, thank $deity
dwdBut anyway, that's my exciting news. Given the cheapness of my cars, it's probably an insurance write-off.
dwdSo - #780 - anything else?
jonas’not that I knew
Guus(that's the same son that is a pilot?)
Ge0rGThat AOB discussion from two weeks ago? I tried to remind the List, but it failed similarly to what Kev attempted
dwdGuus, Yes. Better a minor car crash than a minor aircraft crash. :-)
jonas’Ge0rG, what was the AOB again?
dwd3) Items Not For A Vote:
dwda) https://github.com/xsf/xeps/pull/780 (Editorial changes and XEP state)
jonas’I am +1 on that one for obvious reasons
Ge0rGWhy are you +1 if it's not for a vote?
jonas’I’m not sure if it’s for a vote or not, and this expresses my intent unambigiuously either way :)
KevMy comment still stands that we have a definition based on versioning here already, and making that clearer would be good. Instead of the suggested wording.
dwdSeve's point is interesting. Are you intending to mean that if a XEP has a substantial edit in (say) April, and a series of edits considered Editorial subsequently, it would still be moved to Deferred in October?
jonas’Kev, I’m still not sure we do, technically
Kevjonas’: XEP-0001 is only concerned with substantive edits (x.y), not the x.y.z versions we use for editorial stuff.
KevI'd rather we codified the use of x.y.z in XEP-0001 for Editorial changes.
jonas’that’s what I meant by ". So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff."
Kevdwd: Believe it or not, based on the versioning requirements, that's what XEP-0001 already says.
jonas’that’s what I meant by "So to be able to refer to that, we’d have to go ahead and write that down clearly. Which I’m not opposed to, in general, but time and stuff."
jonas’if you folks think that needs more explanation and should be made clearer, I can put it on my todo to write that down
dwdKev, I believe you. But Seve's point is that the way that reads is that you can make a substantial edit to a document which causes it to be deferred.
jonas’an edit can never cause a document to be deferred
Link MauveYeah, removing the “or to” part would seem sensible.
dwdjonas’, I think I lean toward defining versions properly and unequivocally, and then I think this particular change/clarification falls out of that automatically.
jonas’so I’ll go ahead and do that
dwdLink Mauve, Except an editorial change is intended to leave the move *to* Deferred unaffected, so ...
dwdjonas’, Sorry for making more work for you.
jonas’I have been thinking about that one anyways
Ge0rGThat phrasing is not perfect, I agree with Seve
jonas’and yeah, that phrase is a weak spot in the diff
jonas’will fix both
Link Mauvedwd, “[…] for the purpose of considering moving a XEP back from Deferred state, or keep it there.” maybe?
dwdLink Mauve, As I say, once you define versioning clearly, I don't think it matters anymore.
jonas’I think it’s more effective when I draft up an alternative wording and we discuss it
Link Mauvejonas’, agreed.
dwdb) That AOB That Georg Raised A Few Weeks Back.
jonas’Ge0rG, what was it even about?
Ge0rG> Purely editorial changes (e.g. version updates from 0.1.1 to 0.1.2) count as <em>activity</em> (or <em>updates</em>) do not effect the Deferred state or deferral time of an XEP.
Ge0rGit was about fixing 0184 properly
jonas’wasn’t that last week?
jonas’apparently not, and also it doesn’t matter
Ge0rGthe other AOB was asking Link Mauve to explain how to do MUC-0313 without exposing a DoS vector
dwdGe0rG, Which first?
Ge0rGdwd: in that order please
dwdGe0rG, OK. 5 minutes on each then.
dwdb) Fixing XEP-0184 properly.
Link MauveGe0rG, I have never implemented 0313 in a server, I’m sure there are many better people than me for that.
Ge0rGThat message-type info box in 0184 is a fig-leaf, and Kev asked to do it right in one of the last Council Meetings. Do we want to fix it properly?
jonas’I’m all in for fixing things properly
jonas’but we need to do it without a namespace bump, because there are other things we should include when we bump 184
dwdI'm in favour of fixing things properly as a general rule. What do real implementations actually do?
Ge0rGhow far can I go with "fixing" it without you requiring a version bump?
Ge0rGdwd: it varies wildly
Ge0rGsome reflect message type, others send normal. Some send to full JID, others to bare JID
dwdGe0rG, You bump a namespace when to implementations using the same namespace would fail to interoperate (or, indeed, already do).
jonas’Ge0rG, I’d say we specify that clients SHOULD send the same type, but MUST accept different types, too.
Ge0rGdwd: the XEP does not mention message types.
jonas’mention why it makes sense to have that (archive stuff)
Ge0rG(except when treating MUCs)
dwdGe0rG, I have noticed that some (COnverse, perhaps?) only handle receipts in type='chat'. I'd thought receipts were meant to be in type='normal' myself.
Ge0rGdwd: "were meant to" is your reading of the XEP or some background knowledge?
Ge0rGtype=normal + no body leads to them being ephemeral for MAM and Carbons.
Link MauveGe0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.
Ge0rGLink Mauve: please wait for AOB c.
dwdGe0rG, I read the XEP and implemented my end, and it failed. But Example 4, for example, shows a normal message.
Ge0rGdwd: no, it shows a message with default message type.
jonas’which is type normal
Ge0rGI claim that this is an oversight of the XEP author and not a deliberate design decision.
Ge0rGAnd it's not normative in any case.
dwdGe0rG, So what does "fixed" look like? Same type? I personally think that 1:1 receipts ought to be in type='normal', and not type='chat' (since they're not chat messages). But I'm not wed to that idea.
Ge0rGdwd: the pseudo-quote block in https://mail.jabber.org/pipermail/standards/2019-April/036090.html
jonas’The receiving client should consider the following when generating a
Receipt, depending on the message type of the message that contained
the Receipt Request:
- "chat", "normal": the Receipt message SHOULD have the same @type as
the Request message.
- "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A
client choosing to respond despite of this SHOULD send the Receipt
with type="groupchat" to the bare JID of the room and not to the full
JID of the sender. It MAY be useful to limit this feature to private
MUCs with a small number of participants, or to instead send the
Receipt as a MUC-PM.
- "headline": the Receipt message SHOULD have type="normal".
- "error": this should not actually be possible, so the client SHOULD
NOT (MUST NOT) respond.
A client MUST be able to Process a Receipt message with a different type
than the original Receipt Request message.
jonas’(quoting from Ge0rGs mail)
Ge0rGThis is strawman wording, not carved in stone.
jonas’I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule
dwdOK, so it's not clear to me that this is a bad set of words. I'd be happy to see that as a PR and we can vote on it.
jonas’I think that’s sane, with the exception of the "headline" rule; I have no opinion on the "headline" rule due to lack of data
Ge0rGI wanted to initiate a discussion, specifically about _how_ to treat each of those, and whether this would be a ns-bumping change
dwdGe0rG, I think it's compatible with the existing XEP, and can only improve interop, so seems OK to me without a bump.
Ge0rGMaybe what dwd said is the more sensible strategy: have all receipts be type=normal and rather fix MAM and Carbons
Ge0rGI think we can all agree that a type=headline receipt doesn't make sense.
dwdWe're running over on the 5-minute slot here, though - I'll dig out that email and reply to it with some comments.
jonas’for some reason that mail was marked as read so I totally forgot about it
Ge0rGdwd: awesome. I can't promise any activity in the next three weeks though.
dwdc) XEP-0308 (Last Message Correction) in MUC
jonas’Link Mauve, your slot
jonas’I guess this is in context of https://github.com/xsf/xeps/pull/736
Ge0rGLink Mauve: the PR was rejected because everybody was wondering how you are going to combine limited back-history with strong guarantees
jonas’quoting Link Mauve from above:
15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server,
I’ll raise the change again once I have gathered enough
information to answer your question.
jonas’quoting Link Mauve from above:
15:22:43 Link Mauve> Ge0rG, re MUC-0308, I have started a draft module for a server, I’ll raise the change again once I have gathered enough information to answer your question.
jonas’i guess we can defer the discussion based on that?
Link MauveIndeed, that’d be my preferred course of action.
Ge0rGI wanted to clarify the issue, but it's in the Council logs as well, obviously.