[Standards] Re: Remove requirement to send disco#info feature in XEP-0030
>From XEP-0001, regarding Final XEPs, "limited modifications may be made as >long as they are optional, backwards-compatible extensions rather than >modifications to the core protocol itself." XEP-0030 requires that entities return "one or more elements and one or more elements", so the otherwise redundant 'disco#info' feature ensures this will always be the case, even in the (seemingly unlikely) situation where an entity somehow supports disco#info without supporting any additional features. So, is removing the requirement for this feature an optional, backwards-compatible extension? An obvious, and maybe more realistic, retort is "but will it break anything?" So, would it cause problems for implementations if they were to receive a reply containing zero features (since they were originally implemented expecting there will always be at least one)? Equally, would implementations have problems calculating the caps hash (XEP-0115) with zero features (the algorithm doesn't explicitly account for this)? It's also worth considering whether leaving it as-is causes harm. It's nice (desirable, even) to clean things and remove 'warts' like this, and there are likely many more scattered throughout the protocol, so it's worth noting for XMPP 2.0, but this has been the status quo for 22 years without being an issue. As for benefits: many implementations would now be 'correct' for not complaining when the feature isn't present (if implementations don't follow the specification, just change the specification); and there is a minor reduction in data transferred from having one less feature, though that's less notable where XEP-0115 is used (and there may be an initial increase caused by most hashes now being unknown, until that settles.) (Semi-relevant: https://github.com/xsf/xeps/pull/961 ) ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Escape characters in XEP-0393: Message Styling
Hi Werner, This is not specific to the '\' character - any non-whitespace character will have the same effect (e.g. "this text*is not bold* "); as specified in section 6.2: "… The opening styling directive MUST be located at the beginning of the parent block, after a whitespace character, or after a different opening styling directive. …" So there is no styling because the '*' is not immediately after a whitespace character. However, the inclusion of a formal grammar would make implementing a parser easier and help to clarify cases like this. (The reason for escaping with '\' comes from the C language, where it was useful to be able to represent ASCII control characters using printable characters, specifically "\n" to produce a line-feed, plus others; but then comes the need to represent a literal '\' character that is not an escape, and thus "\\" escapes a literal '\'. Escaping characters in the context of human-to-human communication seems less appropriate.) ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
In my imaginary world where all stanzas have UUIDs there would be no need for anyone else to add their own id because every stanza already has a unique id which is suitable for referencing in various archives (and the risk of collisions is acceptably close to zero.) Of course, that depends on trusting that everybody else is both competent and not malicious; while that is true most of the time, we still have to cover for the few times that it's not. So, everyone adds their own id because they can't trust anyone else's ids, though those are still useful for referencing with the entities who added them. We should still aim to limit revealing ids to places where they are relevant, rather than piling multiple ids everywhere just because someone in the chain wanted one for their own purposes. I don't care what id you're using to store messages in your local archive, I could not use that information even if I wanted to, and arguably it's a data leak. If I send a message to the MUC: ... Then I should receive back: ... I can cross-reference with the original message I sent using origin-id (uuid_001) because that is the id I used. I can reference a message in the MUC by using stanza-id (uuid_002) because that is the id the MUC used. If I want to reference a message in my server's archive, I can use message.id (uuid_003) because that is the id my server used; if there is no server archive then stanza-id.id will be the same as message.id (and stanza-id is duplication, but included for simplicity.) And you should receive: ... You can't reference the original message I sent, and there is no legitimate reason you should. To reference a message in the MUC, you can use stanza-id (uuid_002). And to reference a message in your server's archive, use message.id (uuid_004). Each endpoint should add its own new uuid into message.id, since that's the one it recognises for referencing; and stanza-id is added to provide the id used by the original sender (the muc), rather than trying to use the same id in two different places for different purposes. If you like, there is an implicit 'by' on the stanza-id with the value equal to message.from (minus nick.) Is the above something we can move towards, or are there practical reasons that it's not possible/realistic? And is there a need for yet more ids to be exposed to genuinely interested parties? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
I think there may be some confusion and we're not even disagreeing about the same things; so, I'll state my thoughts more clearly. The original sender of a message stanza SHOULD give it id=UUID. Unfortunately, this wasn't a requirement in the RFCs, so now we have various hacks to try to deal with that because we can't just fix the problem while maintaining compatibility. In the case of MUC messages, the original sender IS the MUC, and not the client. The client sends its message to the MUC, and that message SHOULD have its own unique id, but the message which the MUC forwards to participants SHOULD be a new message with its own new unique id. But the client wants to cross-reference the message it sent with the one it receives, and so the MUC SHOULD also insert an origin-id with the client's original message id (only in the message it forwards to that client.) Now, the above SHOULDs are my own preferences for an ideal world where we could have nice things, whereas in reality we maintain compatibility and add 'just one more' id in the hope it solves things. In the above ideal world, MUC message ids can't be spoofed because they are assigned by the MUC itself. The MUC doesn't even need to care what id a client used because it assigns its own new id to any messages it sends - if a client does duplicate one then it only confuses itself in the origin-id (and nobody else sees that.) I understand that is effectively what you're trying to address with stanza-id, and it is a valid solution. What I'm less sure of is the benefit 'by' actually brings in practice. If there are multiple stanza-ids then it obviously serves to differentiate them, but why the need for multiple? The client's id is the origin-id (so it can cross-reference with its archive) and the MUC's id is the stanza-id (so it can be referenced for reactions, etc.) Carbons shouldn't need yet another id. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
> …this is the line of thought that neglects that we are working on a
> federated system where we can not assume that every actor is faithful.
> ID assigned by the sending entity can potentially be observed by another
> malicious actor and be reproduced ("spoofed").
There is nothing stopping me from reproducing your stanza ids elsewhere, but
that causes no problem unless there is interaction with an entity who already
received a stanza with such an id - which it should be checking for anyway,
regardless of 'by' value.
> Referencing messages via such IDs is hence worrisome at best, or simply
> insecure at worst.
Referencing messages by any non-encrypted value (or even message content, for
that matter) is simply insecure; there is no way around that in a publicly
federated network where any hop could potentially alter a message.
> tries to mitigate this by the 'by' attribute, which denotes
> the entity that assigned the ID, for example a MUC. If the MUC behaves
> standard compliant, then it will reject (or at least sanitize) incoming
> messages containing a with a 'by' attribute denoting its
> from the MUC.
Let's assume that every hop appends its own because you can never
fully trust that the previous one wasn't altered - which stanza-id does a
recipient use? The only stanza-id you can reliably trust to be 'real' is the
one you received the stanza from, and so all previous stanza-ids should be
ignored, in which case each hop may as well strip and replace them with its
own. In that case, you already know who the stanza-id is 'by' and it is the
only one.
> Yes, MUCs could also spoof IDs, but at least you only have to trust the
> MUC and not everyone in the federated network to behave nice.
The MUC is the originator of the stanza in this case, so it should assign its
own unique message id. The original sender, who directed the MUC to forward the
message to room participants, will want to match up its sent message with the
one it receives from the MUC - so then it's useful for the MUC to inform (only)
the original sender "this was the id you used when you sent me this message" in
the same forwarded message.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
> > There is a very obvious solution to this which everyone seems to be > > overlooking: we need a new element with a guaranteed unique, non-spoofed > > UUID; should a server feel the need to do bad things, it can set the > > 'spoofed' attribute to true and then clients can act accordingly. > what entity would set that element? the sending client? the server of that > client? the server of the receiving client? It was meant to be a joke about the number of stanza id mechanisms - clearly, the solution is another stanza id mechanism! (I'd hoped the 'spoofed' attribute made it obvious I wasn't serious.) But, being serious: the issue is that both clients and servers need an id for referring to stanzas, and if that id is dependably unique then it solves a number of difficulties; the reason we have problems is that the original RFC-defined 'id' attribute had no such requirements, and so id can't be depended upon. So, if the originator of a stanza (sending client, usually) guarantees that its id is unique (and you also trust that guarantee) then there should be no reason for anyone else to add their own id mechanism - both the client and server can use the id for referencing (servers can still use their own internal ids for indexing and such, but the 'long' id is for all public-facing referencing), and then there's no need for the client to check which id the server gave the stanza (it's the same.) XEP-0359 attempts to do exactly this, but it only works dependably if everyone uses it, and legacy clients don't/can't. If a server does spoof ids for malicious purposes, there is no protection against this (without resorting to cryptographic signatures, which brings its own difficulties) and no amount of additional ids would help (it could spoof those too.) XMPP 2.0 will solve all of these problems, of course. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and
There is a very obvious solution to this which everyone seems to be overlooking: we need a new element with a guaranteed unique, non-spoofed UUID; should a server feel the need to do bad things, it can set the 'spoofed' attribute to true and then clients can act accordingly. Something like: Or in the case of server interference: Simple The informational guidance XEP is a good idea too. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2023
Without trying to delay this, considering the 'already late date'… A few quick fixes: - "A/V Calling" should be added to the list "(Core, Web, IM, and Mobile)" in both the Abstract and Introduction; - 'Changes since …' is nice, but will eventually become longer than the main content; keep the most recent, and put the rest in an appendix. And a few less quick fixes (if only so I can point to them again next year): - most of my comments from the previous year [1] still stand; - once upon a time, there was an idea [2] for moving away from yearly Compliance Suites to 'living documents' (one for current state and another for future); it maybe worth revisiting. [1] https://mail.jabber.org/pipermail/standards/2021-September/038582.html [2] https://mail.jabber.org/pipermail/standards/2019-April/036074.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0444 update: restrict reactions
> The other part this PR tries to address is to specify how clients should > behave when they receive an error in reply to a reactions payload. I > think that without clarification, the clients should "revert to the > previous reaction state", but I proposed to make "empty my reactions for > this message". Any feedback about this? Removing all reactions just because a user unwittingly adds one too many seems like a bad experience; rejecting the extra(s) makes the most sense. A user then has the option of deciding whether the new reaction is important enough to warrant removing any (and which) of their previous reactions to fit it in. 0444 already provides a way to remove all reactions (send an empty 'reactions' element), so clients should already be able to do that if necessary. The obvious omission is removing an individual reaction (where there are multiple), though this can be simulated by removing all and then adding back the wanted reactions (as ugly as that is.) [Correction: new reactions replace all previous ones, so removing one or replacing one with another is simply a matter of sending the required list of reactions to replace the previous list.] ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0444 update: restrict reactions
> The other part this PR tries to address is to specify how clients should > behave when they receive an error in reply to a reactions payload. I > think that without clarification, the clients should "revert to the > previous reaction state", but I proposed to make "empty my reactions for > this message". Any feedback about this? Removing all reactions just because a user unwittingly adds one too many seems like a bad experience; rejecting the extra(s) makes the most sense. A user then has the option of deciding whether the new reaction is important enough to warrant removing any (and which) of their previous reactions to fit it in. 0444 already provides a way to remove all reactions (send an empty 'reactions' element), so clients should already be able to do that if necessary. The obvious omission is removing an individual reaction (where there are multiple), though this can be simulated by removing all and then adding back the wanted reactions (as ugly as that is.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Social Feed
> - what is this "Gallery profile" thing ? It looks like a terrible way to do > photo galleries, ignoring all the work done by stuff like XEP-0447. Please, I > see no good reason to have this. I think people are misunderstanding the intention of this based purely on the name - it's not intended as a way to do a "photo gallery" but for providing a 'gallery' of posts, each of which has an associated picture. The feature itself is useful and this is an adequate way to do it. While 'gallery' is an appropriate name for it, if it leads to misguided expectations of its purpose, maybe a different name would be preferable, e.g. showcase, or exhibition. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] The Editor intends to resign
Jonas has had enough of Editor work is resigning - good! If the rest of you reading this are feeling outraged that I would say such a thing - GOOD! Now, before anyone jumps on me to say "How dare you say this! Jonas has worked tirelessly and done a superb job, and we'd be lucky to find anyone half as good," you are absolutely correct - he has and we would. Jonas has been extremely diligent, done amazing work, and put in far more time than he should have while doing what is largely a thankless task, even if the end result is appreciated. So, I have no doubt that I speak for everyone when I say thank you very much for everything. However, that doesn't change my point. The Process (Editor or otherwise) should not fall apart because one person needs to take a break. Everybody needs a break from time-to-time, everybody _should_ take a break from time-to-time, and they should not have the guilt of 'allowing' things to fail just because they need a change of scenery. No single person should be carrying all of that responsibility. The Editor process has been broken for some time and, despite repeated calls for help and "can we fix this?", little has changed. Jonas has covered up many of these deficiencies with manual work which he really shouldn't have even had to waste time doing; somebody else stepping up to sacrifice themselves on the same altar will not fix this. It needs to change. So, Jonas, please take a break. Please walk away. Things will break - they should break. And you should not feel any guilt, shame, or remorse. This is a good thing that needs to happen because it won't get fixed until it's broken and causes inconvenience; while it can still be patched up with a little spit and manual work, it will, and so the problem persists. Jonas has provided a convenient list of issues in need of solutions; I suggest anyone concerned by the impending doom should direct some effort towards remedying the situation. Anybody with strong opinions on automating a process who is not involved in maintaining that process can shut up. We all have other responsibilities and this is voluntary for most of us, so the usual "I don't have spare time for that" will apply, but where does Jonas magically get all of this extra spare time to continue covering for the issues that the rest of us don't have the time to fix? It benefits us all, so we can all spare a little time to get it fixed. P.S. For anyone else feeling burnt-out, please take a break - do something else; try a new hobby; go for a walk; stare at the clouds - the things you left will be right where you left them when (or if) you decide to return. The past few years have been difficult for everyone, for cumulative reasons; even if COVID hasn't affected you directly, it has had knock-on effects which most likely have - so feel no shame in needing to take the time to step away and take a breath until you feel fresh and motivated. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-07-27
https://logs.xmpp.org/council/2022-07-27?p=h#2022-07-27-896db7fe75bc4286 1) Roll Call Present: Georg, Daniel, Jonas, Travis, Larma Daniel apologises for missing last week, on account of finally falling victim to Covid; apparently, the experience really wasn't that great (0/5 stars; would not recommend.) 2) Agenda Bashing None. 3) Editor's Update (Repeating from last week) * Last Call for XEP-0215 (External Service Discovery) * Published XEP-0467 (XMPP over QUIC) * Published XEP-0468 (WebSocket S2S) * Proposed XMPP Extension: Pubsub Attachments * Proposed XMPP Extension: Bookmark Pinning Daniel notes that the Last Call for XEP-0215 (External Service Discovery) will be voted on next week, so people should read the XEP and leave feedback [1]. 4a) Proposed XMPP Extension: Bookmark Pinning - https://xmpp.org/extensions/inbox/bookmark-pinning.html Daniel: +1 Travis: +1 Jonas: +1 Georg: +1 Larma: +1 Georg asks whether this is orthogonal to autojoin - Jonas says it is. Georg wants to decorate his bookmarks with emoji. 4b) Proposed XMPP Extension: Pubsub Attachments - https://xmpp.org/extensions/inbox/pubsub-attachments.html Daniel: +1 Travis: +1 (s/6\. discovering support/6. Discovering Support/) Jonas: +1 Georg: [on-list] Larma: +1 5) Pending Votes None. 6) Date of Next 2022-08-03 1500 UTC 7) AOB None. 8) Close Thank you all. Thanks Daniel. [1] https://mail.jabber.org/pipermail/standards/2022-July/038889.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-07-20
https://logs.xmpp.org/council/2022-07-20?p=h#2022-07-20-800b3c244c74f67c 1) Roll Call Present: Travis, Jonas, Larma, Georg Absconding: Daniel 2) Agenda Bashing With no agenda and no Chair, Jonas proposes postponing the meeting, while also suggesting that everyone takes a look at the latest batch of Editor emails. 3) Editor's Update * Last Call for XEP-0215 (External Service Discovery) * Published XEP-0467 (XMPP over QUIC) * Published XEP-0468 (WebSocket S2S) * Proposed XMPP Extension: Pubsub Attachments * Proposed XMPP Extension: Bookmark Pinning 4) Date of Next 2022-07-27 1500 UTC 5) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-07-13
https://logs.xmpp.org/council/2022-07-13?p=h#2022-07-13-195925c6f401ec4c 1) Roll Call Present: Georg, Larma, Daniel, Jonas Idle: Travis 2) Agenda Bashing None. 3) Editor's Update None (Editor is currently working to publish stuff.) 4) Items for Voting None. 5) Pending Votes None. 6) Date of Next 2022-07-20 1500 UTC 7) AOB None. 8) Close Thank you everyone. Thanks Daniel. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-07-06
https://logs.xmpp.org/council/2022-07-06?p=h#2022-07-06-4c0b142619b1b6c0 1) Roll Call Present: Travis, Daniel, Larma, Jonas Apologies: Georg 2) Agenda Bashing None. 3) Editor's Update None. Daniel mutters something cryptic about a last call and the number 215. 4) Items for Voting None. 5) Pending Votes Larma voted +1 on both "XMPP over QUIC" and "WebSocket S2S". 6) Date of Next 2022-07-13 1500 UTC Larma is upgrading to a shiny new superfast fibre connection next week, which possibly means the only (barely) working connection for the rest of the month will be the mobile network. 7) AOB Travis now needs to find the time to write the XEP to discover QUIC and WebSocket S2S - donations of spare time are invited [1]. 8) Close Thank you all. Thanks Daniel and all. Thanks all! [1] https://www.buymeaminute.com/moparisthebest ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-06-29
https://logs.xmpp.org/council/2022-06-29?p=h#2022-06-29-aca5df0aa0c484ce 1) Roll Call Present: Jonas, Travis, Daniel, Larma Apologies: Georg 2) Agenda Bashing None. 3) Editor's Update None this week (Editor was sleepy.) 4) Items for Voting None. 5) Pending Votes (Georg voted on-list [1].) Larma, on XMPP over QUIC; Daniel, Jonas, and Larma, on WebSocket S2S. Daniel asks whether Travis would be willing to take up Peter's offer [2] of guidance through the tribulations of the RFC process - he would, though would prefer to keep them as XEPs in the short-term. WebSocket S2S: Jonas: -0 (should probably be an RFC; can't bring myself to vote *for* the concept of websocket s2s) Daniel: -0 (should be an rfc) Jonas won't veto if Council wants to develop this in Experimental before it moves to an RFC. Daniel notes that this won't pass unless Larma specifically votes in favour. Jonas seconds Georg's comments [1] on XMPP over QUIC, in particular the port numbers - Travis disagrees on changing the default ports and gestures towards ALPN (why reveal we are doing XMPP instead of HTTPS) - Jonas thinks a registration should be sought regardless, as it makes sense for non-multiplexed use cases. 6) Date of Next 2022-07-06 1500 UTC Daniel is in a busy phase, but will try to make it. 7) AOB None. 8) Close Thank you all. Thanks all! [1] https://mail.jabber.org/pipermail/standards/2022-June/038862.html [2] https://mail.jabber.org/pipermail/standards/2022-June/038863.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-06-22
https://logs.xmpp.org/council/2022-06-22?p=h#2022-06-22-09b8686af2f96171 1) Roll Call Present: Georg, Daniel, Jonas, Travis Apologies: Larma 2) Agenda Bashing None. 3) Editor's Update * Proposed XMPP Extension: XMPP over QUIC * Proposed XMPP Extension: WebSocket S2S Daniel takes the opportunity to remind Editor of the XEP-0215 Last Call (no rush.) 4b) Proposed XMPP Extension: XMPP over QUIC - https://xmpp.org/extensions/inbox/xmpp-over-quic.html Travis: +1 (as author) Georg: [on-list] Jonas: +1 (I like the idea) Daniel: +1 Larma: [pending] 4a) Proposed XMPP Extension: WebSocket S2S - https://xmpp.org/extensions/inbox/websocket-s2s.html As a developer, Daniel understands "just do everything rfc xyz is doing except…" in the Requirements, but isn't sure this is the correct form - the author, Travis, didn't want the risk of copying the wrong part or missing something. Jonas has ethical concerns and needs to ponder, though a proper section on 'Motivation' may convince him (noting this is currently entirely missing) - the author thinks that's covered in Use Cases. Daniel asks whether anyone else feels that this belongs in an update of RFC 7395 [1] - Jonas does too - the author expects both belong in RFCs, but is unfamiliar with that process. Daniel suggests Informational XEP as a cheap alternative; also notes the illegal use of an IETF namespace - Jonas suggests using 'urn:xmpp:…'. The author points to RFC 7858 [2] as a prior art for "just do what RFC X says" - Daniel will have to read up on that before voting. Daniel doesn't think creating an RFC is particularly hard, which seems like a better way to handle it - the author will have to look into that. Daniel doesn't want to be the only one blocking this - Jonas is happy to be a second blocker, if needed. Travis: +1 (as author) Jonas: [on-list] Georg: [on-list] Daniel: [on-list] Larma: [pending] 5) Pending Votes None. 6) Date of Next 2022-06-29 1500 UTC 7) AOB None. 8) Close Thank you all. Thanks Daniel. Thanks all! Kev notes that various things have, in the past, migrated from XEP to RFC and back again; doesn't think that starting as XEP and migrating to RFC would be the end of the world, unless Council/XSF lacks the ability to review sensibly (as is sometimes the case with security things.) [1] https://datatracker.ietf.org/doc/html/rfc7395 [2] https://datatracker.ietf.org/doc/html/rfc7858 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-06-15
https://logs.xmpp.org/council/2022-06-15?p=h#2022-06-15-0abb68040a373c63 Tedd returns from the undead and starts burying Georg under a pile of old meeting minutes. 1) Roll Call Present: Jonas, Daniel Apologies: Travis, Georg, Larma Daniel postpones the meeting due to lack of quorum; but still votes +1 on the XEP-0215 Last Call, and is willing to process feedback (with reference to Georg's blocking conditional vote.) 6) Date of Next 2022-06-22 1500 UTC Jonas may lose all sense of time and could need extensive pinging. 8) Close See you all next week. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-06-01
https://logs.xmpp.org/council/2022-06-01?p=h#2022-06-01-cbb53285137d9a07 1) Roll Call Present: Travis, Jonas, Larma, Georg Vacation: Daniel 2) Agenda Bashing Nothing, apparently. 3) Editor's Update None (a proto-XEP is in the pipeline.) 4) Last Call: XEP-0215 (External Service Discovery) - https://xmpp.org/extensions/xep-0215.html Georg asks if there is a nominated Shepherd - Jonas suggest that as Daniel brought it up then it can be his problem. Jonas: +1 Travis: +1 Larma: +1 Georg: +1 (on the condition that Daniel or somebody else volunteers to actually incorporate LC feedback) Daniel: [pending] Jonas questions Georg whether it's necessary to block just because nobody is incorporating the feedback immediately - Georg thinks feedback is best served fresh, and nobody will remember what was needed or why in two years - Jonas hopes those would be recorded in a mailing list thread. Georg starts scaring the younglings with stories of an XEP that once went through six Last Calls - Zash runs away screaming. 5) Date of Next Jonas will be busy in Berlin [1], Daniel will still be on vacation, and Larma is uncertain - Jonas proposes skipping next week - Travis and Georg will be away the following week. 2022-06-15 1500 UTC 6) AOB Georg wonders if anyone has seen the Board in recent weeks - Jonas thought they had a meeting last week, though there seems to be no trace. Georg wanted to put something onto their agenda - Jonas suggests writing an email. 7) Close Thanks everyone. Thank you, Jonas. Georg suddenly remembers an AOB item. 6.1) AOB Again Georg hasn't seen any meeting minutes in a very long time - thinks it's time to ask for a volunteer - Jonas would participate in a rotating schedule between all Council members; since the others have already left, Jonas will try to remember to bring it up at the next meeting. 7.1) Close Again Thanks, it was nice. [1] https://openinfra.dev/summit/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-05-25
https://logs.xmpp.org/council/2022-05-25?p=h#2022-05-25-d33f19e7a9f11f8f 1) Roll Call Present: Jonas, Travis, Larma, Georg, Daniel 2) Agenda Bashing None this week. 3) Editor's Update None this week. 4) Items for Voting None this week. 5) Pending Votes None this week. 6) Date of Next 2022-06-01 1500 UTC Jonas will be at the OpenInfra Summit [1] the week after and likely to be busy doing fearless stuff. Daniel will be on vacation for the next two weeks. Travis will be unavailable for the 15th. Larma has no idea where he will be for the next four weeks. Daniel doesn't expect it will be busy - asks Jonas to chair next week, and possibly skip the week after - Jonas can probably do that; Daniel suggests deciding next week whether to skip the following meeting - Jonas can probably do that too. Daniel will send the agenda and a reminder to Jonas - Jonas thinks that would be excellent. 7) AOB Daniel wants eventually to start a Last Call for XEP-0215 (External Service Discovery), but it's not urgent. 8) Close Thanks Daniel. [1] https://openinfra.dev/summit/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-05-18
https://logs.xmpp.org/council/2022-05-18?p=h#2022-05-18-cfc2980836a99b54 1) Roll Call Daniel, Georg, Jonas, Larma, Travis 2) Agenda Bashing Georg is happy to see that there is an agenda. 3) Editor's Update * Updated XEP-0365 (Server to Server communication over STANAG 5066 ARQ) * Published XEP-0465 (Pubsub Public Subscriptions) * Published XEP-0466 (Ephemeral Messages) 4) Items for Voting Nothing new this week. 5) Pending Votes None. 6) Date of Next 2022-05-25 1500 UTC 7) AOB None. 8) Close Thank you all. Thanks Daniel. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-05-11
https://logs.xmpp.org/council/2022-05-11?p=h#2022-05-11-0e82607eaf36d12f Travis nudges Daniel to update the Security Considerations in XEP-0363 (HTTP File Upload); Travis still has four XEPs he'd like to write himself; Zash also has many to write, and others to fix; nobody knows when such miracles will happen. 1) Roll Call Present: Georg, Travis, Larma, Jonas, Daniel Daniel notes the very full non-existent agenda, consisting of no new votes and no pending votes. 2) AOB None. 3) Date of Next 2022-05-18 1500 UTC 4) Close Everyone thanks each other, hands are shaken, backs are patted, in the distance there is a small cheer; everyone leaves feeling satisfied at a job well done. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-05-04
https://logs.xmpp.org/council/2022-05-04?p=h#2022-05-04-dfbc8534490a72df 1) Roll Call Present: Travis, Jonas, Daniel, Larma, Georg 2) Agenda Bashing None. 3) Editor's Update * Proposed XMPP Extension: Ephemeral Messages 4) Proposed XMPP Extension: Ephemeral Messages - https://xmpp.org/extensions/inbox/ephemeral-messages-v2.html Travis thinks the author, Pep, said he was going to update it and change the name - Editor hasn't seen an update in the queue; Daniel would be fine with it being updated after the vote. Jonas: +1 (good enough to move to experimental, even though it contains at least one error) Georg: +1 (many questions, but none of them are blocking) Daniel: +1 Travis: +1 Larma: +1 (to get it rolling) 5) Pending Votes None. 6) Date of Next 2022-05-11 1500 UTC 7) AOB None. 8) Close Thank you all. Thanks Daniel. Thanks Daniel. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-04-27
https://logs.xmpp.org/council/2022-04-27?p=h#2022-04-27-3eba5833f9745303 1) Roll Call Present: Larma, Daniel, Travis, Jonas Apologies: Georg Daniel proposes postponing, unless someone feels strongly about starting the vote on Ephemeral Messages today - Travis and Jonas would be on-list anyway. 2) Date of Next 2022-05-04 1500 UTC Larma will be travelling, but can (try to) join. 3) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-04-20
https://logs.xmpp.org/council/2022-04-20?p=h#2022-04-20-36d8ce0c7468bf92 1) Roll Call Present: Jonas, Daniel, Travis, Larma Apologies: Georg 2) Date of Next 2022-04-27 1500 UTC 7) AOB Editor queries ideas for what to do with PR #1177 (Ephemeral messages -- Take 2) - it's updating a rejected Proto-XEP for resubmission; asks whether there are objections to treating it as entirely new and letting it go through the process - Daniel and Travis (and Jonas) think that seems fine. 8) Close Thanks! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2022-04-13
https://logs.xmpp.org/council/2022-04-13?p=h#2022-04-13-e6a322ccadb5d94b 1) Roll Call Present: Georg, Travis, Larma, Jonas, Daniel 2) Agenda Bashing No bashing today. 3) Editor's Update * Published Cookies as XEP-0464 * Updated XEP-0356 (Privileged Entity) * Proposed XMPP Extension: Pubsub Public Subscriptions 4) Proposed XMPP Extension: Pubsub Public Subscriptions - https://xmpp.org/extensions/inbox/pubsub-public-subscriptions.html Daniel: +1 Georg: +1 Larma: +1 Travis: +1 (lacking important security considerations, really need those added first thing after acceptance) Jonas: +1 (what Travis said) 5) Pending Votes None. 6) Date of Next 2022-04-20 1500 UTC Larma might be on a train next week (unreliable connectivity expected.) 7) AOB None. 8) Close Thank you everyone. Thanks Daniel. Thanks Daniel. Thanks Daniel. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-04-06
https://logs.xmpp.org/council/2022-04-06?p=h#2022-04-06-ce569d7ee164f613 Daniel notes that there is nothing on the non-existent agenda today. 1) Roll Call Present: Travis, Daniel, Georg, Jonas Late: Larma 2) Date of Next 2022-04-13 1500 UTC Next week's agenda may even have actual content! 3) AOB Travis suggests that Someone™ should update the Security Considerations in XEP-0363 (HTTP File Upload) - Daniel thinks he might be that someone. 4) Close Thanks! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-03-30
https://logs.xmpp.org/council/2022-03-30?p=h#2022-03-30-6b5f019ea634050c 1) Roll Call Present: Jonas, Travis, Daniel, Larma Apologies: Georg 2) Agenda Bashing Jonas possibly has something for AOB. 3) Editor's Update None this week. 4) Items for Voting None this week. 5) Pending Votes None this week. 6) Date of Next 2022-04-06 1500 UTC Jonas will be somewhat unavailable for the next seven days due to business stuff. 7) AOB Jonas suggests asking for more XEPs to advance, and maybe review what's left of the previous shortlist. 8) Close Thank you everyone. Thanks! Thanks!!! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-03-23
https://logs.xmpp.org/council/2022-03-23?p=h#2022-03-23-798e24a8b6dfe6e6 1) Roll Call Present: Jonas, Travis, Daniel Half-present: Georg Non-present: Larma Daniel notes the lack of Editor updates, new votes, and pending votes. 2) Date of Next 2022-03-30 1500 UTC [Note the time change, as Europe will be on DST, technically making the meeting time one hour earlier for those outside of the change (thus back to 'normal' for those who changed earlier.)] 3) AOB None. 4) Close Thank you everyone. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-03-16
https://logs.xmpp.org/council/2022-03-16?p=h#2022-03-16-5ed16d7b34810b0f 1) Roll Call Present: Jonas, Larma, Daniel, Travis, Georg 2) Agenda Bashing Nothing to bash. 3) Editor's Update None this week. 4) Items for Voting Georg made four PRs as a result of last week's discussion - everyone agrees they look editorial and to vote on them all at once; Georg considers them editorial too, but would really like to hear from implementers of 'sipub', if they exist. 4a) PR #1169 (XEP-0406: fix xmlns in example) - https://github.com/xsf/xeps/pull/1169 4b) PR #1170 (XEP-0087: fix xmlns in example) - https://github.com/xsf/xeps/pull/1170 4c) PR #1171 (XEP-0109: fix xmlns in example) - https://github.com/xsf/xeps/pull/1171 4d) PR #1172 (XEP-0072, XEP-0096, XEP-0214: fix xmlns in sipub examples) - https://github.com/xsf/xeps/pull/1172 Jonas: +1 (to me they're fine as editorial) Travis: +1 (they look editorial) Larma: +1 Daniel: +1 Georg: +1 5) Pending Votes None. 6) Date of Next 2022-03-23 1600 UTC [Note: DST is now in effect in North America, causing the meeting time to appear one hour later than normal; European DST will begin on the 27th.] 7) AOB None. 7') Close Thanks Daniel! Thanks Daniel! Thanks Daniel! Thanks Daniel! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-03-09
https://logs.xmpp.org/council/2022-03-09?p=h#2022-03-09-f3d53928d1465034 1) Roll Call Present: Travis, Georg, Jonas, Daniel, Larma 2) Agenda Bashing lua: meeting.lua:9: attempt to get length of a nil value (global 'agenda') stack traceback: meeting.lua:9: in main chunk [C]: in ? 3) Editor's Update * Obsoleted XEP-0008 (IQ-Based Avatars) * Obsoleted XEP-0038 (Icon Styles) * Obsoleted XEP-0051 (Connection Transfer) * Obsoleted XEP-0138 (Stream Compression) * Obsoleted XEP-0229 (Stream Compression with LZW) * Updated XEP-0115 (Entity Capabilities) * Updated XEP-0156 (Discovering Alternative XMPP Connection Methods) * Published PubSub Type Filtering as XEP-0462 * Published MUC Affiliations Versioning as XEP-0463 Jonas notes that some of the changes were due to security issues, so implementers should consider looking into them. 4) Items for Voting Nothing new this week. 5) Pending Votes None. 6) Date of Next 2022-03-16 1600 UTC [Note: DST will be in effect in North America, causing the meeting time to appear one hour later than normal; European DST will begin on the 27th.] 7) AOB Georg has been poking around XEPs and investigating namespaces, and found some inconsistencies (mostly in examples) - isn't sure if they're editorial or normative - Daniel says examples are never normative; Larma thinks the namespaces in examples should still be proper - Daniel agrees, but they can simply be fixed, so it's editorial. Georg can prepare a PR, but would like to escalate each one to the respective XEP authors - which is what he wanted to discuss with Council - Daniel will add it to next week's agenda, but it just seems like fixing typos in examples and doesn't really need to go through Council. Georg checks whether Editor would prefer one big PR or seven million tiny ones - Editor prefers individual ones. 8) Close Thanks Daniel. Thanks all. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-03-02
https://logs.xmpp.org/council/2022-03-02?p=h#2022-03-02-f00da261ce36d367
1) Roll Call
Present: Travis, Jonas, Georg
Apologies: Daniel, Larma
2) Agenda Bashing
Nothing, apparently.
3) Editor's Update
Nada.
4) Items for Voting
{}
5) Pending Votes
Georg, on all the things.
PR #1163:
Georg: +1 (looks like the 0045 editorial f'up has been cleaned up)
MUC Affiliations Versioning:
Georg: +1 (looks good enough for experimental, but I'd rename "since" to
"after" to make it less confusable with timestamps)
Jonas suggests raising that feedback on-list.
Georg would also prefer a sub-element of the 'x' element over namespace
attributes.
PR #1168:
Georg asks if there is a CVE for XEP-0115 - Jonas doesn't think CVEs are for
protocol vulnerabilities.
Georg: +1
PR #1158:
Georg: +1
PR #1159:
Georg: +1
6) Date of Next
2022-03-09 1600 UTC
7) AOB
Jonas would still like to discuss A/V Council meetings, but will postpone that
until everyone is present.
8) Close
Thanks all. Thanks Jonas!
Georg is glad his interrogation is over.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Delayed Council Minutes 2022-02-23
https://logs.xmpp.org/council/2022-02-23?p=h#2022-02-23-315035328bad573b 1) Roll Call Present: Jonas, Daniel, Larma, Travis Driving-responsibly: Georg 2) Agenda Bashing Travis adds his updated PRs from last week. 3) Editor's Update None. 4a) PR #1168 (XEP-0115: mention the pre-image attacks in the XEP) - https://github.com/xsf/xeps/pull/1168 Daniel: +1 Travis: +1 Jonas: +1 Larma: +1 Georg: [pending] 4b) PR #1158 (Remove _xmppconnect DNS method from XEP-0156 and add warnings) - https://github.com/xsf/xeps/pull/1158 Travis: +1 (as author) Daniel: +1 Larma: +1 Jonas: +1 Georg: [pending] 4c) PR #1159 (Obsolete and update Security Considerations for XEP-0138 and XEP-0229) - https://github.com/xsf/xeps/pull/1159 Travis: +1 (as author) Daniel: +1 Larma: +1 Jonas: +1 Georg: [pending] 5) Pending Votes Everyone, on PR #1163: Daniel: +1 Travis: +1 Jonas: +1 Larma: +1 Daniel, on obsoleting 0008, 0038, and 0051: +1 to all three. Jonas, on obsoleting 0038: +1 Georg, Jonas, and Travis, on MUC Affiliations Versioning: Jonas: +1 (worth exploring in experimental) Travis: +1 (still unsure about namespaced attributes but that's what experimental is for) 6) Council Meetings via A/V Continuing the subject from last week. Jonas thinks a regular high-bandwidth call would be nice, though it may not suit everyone, and there are concerns about transparency; also agrees that doing it for every meeting would be problematic. Given that Georg was the strongest opponent, it doesn't make sense to discuss this without his presence. 7) Date of Next 2022-03-02 1600 UTC Daniel will be on vacation - will send an agenda, but ask if Jonas can chair - Jonas accepts. Larma will also be travelling, but might still make it. 8) AOB None. 9) Close Thank you everyone. Thanks. Travis thanks Sam for updating the Security Considerations (in PR #1168). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-02-16
https://logs.xmpp.org/council/2022-02-16?p=h#2022-02-16-be3c28ae5ed36ed4 1) Roll Call Present: Travis, Georg, Daniel, Jonas, Larma 2) Agenda Bashing Jonas checks whether Larma got any reply regarding taking ownership of XEP-0272 (Multiparty Jingle (Muji)) - Larma hasn't yet posted to the Standards List, as was agreed last week. 3) Editor's Update * Updated XEP-0004 (Data Forms) * Updated XEP-0060 (Publish-Subscribe) * Proposed XMPP Extension: MUC Affiliations Versioning 4a) PR #1158 (Obsolete XEP-0156 and add warnings) - https://github.com/xsf/xeps/pull/1158 Daniel checks that this will essentially make BOSH obsolete as it would no longer be discoverable - the author, Travis, notes that it does remove BOSH, but he also has an alternative proposal to remove everything else, while adding BOSH. Travis: +0 (this removes bosh, so my alternate proposal is remove everything else but adding bosh) Jonas: -1 (we should keep BOSH discoverable) Georg: -1 (because of BOSH) Daniel: -1 (i'm on board with getting rid of dns and getting rid of http, but i do think we need to keep bosh) Larma: -1 (don't think we need to keep BOSH forever, but probably still need it today) Travis intends to rework the PR for next week. Daniel thinks that it's interesting W3C EventSource is still around, even though WebSocket exists, but that's probably a discussion for another day. 4b) PR #1159 (Obsolete and update Security Considerations for XEP-0138 and XEP-0229) - https://github.com/xsf/xeps/pull/1159 Jonas would like to point out that writing a MUST NOT in an Obsolete document seems pointless. Georg agrees with obsoleting, but says that "this method is deemed insecure and MUST NOT be used" is a normative change and policy must not be enforced with protocol. Sam understands the reasoning, but has also deployed it on large projects and found it to be extremely beneficial - Travis notes that lots of insecure things are useful. Jonas would be happier if, instead of changing the normative text, a huge security notice were added at the top of the document and in the place where the normative text would've been changed, otherwise the "MUST NOT" part seems obsolete - the author, Travis, explains that the "MUST NOT" is targeted at the method specifically, as he expects a new compression method may be used with the negotiation being resurrected - Jonas still thinks it seems off. Georg would be okay with obsoleting and adding a big red warning in the Security Considerations - Jonas agrees - Travis is happy to change it and will prepare an update for next week. Travis: +1 (as author) Larma: +1 Georg: -1 (because of the MUST NOT) Daniel: -1 (either just obsolete it or just add a security warning) Jonas: -1 (what Georg says) Sam has a brainwave: maybe there could be a non-normative "Editorial Notes" section at the top of XEPs which doesn't require a version update since it's not actually part of the XEP - Jonas thinks that such things should definitely be versioned - Sam says it would still be versioned in Git, and could be updated by Editor or Council. 4c) PR #1163 (XEP-0045: Remove some more mentions of GC 1.0) - https://github.com/xsf/xeps/pull/1163 Georg doesn't think that "[citation needed]" is appropriate in a XEP - Editor will leave a note. Daniel: [on-list] (probably fine, just want to double check later) Georg: [on-list] Larma: [on-list] (same as Daniel) Jonas: [on-list] Travis: [on-list] (would be be +1 if not for [citation needed]) 4d) PR #727 (Obsolete some deferred XEPs) - https://github.com/xsf/xeps/pull/727 This PR moves three currently Deferred XEPs to Obsolete; Jonas suggests voting for each XEP separately - Daniel agrees. 4d i) Obsolete XEP-0008 (IQ-Based Avatars) - https://xmpp.org/extensions/xep-0008.html Jonas: +1 Georg: +1 Daniel: [on-list] Larma: +1 Travis: +1 4d ii) Obsolete XEP-0038 (Icon Styles) - https://xmpp.org/extensions/xep-0038.html Larma: +1 Jonas: [on-list] Travis: +1 Georg: +1 Daniel: [on-list] Georg would still like a XEP for mapping the ASCII smiley to Unicode - Jonas thinks that's better suited to ModernXMPP - Pep suggests using 'jabber:x:data'. 4d iii) Obsolete XEP-0051 (Connection Transfer) - https://xmpp.org/extensions/xep-0051.html Larma: +1 Travis: +1 (with prejudice because it needs major security considerations) Jonas: +1 (think this is best addressed with stream error in RFC 6120, which also talks about the corresponding security considerations) Daniel: [on-list] Georg: +1 (given ) Georg notes that it's been Deferred for over a decade, and asks if anybody is using it - Travis hopes not, or at least that they're using it in a secure way. 4e) Proposed XMPP Extension: MUC Affiliations Versioning - https://xmpp.org/extensions/inbox/muc-affiliations-versioning.html Daniel asks about using attribute namespaces - remembers there was a huge debate, but not the outcome - Jonas says the outcome was that some people are using XML libraries that can't handle
[Standards] Delayed Council Minutes 2022-02-09
https://logs.xmpp.org/council/2022-02-09?p=h#2022-02-09-b64bbd1ecbbd946f 1) Roll Call Present: Georg, Larma, Daniel, Jonas, Travis Georg is welcomed back. 2) Agenda Bashing None. 3) Editor's Update * Updated XEP-0060 (Publish-Subscribe) * Proposed XMPP Extension: PubSub Type Filtering 4a) Proposed XMPP Extension: PubSub Type Filtering - https://xmpp.org/extensions/inbox/pubsub-filter.html Daniel: +1 (lgtm) Travis: +1 (not sure discovery is even necessary, but good to go) Larma: +1 Jonas: +1 Georg: [on-list] 5) Pending Votes Daniel notes there was some list discussion on PR #1153. With PR #1154 depending on the outcome of #1153, people start voting on that too (noted separately for clarity.) Everyone, on PR #1153: Travis: +1 Daniel: +1 Larma: +1 Georg: +1 (the added content sounds like a banality, but it's probably good to explicitly write it out) Jonas: +0 (this is a normative change which just happens to align with the implementations we asked) Additionally, Georg votes on PR #1152: +1 (it's also semi-normative) 4b) PR #1154 (XEP-0060: Release version 1.23.1) - https://github.com/xsf/xeps/pull/1154 Travis: +1 Daniel: +1 Larma: +1 Georg: +1 Jonas: +0 (because it depends on the '4 one) 6) Date of Next 2022-02-16 1600 UTC Larma may not be able to make it, but will try. 7) AOB Larma has attempted to contact the authors of XEP-0272 (Multiparty Jingle (Muji)), but received no response after a month, and the authors don't appear to be involved in XMPP any more - Jonas would be happy to vote in favour of granting Larma ownership, given his current conferencing work. Daniel agrees with Jonas's sentiment, but wonders whether the correct approach might be to leave feedback on the Standards List before declaring it abandoned - others agree. Daniel requests that Larma posts on-list first - it's probably interesting, additionally to ensure they're not subscribed with a different email address and/or stopped caring. 8) Close Thank you all. Thanks, Daniel. Thanks. Thanks Daniel! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-02-02
https://logs.xmpp.org/council/2022-02-02?p=h#2022-02-02-cb9f4f481ab01572 1) Roll Call Present: Jonas, Larma, Travis, Daniel Holiday: Georg 2) Items for Voting None. 3) Pending Votes Georg, on PR #1152; everyone, on PR #1153. Daniel points out that everyone was waiting for the on-list discussion about PR #1153, which has yet to materialise - Daniel will post something [1] after the meeting. 4) Date of Next 2022-02-09 1600 UTC 5) AOB None. 6) Close Thank you all. Thanks. Jonas doesn't guarantee that next week will be better. [1] https://mail.jabber.org/pipermail/standards/2022-February/038736.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-01-26
https://logs.xmpp.org/council/2022-01-26?p=h#2022-01-26-4b609e3fdface235 1) Roll Call Present: Larma, Travis, Daniel, Jonas Holiday: Georg 2) Agenda Bashing No changes. 3) Editor's Update * Deprecated XEP-0256 (Last Activity in Presence) * Message Replies accepted as XEP-0461 * Deprecated and Obsoleted XEP-0443 (XMPP Compliance Suites 2021) 4a) PR #1152 (XEP-0060: Release version 1.23.0) - https://github.com/xsf/xeps/pull/1152 Daniel finds the MUST a bit problematic - what about services that support it but don't advertise - Travis thinks that means they effectively don't support it; Jonas thinks it's okay. Travis: +1 (seems editorial) Jonas: +1 Daniel: +1 Larma: +1 Georg: [pending] 4b) PR #1153 (XEP-0004: Release version 2.13.0) - https://github.com/xsf/xeps/pull/1153 Travis questions whether this actually helps, as a client still can't rely on it; the MUST helped, but 'broke protocol', although known implementations already did it. Larma isn't entirely convinced on the wording of "…only process (e.g., apply) the submitted fields." Daniel would have preferred this to have been posted to the List before being brought to Council; there was already some discussion on it - Travis thinks further on-list discussion would help. Travis also notes that 4c won't be possible unless this is accepted (and is editorial if it is.) Daniel: [on-list] Larma: [on-list] Travis: [on-list] Jonas: [on-list] Georg: [pending] 4c) PR #1154 (XEP-0060: Release version 1.23.1) - https://github.com/xsf/xeps/pull/1154 Skipped, as Travis noted. 5) Pending Votes Daniel votes on PR #1148: +1 6) Date of Next 2022-02-02 1600 UTC 7) AOB None. 8) Close Thank you everyone. Thanks everyone. Thanks! Thanks all. Travis suggests deprecating XEP-0138 (Stream Compression) and XEP-0274 (Design Considerations for Digital Signatures in XMPP) [presumably XEP-0229 (Stream Compression with LZW) was meant] - if not the negotiation, at least the two methods [ZLIB and LZW]; minimally, CRIME/BREACH [1] should be mentioned in the Security Considerations - Jonas thinks the negotiation may be useful. [1] https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-01-19
https://logs.xmpp.org/council/2022-01-19?p=h#2022-01-19-7d46738f10328167 Georg wishes to add an AOB item to talk about the proposed XEPs before he votes on them; a huge discussion erupts [1], causing hours of mayhem. 1) Roll Call Present: Travis, Jonas, Georg, Larma, Daniel 2) Agenda Bashing Daniel notes Georg's earlier desire to add an AOB item, but since it affects pending votes (which would come before AOB) then it should be discussed now - Georg thinks the monster discussion already covered most of it, but would like to give a summary of his thoughts. Georg notes that three of the proposed XEPs from two weeks ago covered ground already proposed/implemented in other XEPs. "Message Replies" is yet another mechanism to reference messages, in addition to References, Fastening, and so on, but Georg thinks it adds UX value and will probably play well with some kind of revised fallback, so is generally in favour, though slightly hesitant due to the message referencing mess. "Compatibility Fallbacks" provides additional semantics to XEP-0428 (Fallback Indication) with a similar title - with Dave's agreement on merging the two and dealing with security considerations along the way, Georg thinks it's better to reject this one. "Call Invites" overlaps XEP-0353 (Jingle Message Initiation) very much and it wasn't made clear why that couldn't be used; the discussion clarified the points and reinforced Georg's feeling that it should be merged into 0353 to focus on calls (both one-to-one and groups) and not have a dedicated wire protocol for the same UX semantics. Georg thanks everybody for the productive discussion and helping to make up his mind. Daniel agrees with Georg's criticism, but notes that "no special criteria (other than acceptance by the Approving Body and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental." Travis understood there to be very different UX between generic Jingle invites and call invites - Jonas took it to mean that this may be true in theory, but in practice 0353 is mostly used for calls, while a push notification for a file transfer offer might be undesirable. Georg will reject the current proposal because it lacks a rationale that clearly describes how 0353 is unsuitable - the author, Larma, thinks the Introduction already has a decent explanation of why it's different. 3) Editor's Update Nothing new. 4a) PR #1148 (XEP-0060: Specify pubsub#type to reflect semantic info) - https://github.com/xsf/xeps/pull/1148 Jonas: +1 Travis: +1 Georg: +1 (looks rather editorial to me) Daniel: [on-list] Larma: +1 4b) PR #1149 (XEP-0256: Deprecate in favour of XEP-0319) - https://github.com/xsf/xeps/pull/1149 Daniel has implemented XEP-0319 (Last User Interaction in Presence) and thought it was lacking in some areas - Jonas asks what's lacking, as they look pretty much the same - Daniel isn't saying that it's better or worse, just that it didn't feel ready, and it feels wrong to Deprecate in favour of something that isn't ready yet. Georg wonders whether XEP-0319 should be included in the Compliance Suites; Jonas has an agenda item about this year's Compliance Suites. Larma thinks that XEP-0319 lacks the functionality to indicate that a timestamp is purposely inaccurate, e.g. rounded to the next hour for privacy - Travis thinks that should be covered in Security Considerations. Daniel has a bunch of issues with 0319, but this isn't the right venue, and it's orthogonal to Deprecating XEP-0256 (Last Activity in Presence). Travis: +1 Georg: +1 Jonas: +1 Daniel: +0 Larma: +1 (on getting rid of 256 so we don't have a duplicate) 5) Pending Votes Georg on the four proposed XEPs… Message Replies: +0 (I like the idea and the UX, but I dislike the mess we are in regarding message reference mechanisms) Compatibility Fallbacks: -1 (needs to be merged into 0428) Call Invites: -1 (should be merged into 0353 unless this merging fails, in which case it needs a better description of why 0353 is not sufficient - the one it has is inadequate as it lacks depth) PubSub Namespaces: -1 (as discussed before, this needs to go into pubsub#type) Everyone on PR #1145… Georg: -1 (removes too much from 0030; see [2] for feedback) Jonas: -1 (supporting the reasons on-list: it is well suited in the PEP add-ons. I like Dave's reasoning that "otherwise trusted" should be taken for that as an escape hatch) Travis: -1 (we shouldn't allow it to become useable for harvesting JIDs) Daniel: -1 (see [3]) Larma: -1 (same reasoning as Travis; also don't think it's needed that you can disco to fetch the pep node) Travis thinks the XEPs that make harvesting JIDs useable need to be fixed, not expanded. 6) Date of Next 2022-01-26 1600 UTC Georg will be on vacation for the next two weeks. 7) AOB Daniel checks that everyone has time for Jonas's urgent agenda item - nobody protests. Jonas suggests that XEP-0459 (XMPP Compliance Suites 2022)
[Standards] Delayed Council Minutes 2022-01-12
https://logs.xmpp.org/council/2022-01-12?p=h#2022-01-12-9ebd16c0ff0be31a Travis apologises for last week's absence, and tries to use the old 'my alarm didn't go off' excuse. 1) Roll Call Present: Jonas, Larma, Georg, Daniel, Travis Daniel runs off quicksy to grab a coffee. 2) Agenda Bashing There is a late addition, courtesy of Pep and Jonas. 3) Editor's Update * Updated XEP-0353 (Jingle Message Initiation) Daniel thanks Thilo for writing that up. 4a) PR #1140 (XEP-0363: notes) - https://github.com/xsf/xeps/pull/1140 Daniel thinks there is a normative change, technically - Jonas says that's why it goes through Council first. Larm votes +1; Jonas also votes +1, saying that any other behaviour doesn't make sense; Daniel thinks it's fine because what else would you do with those headers, and votes +1. Travis thinks some HTTP libraries don't allow specifying the header order - Jonas notes that it should be the header values, not the headers themselves. Jonas realises that the wording is confusing in this respect and changes his vote to -1. Georg adds that it's not clear which are the headers that MUST be included in the PUT request. Jonas hijacks the PR to improve the wording - everyone now votes on Jonas's patched version. Travis: +1 Jonas: +1 Larma: +1 Georg: +1 Daniel: +1 4b) PR #1145 (XEP-0030: remove security considerations preventing requests on a bare JID) - https://github.com/xsf/xeps/pull/1145 Jonas notes that there is already an on-list thread about this [1]. Daniel: [on-list] Jonas: [on-list] (haven't gotten around to read it yet) Travis: [on-list] (worries me a bit) Georg: [on-list] Larma: [on-list] 5) Pending Votes Georg and Travis on all four of last week's proposed XEPs, and Larma on PubSub Namespaces. Travis votes +1 on the first three, but -1 on PubSub Namespaces. Jonas says that the discussion has confirmed his perception that it should be -1 until fixed up as discussed on-list. Georg still needs time to deliberate. Larma votes on PubSub Namespaces: 0 (feel there is need for clarification, but this is not how it should be) Jonas requests the link to the current Spreadsheet of Doom, as it's useful for Editor work - Travis obliges [2]. 6) Date of Next 2022-01-19 1600 UTC Georg will be on vacation for the two weeks after next. 7) AOB None. 8) Close Thank you everyone. Thanks Daniel. Thanks Daniel. Thanks. Travis compliments Larma on all of the new XEPs with actual code behind them, which he thinks is infinitely better than 'in theory' XEPs. Pep grants Jonas retroactive permission to hijack his PR. [1] https://mail.jabber.org/pipermail/standards/2022-January/038702.html [2] https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit#gid=0 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2022-01-05
https://logs.xmpp.org/council/2022-01-05?p=h#2022-01-05-bb4956c3043a4dfa
Happy new year, Council!
1) Roll Call
Present: Larma, Jonas, Daniel, Georg
Absent: Travis
2) Agenda Bashing
Daniel notes some additions to the agenda, as Editor published a few new
proposals after it was already sent out - doesn't expect people to vote yet,
given they haven't had time to read them; at least one looks like it may become
an interesting discussion [1], which could decide Jonas's vote. Georg is
pleased to have more discussion.
3) Editor's Update
* Last Call on XEP-0424 expired
* Last Call on XEP-0425 expired
* Proposed XMPP Extension: Compatibility Fallbacks
* Proposed XMPP Extension: PubSub Namespaces
* Proposed XMPP Extension: Call Invites
* Proposed XMPP Extension: Message Replies
4a) Advance XEP-0424 (Message Retraction) -
https://xmpp.org/extensions/xep-0424.html
Jonas: -1 (depends on a bunch of experimental XEPs the future of which is
unclear)
Daniel: -1 (agree with Jonas)
Georg: -1 (we need to sort out the message referencing mechanism first; also
dislike the amount of boilerplate in both [this and 0425])
Larma: -1 (same here; also goes for 0425)
Travis: [pending]
4b) Advance XEP-0425 (Message Moderation) -
https://xmpp.org/extensions/xep-0425.html
Daniel: -1
Georg: -1
Jonas: -1 (same reasoning as for 0424)
Larma: -1
Travis: [pending]
Daniel notes that even though the following four votes are starting now, not
everyone is necessarily expected to be ready to vote yet.
4c) Proposed XMPP Extension: Compatibility Fallbacks -
https://xmpp.org/extensions/inbox/compatibility-fallback.html
Georg: [on-list]
Larma: +1 (I submitted it, so would be weird to be against)
Daniel: +1
Jonas: +1 (good enough to play with; note it misses a Requirements section)
Travis: [pending]
4d) Proposed XMPP Extension: Call Invites -
https://xmpp.org/extensions/inbox/call-invites.html
Daniel: +1
Larma: +1
Jonas: +1 (looks sensible)
Georg: [on-list]
Travis: [pending]
The author, Larma, notes that this will become useful with PR #1139 [2] applied.
Jonas suggests improving the wording on where to send the 'left' element.
4e) Proposed XMPP Extension: Message Replies -
https://xmpp.org/extensions/inbox/replies.html
Daniel thinks this must be the third or fourth XEP dealing with replies - Larma
(as author) hopes it will be the first to stick.
Jonas isn't sure this should be accepted without a Design Considerations
section detailing why the other mechanisms aren't workable; this feels like
duplication ('thread', References, and Fastening already exist), so some
rationale in the document would be appreciated before acceptance - Larma says
those others don't specifically deal with replies. It's not immediately obvious
to Jonas why 'thread' wouldn't work here, as a reply could always fork off a
fresh thread - Larma explains that this only works if the original message has
a thread-id - Jonas has a realisation. Georg is glad that this doesn't depend
on 'origin-id'.
Daniel doesn't really see threads as a fitting example, but does see overlap
with References and Fastening. Jonas remembers Message Attaching as another
example. Larma doesn't agree they are very similar, but sees the need for a
section in the XEP to explain why it's different.
Daniel: +1
Larma: +1
Georg: [on-list]
Jonas: -0 (desperately needs a Design Considerations section to explain why the
other four standards are not an option to achieve the goal)
Travis: [pending]
4f) Proposed XMPP Extension: PubSub Namespaces -
https://xmpp.org/extensions/inbox/pubsub-ns.html
Jonas: -1 (until there's a good explanation for why pubsub#type isn't an option)
Daniel: 0 (don't know enough about pubsub to make a good call)
Georg: [on-list]
Larma: [on-list]
Travis: [pending]
Larma notes that PR #986 [3] has an explanation for 'pubsub#type' - Jonas says
it should be in the document.
5) Pending Votes
Everyone but Jonas on PR #1126.
Daniel: -1 (should go into 0004; should ask editor to cherry pick the editorial
/ non controversial bits from that PR)
Larma: -1 (not sure if 0004 is the right place either, but the proposal
definitely shouldn't go as is)
Georg: -1 (with the PR as-is, maybe a better non-normative wording can be
proposed if we fail to update 0004)
Jonas wonders how such an integration with XEP-0004 would look, as being Final
makes it tricky - Daniel thinks there was some discussion on how that could
still be done in a compatible way, but also thinks it could be done with a new
XEP.
6) Date of Next
2022-01-12 1600 UTC
7) AOB
None.
8) Close
Thank you everyone. Thanks Daniel. Thanks Daniel!
Kev, as References author, doesn't think References is a reason to block
Message Replies, but agrees that some explanation would be worthwhile - does
think References would work for the use case, but being stuck on URIs is a bit
unfortunate.
[1] https://mail.jabber.org/pipermail/standards/2022-January/038695.html
[2] https://github.com/xsf/xeps/pull/1139
[3]
[Standards] Delayed Council Minutes 2021-12-15
https://logs.xmpp.org/council/2021-12-15?p=h#2021-12-15-2b00496e0cf0ae2c 1) Roll call Present: Georg, Travis, Daniel, Larma Apologies: Jonas 2) Agenda Bashing No changes. 3) Editor's Update None, but keep in the mind the Last Calls expiring on January 4th. 4) Pending Votes Everyone but Jonas is pending on PR #1126 - thanks Travis for starting the List discussion [1]. Daniel is strongly leaning towards -1; as is Travis, and thinks that seems to be the List consensus. Daniel thinks this is too big a change for a Stable XEP; also, that it belongs in XEP-0004 (Data Forms) since many XEPs could benefit from partial configuration submission - Georg notes that XEP-0004 is Final - Daniel thinks it might be possible with some kind of external flag; regardless, XEP-0004 being Final doesn't negate this change not belonging in XEP-0060. Larma is also unhappy with this, and would rather delay voting until after the List discussion ends. Travis thinks it would be fine, or even just editorial, with the partial submission part removed - Daniel thinks Editor could be instructed to apply just the editorial parts. Daniel recommends delaying voting until after the holiday, though with a few already indicating -1, he suspects he knows how it will go. Georg suggests Somebody™ should submit a proposed XEP-0004 wording. 5) Date of Next Daniel proposes taking the next two weeks off and meeting again after the holiday - all are in agreement. 2022-01-05 1600 UTC 6) AOB None. 7) Close Thanks Daniel. Thank you everyone - have nice holidays and enjoy the time off. Stay safe and healthy! [1] https://mail.jabber.org/pipermail/standards/2021-December/038676.html Regarding PR #1126, Kev thinks the change belongs in XEP-0004 and doesn't need to be phrased as a breaking change - all that's needed is to say that "People might submit partial forms. This has been unspecified in the past, but the expected meaning is 'I'm only trying to change what I submit'" - doesn't think it needs to be normative. Peter thinks this makes sense. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2021-12-08
https://logs.xmpp.org/council/2021-12-08?p=h#2021-12-08-2831ac1e3aa545cc 1) Roll Call Present: Jonas, Travis, Georg, Daniel, Larma 2) Agenda Bashing Daniel has two things from Editor which weren't on the original agenda. 3) Editor's Update * Last Call for XEP-0424 (Message Retraction) * Last Call for XEP-0425 (Message Moderation) Editor notes that these will expire after the holiday, in January, rather than the minimum two weeks. 4a) PR #1129 (XEP-0459: Replace deprecated XEP-0411 with XEP-0402) - https://github.com/xsf/xeps/pull/1129 Jonas is generally for the change, but thinks there's an editorial mistake. Daniel asks whether changes have been made before to the Compliance Suites after they became Draft/Stable, but generally agrees on the change. Georg is a bit lost with all of the Bookmarks formats. Jonas thinks the goal should be pushing the Compliance Suites towards Final for the beginning of the next year. Georg agrees with making useful changes. Jonas thinks it's an obvious oversight because recommending a Deprecated protocol doesn't make sense. Georg: +1 Travis: +1 Daniel: +1 Jonas: +1 Larma: +1 Jonas and Daniel attempt to set up a new Spreadsheet of Doom. 4b) PR #1126 (XEP-0060: Release version 1.23.0) - https://github.com/xsf/xeps/pull/1126 Daniel thinks this is probably just editorial, but voting doesn't hurt. Travis notices that part of the change adds a MUST, but it appears to make sense and seems like the correct thing, and maybe implementations already do it this way - Jonas thinks it was previously undefined, and has seen some discussion suggesting it's not how all implementations work today. Larma hasn't thought it through completely, but expects a SHOULD might be more sensible - Travis thinks the MUST is necessary, otherwise you can't be sure what will happen. Jonas suggests Editor should inform the author that this should be put to the List first. Travis thinks there are two sensible options: either a full form is fetched and submitted, with no ambiguity over what was filled, or if a partial form is submitted then the service MUST change only those fields (and not others) - prefers the latter, but only if it doesn't make implementations non-compliant; Jonas notes that as this removes some implementation defined behaviour, it probably will make some implementation non-compliant. Daniel thinks this needs List discussion to see how implementations currently handle it. Travis will write something to the List. Jonas: +1 Daniel: [on-list] Georg: [on-list] Travis: [on-list] Larma: [pending] 5) Pending Votes None so far. 6) Date of Next 2021-12-15 1600 UTC Travis should be able to make it, but is starting a new job. Daniel thinks it might be the last meeting before the holiday, but that can be decided next week. 7) AOB None. 8) Close Thanks everyone, Daniel, Daniel, all, Daniel. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Delayed Council Minutes 2021-12-01
https://logs.xmpp.org/council/2021-12-01?p=h#2021-12-01-2f4806998261b0ce New Council Time! 1) Roll Call Present: Daniel, Jonas, Travis, Georg Delayed: Larma 2) Welcome Jonas welcomes Travis (moparisthebest) and Larma as fresh faces to Council. 3) Chair Election Council is required to have a chairperson to act as head of the committee, and to prepare an agenda for meetings and to lead them; the Chair should also ensure a replacement in cases of expected absence. Jonas asks for volunteers - Daniel says that Jonas did an excellent job for the previous term and would happily vote for him should he volunteer again, but will step forward himself if not - Jonas would prefer less responsibility this term. Travis and Georg compliment Jonas's exceptional management - Jonas graciously accepts the praise. Georg wishes he could spare the time and commitment, but is too familiar with reality. With a lack of other volunteers, and in true democratic style, everybody votes for Daniel as the one and only option - Daniel humbly accepts the honour. Jonas is happy to aid in a peaceful transition where needed, and offers to continue chairing this meeting as Daniel is likely unprepared - Daniel approves. 4) Board Liaison Jonas notes that someone should act as liaison with Board, which includes being subscribed to their mailing list and attending their meetings - Jonas is happy to continue in this role, but will step aside should anybody else want it - Daniel could take over this task as well, but is happy to leave it with Jonas. Everyone votes for Jonas. 5) Meeting Schedule Jonas is happy with the current slot (Wednesdays, 1600 UTC; following European DST) and checks that still works for everyone else - there are no objections. [Date of next: 2021-12-08 1600 UTC] 6) AOB Jonas will poke iTeam regarding room affiliations; has sent an email to the Council mailing list - everyone should check they receive it, and complain (to iTeam) if there are problems. Jonas (Council) will poke Jonas (Editor) to take a look at pending Last Calls; one is already queued, which should start before the next meeting. 7) Close Thanks everyone, Jonas, Jonas, thanks much. Jonas recommends that Daniel arrange a new Spreadsheet of Doom. Kev notes that Board Liaison was originally the Council Chair, not a selected person, but doubts anyone cares too much. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-07-14
https://logs.xmpp.org/council/2021-07-14?p=h#2021-07-14-389c0dc05f245f96 1) Roll Call Present: Zash, Daniel, Jonas, Dave, Georg 2) Agenda Bashing None. 3) Editor's Update * Deferrals have been executed and will be disseminated to the list in a few days to not drown out other updates. Thanks Sam for the reminder. * LCs for XEP-0429 and XEP-0381 have expired last year and Council never voted on it apparently. * Moved 2.0 vs 1.0 will be taken care of by the Editor and MattJ. 4) Items for voting Jonas notes that PR #1064 has been updated yet again during the voting period in order to incorporate list feedback - on behalf of Council, Jonas accepts responsibility as a result of not adhering to the "only vote on it after list discussion has settled down" policy accepted some time ago; this time, Council shall wait for list feedback before voting for a third and (hopefully) final time. 4a) Advance XEP-0381 (Internet of Things Special Interest Group (IoT SIG)) - https://xmpp.org/extensions/xep-0381.html Jonas notes that this had a Last Call in December [1], which was probably missed due to the ensuing holiday. Georg asks whether the IoT Working Group is still functional - Jonas says that Debacle indicated interest, and there are a number of people in the IoT MUC. Zash mentions that were a number of related XEPs in the past, but most have been Retracted [2]. Jonas wonders whether there are measures in place to keep track of SIG members, if only to know where to address questions about deliverables being met; additionally, Jonas asks whether the SIG should be ignored unless there's a problem or if anything is required from Council. Georg: +1 Jonas: +1 Zash: +1 Daniel: +1 Dave: +1 4b) Advance XEP-0429 (Special Interests Group End to End Encryption) - https://xmpp.org/extensions/xep-0429.html Jonas thinks this is in a similar situation [3], though without resources allocated to it (mailing list, MUC, etc.) Jonas: +1 Zash: +1 Georg: +1 Daniel: +1 Dave: +1 5) Pending Votes The vote on PR #1064 has been cancelled. 6) Date of Next 2021-07-21 1500 UTC 7) AOB None. 8) Close Thanks everyone. Dave appears after everybody has already left and votes (noted inline.) [1] https://mail.jabber.org/pipermail/standards/2020-December/037940.html [2] Retracted: XEP-0323, XEP-0324, XEP-0325, XEP-0326; Deferred: XEP-0347 [3] https://mail.jabber.org/pipermail/standards/2020-December/037941.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-07-07
https://logs.xmpp.org/council/2021-07-07?p=h#2021-07-07-cd234d320f4e1065 1) Roll Call Present: Jonas, Daniel, Georg, Zash, Dave 2) Agenda Bashing The author of XEP-0283 (Moved) has consented to ceding authorship, and MattJ is fine with "Moved 2.0" being merged into XEP-0283 and with taking control. 3) Editor's Update * Nothing 4) Add MattJ as author of XEP-0283 (Moved) - https://xmpp.org/extensions/xep-0283.html Jonas: +1 Dave: +1 Zash: +1 Daniel: +0 (if it's not a real change but more a completely new xep it should have been a new number (possibly obsoleting the old one) but I won't block it) Georg: +1 5) Pending Votes Jonas votes on the proposed "Moved 2.0": -1 (under the assumption that it'll be handled in '283 from here on); Dave also votes: -1 (on the basis of [what Jonas said]). Georg is still pending on PR #1064, but would prefer to take more time to catch up. 6) Date of Next 2021-07-14 1500 UTC 7) AOB Jonas says that the Council MUC needs an avatar, and asks for suggestions - Zash suggests the XMPP logo with an additional something; Dave posts an incomplete link to an image and is disappointed when it doesn't work. Georg suggests an antique scroll with the word "standard" written in some dead language [like XML?] Dave posts a better link to the "Grey Council" from Babylon 5. Jonas thinks it would be great if someone came up with a PNG or SVG that can be used, but further deliberation on the content can occur outside of the meeting. 8) Close Thanks everyone! Thanks Jonas, all. Zash thanks a cat for the company. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-06-30
https://logs.xmpp.org/council/2021-06-30?p=h#2021-06-30-a6804355d0b6978b 1) Roll Call Present: Zash, Dave, Jonas, Daniel Late: Georg 2) Agenda Bashing Zash would like to add tacos to the agenda - Jonas thinks that would be nice, but doesn't have any. 3) Editor's Update * Proposed XMPP Extension: Moved 2 4a) PR #1064 (XEP-0227: New revision 1.1) - https://github.com/xsf/xeps/pull/1064 Jonas notes that there was a minor change during the voting period, so a new vote must be started. Jonas: +1 Dave: +1 Daniel: +1 Zash: +1 (but see my post to the list [1]) Georg: [pending] Jonas mentions that there has been some feedback to include PEP affiliations and stuff, but feels that can be done in a future update, with newly namespaced elements - Zash agrees. 4b) Proposed XMPP Extension: Moved 2 - https://xmpp.org/extensions/inbox/moved2.html Jonas has contacted the author of XEP-0283 (Moved), but hasn't heard back yet. Daniel doesn't see any benefits to taking over 0283 - Jonas would prefer merging into the existing one over creating a fresh one, especially since it's really similar - Georg and Dave second that; Zash is neutral. Georg thinks there are already too many ways to do one thing; Dave would be happier just changing the existing one, and doesn't think there's a lot of implementation of 0283. Jonas would prefer overwriting 0283 and granting authorship to MattJ, but would like to wait another week for the original author to respond. Daniel: +1 Georg: +1 Zash: +1 Jonas: [pending] (don't want to vote on accepting as Experimental before that reply) Dave: [pending] (happy to wait to find out if updating XEP-0283 is a sensible option) 5) Pending Votes None. 6) Date of Next 2021-07-07 1500 UTC Georg offers no guarantee on next week. 7) AOB None [Georg must be busy.] 8) Close Thanks everyone, Jonas, all. [1] https://mail.jabber.org/pipermail/standards/2021-June/038397.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-06-23
https://logs.xmpp.org/council/2021-06-23?p=h#2021-06-23-cbe6c0e418e34c85 1) Roll Call Present: Jonas, Daniel, Zash Late: Dave Absent: Georg 2) Agenda Bashing Jonas recommends random outbursts during the meeting. 3) Editor's Update * Compliance Suites 2022 accepted as XEP-0459 4) Items for voting None. 5) Pending Votes Georg, Dave, and Zash, on PR #1064; Dave voted on-list, earlier [1], on Deprecate and Obsolete XEP-0423 (XMPP Compliance Suites 2020): +1 (definitely deprecate, and absolutely obsolete) Dave notes that PR #1064 has been updated in response to his feedback - Zash ponders the legality of updating a PR during the voting period - Jonas thinks it would technically need another vote. Dave would like the PR to be discussed on-list to see other server developers' opinions - Jonas notes that it was already posted to the list [2], but nobody seemed to care, so is unsure what can be improved. 6) Date of Next 2021-06-30 1500 UTC 5') Pending Votes (PR #1064 Discussion) Jonas presumes that Dave will veto the old version, so there can be another vote, but should list discussion be encouraged (again) first - Dave doesn't think there's much more to do be done when it was already posted on-list, but wonders whether that means people care either way. Dave suspects the PR is fine, but isn't sure that encouraging the plaintext password field is going to annoy other server developers, or maybe they don't care, or even welcome the changes. Jonas is sure that Prosody will get an implementation, so if nobody else cares then having MattJ taking care of that seems sensible. Daniel doesn't think the PR sounds very controversial - Dave asks what would happen with another server's implementation - Jonas thinks a namespace bump is the right tool for that; Zash thinks the namespace has already changed many times. Dave isn't against the PR, but has no feel for what the Community feels as a whole - Jonas says feedback can't be forced, but known server developers could be poked - Dave agrees that it can't be forced, but it would be nice to get some support for changing a Draft XEP. Daniel explains that such changes are welcome and overdue; conversations.im considered offering import/export to users, but it was held back by XEP-0227 (Portable Import/Export Format for XMPP-IM Servers) not being modern enough, and this PR fixes exactly those problems - Jonas thinks that would have been great as feedback. Jonas prefers an unopposed and unsupported change on a Draft XEP to yet another Experimental rewrite XEP - as does Dave, but support from other server developers would be great - Jonas thinks they can be poked, and a re-vote is needed anyway. Dave has poked Guus (for Openfire); Jonas has poked Holger (for ejabberd.) 7) AOB Sam has poked Editor for a Last Call on XEP-0292 (vCard4 Over XMPP). Sam also requests that Council will Obsolete XEP-0072 (SOAP Over XMPP) at their earliest convenience - Dave thinks soap is still quite important, given the COVID situation. 8) Close Thanks everyone. [1] https://mail.jabber.org/pipermail/standards/2021-June/038384.html [2] https://mail.jabber.org/pipermail/standards/2021-June/038338.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-06-16
https://logs.xmpp.org/council/2021-06-16?p=h#2021-06-16-e86bc4db397159b0 Sam points Council to the still Draft "XMPP Compliance Suites 2020" and requests it be fixed - Zash feels this should be an automatic thing, though XEP-0001 states that happens upon advancing to Final (also, Draft lasts a minimum of six months, which doesn't suit yearly Compliance Suites.) Sam suggests they could be Informational instead, as they seem to define "best practices for implementation or deployment of an existing protocol" - Zash notes that, as it's defined in XEP-0001, it is up to Board. Zash suggests poking someone to advance CS-2021 to Final, which will automatically Obsolete CS-2020. Sam has no strong preference for Informational, but that seems semantically correct, though the change to process isn't worth the paperwork. Sam discovers that XEPs can be assigned expiration dates. 1) Roll Call Present: Jonas, Zash, Daniel, Georg, Dave 2) Agenda Bashing Jonas heard somewhere that something needs to done about CS-2020 still being Draft, but isn't sure how to handle it - Sam suggests they be Obsoleted; Georg suggests burning them with fire. Jonas will add a vote for Obsoleting, but considers a CFE for CS-2021 would just be additional noise that nobody is really interested in. 3) Editor's Update * Proposed XMPP Extension: Pre-auth Registration Key Generation and Validation 4a) PR #1064 (XEP-0227: New revision 1.1) - https://github.com/xsf/xeps/pull/1064 Jonas: +1 Daniel: +1 Georg: [on-list] Zash: [on-list] Dave: [pending] 4b) Deprecate and Obsolete XEP-0423 (XMPP Compliance Suites 2020) - https://xmpp.org/extensions/xep-0423.html Jonas explains that the sacred process graph in XEP-0001 requires that a Standards Track XEP first goes through Deprecated on its way to Obsolete. Jonas: +1 Zash: +1 Daniel: +1 Georg: +1 Dave: [pending] 5) Pending Votes Daniel dutifully votes on PR #1066: +1 6) Date of Next 2021-06-23 1500 UTC Daniel might not be able to make it; Georg thinks he will make it. 7) AOB Jonas makes note of the shiny new "Community Code of Conduct" (XEP-0458 [1]), just in case anyone missed it, since it mentions Board and Council members specifically, so it's probably worth reading and discussing; note that it's still Experimental, not Active as some seem to believe. 8) Close Thanks everyone, Tedd, Zash, Jonas, Georg, Zash. [1] https://xmpp.org/extensions/xep-0458.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-06-09
https://logs.xmpp.org/council/2021-06-09?p=h#2021-06-09-84a3023f959cd037 Anticipating a scheduling conflict, Georg sends apologies and advance voting/comments (noted inline.) 1) Roll Call Present: Zash, Jonas, Daniel Late: Dave Apologies: Georg 2) Agenda Bashing To everyone's surprise, there is stuff on the agenda. 3) Editor's Update * Two ancient PRs merged 4a) PR #1066 (XEP-0124: Fix incorrect attribute name in text) - https://github.com/xsf/xeps/pull/1066 Georg: +0 (looks reasonable and makes sense, but I'm no server dev) Jonas: +1 (I trust MattJ sufficiently to do the due diligence) Zash: +1 Daniel: [on-list] Dave: +1 4b) PR #1062 (XEP-0045 - Fix typo missed in rev. 1.25) - https://github.com/xsf/xeps/pull/1062 Zash mentioned that this is going to be changed soon, so there would be no point voting on it. Georg suggested adding a note about the now-removed 'none' value, as it was formerly valid and may still exist in the wild. 5) Pending Votes Dave makes an appearance and votes on "XMPP Compliance Suites 2022" at the very last minute: +1 (to adopt that and give it a nunber) 6) Date of Next 2021-06-16 1500 UTC 7) AOB None [Georg isn't here.] 8) Close Thanks everyone! Thanks Jonas, all. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-06-02
https://logs.xmpp.org/council/2021-06-02?p=h#2021-06-02-182e2155c3bb7d49 1) Roll Call Present: Zash, Daniel, Jonas, Georg Absent: Dave 2) Agenda Bashing None. 3) Editor's Update Nothing special. 4) Items for Voting None. 5) Pending Votes Dave, on XMPP Compliance Suites 2022. 6) Date of Next 2021-06-09 1500 UTC 7) AOB Jonas notes that there was a lot of feedback on the "things which need to be advanced" request, so he will put that into a new shortlist. 8) Close Enjoy the Summer [or else!] Thanks everyone, all, Jonas. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-05-26
https://logs.xmpp.org/council/2021-05-26?p=h#2021-05-26-f87794dbb18bc6c9 1) Roll Call Present: Jonas, Georg, Zash, Daniel, Dave 2) Agenda Bashing No amendments. 3) Editor's Update * CVE number things in XEPs * Compliance Suites 2020 (sic) ProtoXEP published 4a) PR #848 (XEP-0292: Recommend using contact bare JIDs as item IDs) - https://github.com/xsf/xeps/pull/848 Jonas noted that this has been idling for a very long time, and pinging Peter hasn't helped, so something should be done about it - Kev questions what 'pinging' actually means, as simply mentioning someone in order to generate a notification isn't necessarily effective - Jonas doesn't know if there have been any explicit email 'pings.' Jonas is happy to ping via email, but if authors aren't listening for pings on their PRs then a better process should be found - Kev notes that the process has always been explicit about important discussion happening openly, i.e. on-list, not in GitHub. Jonas will ping Peter via email. 4b) Proposed XMPP Extension: XMPP Compliance Suites 2022 - https://xmpp.org/extensions/inbox/cs-2022.html Jonas: +1 (let's get this under the roof for proper discussion and further development) Zash: +1 Daniel: +1 Georg: +1 Dave: [pending] 5) Date of Next 2021-06-02 1500 UTC 6) AOB Georg has something related to XEP-0280 (Message Carbons), but is currently busy. Zash asks whether there are any old XEPs to LC or Deprecate - Jonas has mostly cleared his shortlist, except for XEP-0390 (Entity Capabilities 2.0) and XEP-0313 (Message Archive Management) - Sam has a list somewhere. Sam recommends XEP-0054 (vcard-temp) and XEP-0055 (Jabber Search) for the axe. Jonas will make another on-list request for "things which need to be advanced" [1]. 7) Close Thanks everyone, Jonas, Jonas, all. Sam mentions that the 2020 (and 2021) Compliance Suites are still in Draft - Zash mentions they're weird and deserve their own XEP-0001 flow - Sam agrees, but changing that sounds like work when they could just be put out on time (even if imperfect) and tell the Editor to Deprecate the old ones - Georg suggests deprecating CS-2020 and moving CS-2021 to Final - Sam would appreciate that. [1] https://mail.jabber.org/pipermail/standards/2021-June/038332.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-05-19
https://logs.xmpp.org/council/2021-05-19?p=h#2021-05-19-166dd46a385797cb 1) Roll Call Present: Zash, Jonas, Daniel, Georg Apologies: Dave 2) Agenda Bashing The lack of agenda items is making Jonas feel uneasy - Jonas adds something into AOB to feel a little better. 3) Editor's Update Nada. 4) Items for Voting None. 5) Date of Next 2021-05-26 1500 UTC 6) AOB On PR #1059 (XEP-0373: Public key and metadata nodes: Recommend 'open' access model) [1], Jonas wonders about the security/privacy implications - Zash says concerns were raised before about correlating MUC participants, which might apply, and something about reuse of a 'normal' PGP key leaking information - Jonas thinks this might be worth consulting the all-knowing List. Daniel says a lot of OX usage is open to interpretation, creating widely varied security implications; for example, reusing the same PGP key already used with your email, with an open access model, will leak your identity - but this is unclear; doesn't think there are best practices, and would leave it to the authors to steer it in their chosen direction. Jonas will ask the authors to write a note in the Security Considerations, and maybe point The List at it. 7) Close Thanks everyone. Thanks Jonas. [1] https://github.com/xsf/xeps/pull/1059 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-05-12
https://logs.xmpp.org/council/2021-05-12?p=h#2021-05-12-f7f41fa0ddc26bcf 1) Roll Call Present: Daniel, Jonas, Zash, Dave By the pool: Georg 2) Agenda Bashing The agenda is a little short again, but nobody has complained. 3) Editor's Update * This space intentionally left blank. 4) Items for Voting * This space intentionally left blank. 5) Date of next 2021-05-19 1500 UTC Jonas will be on vacation from work and may lose all sense of time and reality. 6) AOB Dave notifies everyone, for sake of completeness, of his upcoming change of employment - congratulations are given. 7) This item intentionally left blank. 8) Close Thanks Jonas. Thanks everyone! Jonas wanders off, talking to a cat. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Lost Council Minutes 2021-05-05
https://logs.xmpp.org/council/2021-05-05?p=h#2021-05-05-8ba02b6dd5bcdfbf 1) Roll Call Present: Dave, Jonas, Zash, Daniel At the beach: Georg 2) Agenda Bashing The agenda is bare, Georg is taking a break, and Dave is preoccupied and so wouldn't mind skipping the meeting - Jonas asks whether anyone is against skipping - nobody is opposed. 3) Date of Next 2021-05-12 1500 UTC 4) Close Thanks everyone! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XEP-0060 Changes
> The submitted configuration form MAY contain a subset of possible > configuration options. In that case, the service MUST only change the > submitted configuration options. Here, the 'MUST' means the service has to change the submitted options (to the values given) and only those options (no others). As a 'SHOULD' it would mean the service is technically allowed to deviate from that (possibly changing other options, or amending values to fit constraints) if it has a good reason to do so; if a service has such a need, then submitting the full form won't change that need and it could still modify/omit values as it sees fit. (Is there a requirement the service MUST change all given options for a full form submission? If not, submitting a subset wouldn't change this.) I think 'SHOULD' is okay in this case. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-11-24
https://logs.xmpp.org/council/2021-11-24?p=h#2021-11-24-153dc4999d1de42b 1) Roll Call Present: Zash, Jonas, Daniel, Georg Absent: Dave 2) Agenda Bashing None. 3) Editor's Update None. 4) Items for Voting None. 5) Pending Votes None. 6) AOB Jonas considered giving a protracted speech summarising every detail of Council business from the past year, but decided not to drag this out unnecessarily (and to avoid tears.) Georg thinks it was a great term, and thanks everybody. Jonas would like to note that only one of the 40 Council votes expired [2.5%], compared with four of the 95 in the previous term [4.2%], which is a slight improvement [60% is slight?], so that's nice. Jonas thanks all for their attendance, insight, and votes; is sorry to see some go, but can fully understand it. Zash thanks Jonas for chairing - Jonas takes a bow, and hopes to find someone (else) to do it for the next term. Georg compliments Jonas on doing a great job as Chair, with structure and preparation [as any self-respecting German should appreciate] - it was a great pleasure; Georg dreams of providing a similar level of quality someday. 7) Close Thanks everyone! Zash now feels obligated to finish the heap of half-done XEPs he started over the last few years. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-11-17
https://logs.xmpp.org/council/2021-11-17?p=h#2021-11-17-c6935cd12e25235a 1) Roll Call Present: Georg, Zash, Jonas, Daniel, Dave 2) Agenda Bashing JC Brand requested that two XEPs be Last Called, though it's now too late to complete that within this Council term, so the Editor will start the LCs at the beginning of the next term. 3) Editor's Update None. 4) Items for Voting None. 5) Date of Next 2021-11-24 1600 UTC 6) AOB None. 7) Close Thanks all! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-11-10
https://logs.xmpp.org/council/2021-11-10?p=h#2021-11-10-17f68c47ca6c5e4f 1) Roll Call Present: Jonas, Zash, Dave, Daniel Apologies: Georg 2) Agenda Bashing Jonas has an ominous feeling that something was missed. 3) Editor's Update XEP-0459 (XMPP Compliance Suites 2022) was advanced to Stable. 4) Items for Voting None. 5) Pending Votes None. 6) Date of Next 2021-11-17 1600 UTC Jonas may be enjoying a public holiday and conveniently forget to appear. 7) AOB Jonas is glad there are at least five candidates for the Council election [1], but less happy there are only five; it's nice to see some new names though! Dave mutters something about 2FA, SASL, and Kittens [2] - people are looking at the framework for nested SASL2 disguised as a SASL mechanism Dave put together, but are deciding against it [despite it clearly being the best thing since cheese on toast!] Zash is briefly excited enough to Dance [3] (client authentication, as in S2S clients and the like) but ran out of energy, och kaffet är kallt. 8) Close Thanks all and everyone! [1] https://wiki.xmpp.org/web/Board_and_Council_Elections_2021 [2] https://datatracker.ietf.org/wg/kitten/about/ [3] https://datatracker.ietf.org/group/dance/about/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-11-03
https://logs.xmpp.org/council/2021-11-03?p=h#2021-11-03-6ad901a0a639fdb2 1) Roll Call Present: Daniel, Zash, Georg, Jonas, Dave 2) Agenda Bashing Amendments should be made by yelling random suggestions throughout the meeting. 3) Editor's Update XEP-0313 (Message Archive Management) is now Stable - congratulations to MattJ, Kev, and everyone else involved in this momentous occasion! 4) Advance XEP-0459 (Compliance Suites 2022) - https://xmpp.org/extensions/xep-0459.html Georg: +1 (I don't like the removal of "Core" very much, but not going to die on that hill) Daniel: +1 Jonas: +1 Zash: +1 Dave: +1 (why not) 5) Date of Next 2021-11-10 1600 UTC [Note the change of time due to DST ending in Europe; North America will also have adjusted then.] 6) AOB Jonas notes the fresh application [1] for Council, which is nice. Zash debates whether to stand - Dave would feel happier if there were more candidates with server experience; wonders whether Holger or Guus could be persuaded. Daniel would be happier if there were more candidates; Dave feels that elections are better when they're contested. Zash mentions the idea of an Election Committee, as a group responsible for nominating positions with consideration beyond popularity, to produce a group who better represents the membership - Daniel thinks there are already enough challenges in motivating people, without the additional challenge of motivating people to motivate other people. 7) Close Thanks everyone, Tedd, Jonas, all, Jonas. [1] https://wiki.xmpp.org/web/Board_and_Council_Elections_2021 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-10-27
https://logs.xmpp.org/council/2021-10-27?p=h#2021-10-27-96dcd73ddbdff0bc 1) Roll Call Present: Georg, Zash, Jonas, Daniel, Dave 2) Agenda Bashing There is an agenda and it is a good agenda. 3) Editor's Update Nothing in particular. 4) Advance XEP-0313 (Message Archive Management) - https://xmpp.org/extensions/xep-0313.html Jonas: +1 Daniel: +1 Zash: +1 Georg: -0 (promised not to block this XEP, and it's an urgently needed thing that's widely implemented, but it's still far away from a good XEP) Dave: +1 (for a terrible XEP, it certainly seems like a lot of people rely on it) Georg is glad parts of his LC feedback were addressed, but wishes all of the other loose ends could be tied up. 5) Pending Votes None. 6) Date of Next 2021-11-03 1600 UTC Jonas may not be present, but will attempt to prepare (and maybe even send) an agenda. [Note the change of time due to DST ending in Europe, effectively moving the meeting time one hour later for those outside of affected regions; North America will re-sync next week.] 7) AOB The author of XEP-0459 (XMPP Compliance Suites 2022) has yet to provide an update - Jonas has pinged them. Georg believes there is still enough time before The Election, and repeats his offer to act as Shepherd if needed. Jonas requests that Georg watches for PRs and pings Jonas if nothing is forthcoming by Friday - Georg can manage that and adds a cryptic note to his calendar. Jonas notes that there are currently no candidates [1] standing for Council; will send an email to try to encourage more people to come forward [2]. Jonas intends to run, but wouldn't want to chair again; Georg thinks likewise - Dave suggests it might be helpful to put themselves forward now, if that's their intention anyway, and that may encourage others once they see that the list is growing - Georg and Jonas think that's a great idea and do so. Zash suggests adding the entire membership list and let people opt-out - whoever is left will find themselves newly elected Council members. 8) Close Thanks Jonas, everyone, Tedd, Jonas, Jonas, Tedd, and all. [1] https://wiki.xmpp.org/web/Board_and_Council_Elections_2021 [2] https://mail.jabber.org/pipermail/standards/2021-October/038627.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-10-20
https://logs.xmpp.org/council/2021-10-20?p=h#2021-10-20-c02f17c6921ba0e0 1) Roll Call Present: Georg, Jonas, Zash, Daniel Invisible: Dave 2) Agenda Bashing Zash thinks the agenda is too thin - Jonas will try to feed it more. 3) Editor's Update Nothing in particular. 4) Items for Voting None. 5) Pending Votes Also none. 6) Date of Next 2021-10-27 1500 UTC [DST will end in Europe on the 31st, and in North America on November 7th.] 7) AOB Kev queries the current state of XEP-0313 (Message Archive Management) - Jonas thinks something needs to be done soon and will add it to next week's agenda. Zash queries the current state of XEP-0459 (XMPP Compliance Suites 2022) - Georg volunteers to don his Shepherding costume for Hallowe'en, if necessary; the author expects to submit something soon. Board and Council elections [1] are approaching; if you think you can do a better job than these clowns, put yourself forward as a candidate by November 7th. 8) Close Thanks everyone. Georg notes the lack of LC feedback on the Easy Onboarding suite [silence is golden, but constructive feedback is still valuable!] * XEP-0379 (Pre-Authenticated Roster Subscription) - https://mail.jabber.org/pipermail/standards/2021-October/038606.html * XEP-0401 (Ad-hoc Account Invitation Generation) - https://mail.jabber.org/pipermail/standards/2021-October/038605.html * XEP-0445 (Pre-Authenticated In-Band Registration) - https://mail.jabber.org/pipermail/standards/2021-October/038604.html [1] https://mail.jabber.org/pipermail/members/2021-September/009322.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-10-13
https://logs.xmpp.org/council/2021-10-13?p=h#2021-10-13-80211e79f898a49f 1) Roll Call Present: Zash, Jonas, Dave, Daniel Present-but-also-not: Georg 2) Agenda Bashing Jonas is pleased the agenda wasn't sent too late this time - nobody else seems to have seen it - Jonas specifically remembers composing the agenda. Apparently, you also have to send emails before others can see them - who knew. 3) Editor's Update * XEP-0280 advanced to Stable 4) Items for voting Nothing. 5) Pending Votes Jonas has poked Sonny, the author of XEP-0459 (XMPP Compliance Suites 2022) - Sonny wishes to incorporate some of the feedback; Jonas suggests cancelling this vote and awaiting those changes - nobody objects. There were no objections to deprecating XEP-0411 (Bookmarks Conversion) on-list. (Jonas already voted +1 last week.) Zash: +1 Daniel: +1 Dave: +1 Georg: +1 6) Date of Next 2021-10-20 1500 UTC Jonas will have an Important Meeting™, and so may be running late if that runs late. [Advance warning of the traditional European clock fiddling on the 31st, with North America joining in a week later.] 7) AOB None. 8) Close Praise to the chair, and thanks to all. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0392: colour vision deficiency adaptation
I agree with your reasoning. Colours should be adjusted through a modified colour-profile for the device (screen), which should already be handled by the OS and with the appropriate settings by the user. Though, as Matthew said, it's still worth noting that colour should be considered an enhancement, and not be essential for using the interface. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
Sorry this is last minute, but here are some thoughts: 1. The Last Call questions aren't really appropriate because usual-argument-about-compliance-suites-not-really-belonging-in-standards-track. 2. I know the idea is to get it out of the way before change of Council, but it still feels too early. 3. Core Suite, Core Client, Core Server, Core features, core core core core core! I think we need another word, if only to make talking about things clearer. Given that all of the other suites require and build upon the Core Suite as a base, it makes sense to rename it to "Base Compliance Suite" (or similar.) 4. The original version (XEP-0242/0243) had two simple categories, Core and Advanced, and that was all; later versions just continued with that. The IM Suite, especially, is becoming quite top-heavy, so adding a middle level would be good - but what to call it? Instead of names, how about simply Level 1, Level 2, and Level 3 - right now that would map Core to Level 1 and Advanced to Level 3, then a subset of Level 3 could make up Level 2. Note that not all Suites require 3 levels (or even 2 in the case of Web). [This also fits nicely with a compliance badge design idea I have.] 5. The tables could also be simplified from several columns (particularly if organised into levels): as everything in Core (Level 1) is a requirement for Advanced (Level 2 or 3), sectioning the tables (thick lines to separate) would allow one column for Client and another for Server, with levels increasing for each successive section (where additional levels are needed), avoiding the need for repetition between Core and Advanced, without making the tables noticeably longer (feature rows with two Xs could be omitted.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Advancement Shortlist
I'll just leave this here… https://mail.jabber.org/pipermail/standards/2020-January/036918.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-03-31
https://logs.xmpp.org/council/2021-03-31?p=h#2021-03-31-73bb35836fe3ee0d 1) Roll Call Present: Jonas, Zash, Daniel, Georg Definitely not attending non-existent secret society meetings: Dave 2) Agenda Bashing None. 3) Editor's Update * Published Content Rating Labels as XEP-0456 4) Deprecate XEP-0013 (Flexible Offline Message Retrieval) - https://xmpp.org/extensions/xep-0013.html Last week Sam requested this be Deprecated due to significant overlap with XEP-0313 (Message Archive Management). Georg never liked the XEP-0013 workaround for the MAM use case, but there are no recommended alternatives. Zash suddenly notices that XEP-0136 (Message Archiving) was deprecated. Daniel believes there are actually very few implementations using message purging, though there isn't a mechanism to replace it; but is still in favour of deprecating. Kev notes that XEP-0386 (Bind 2.0) does provide such a replacement. Georg believes 0013 can be deprecated, and there doesn't appear to be a great need to replace it. Daniel doesn't think the existence of a replacement is a strict requirement for deprecation. Zash thinks the underlying problem might be that interaction between XEP-0013 and XEP-0313 is unspecified. Georg wonders whether it would be possible to create something better than 0013, but not as extensive as XEP-0386. Jonas suggests an option might be to insert the message purging part from 0013 into 0313, and then deprecate 0013. Georg suggests an alternative could be that a client using MAM on connect would have its offline message history dropped. Sam thinks it would be fine to go straight ahead with deprecation, since it shouldn't break anything, and doing so may even encourage efforts towards producing a replacement. Daniel thinks moving the purge protocol into 0313 sounds like a good intermediate solution - Georg is concerned by the many race conditions in MAM, without adding 'delete all history now' to the pile - Daniel doesn't find MAM to be so terrible, even when combined with dropping history - Georg notes that everything works only if the correct rituals are performed in exactly the correct order (and the ordering is undocumented, naturally.) Daniel checks for some agreement that a non-Bind2 alternative to offline message history purging is a wanted feature, and whether the MAM authors would be okay with adding that before 0013 is deprecated - Georg is ambivalent regarding that feature. Zash questions whether it needs to go into 0313, as it would no longer be needed once offline messages are no longer in use. Kev would also prefer not to add this temporarily into 0313, unless there is no intention to advance 0313; it should be put into a new XEP until Bind2 is solved. Georg suggests "do not deliver offline messages to a MAM client" and "expire old messages from offline history if full instead of rejecting new ones" as additions to 0313. Kev believes that users are unlikely to care which clients have received which messages, and so doesn't see a need for per-client offline message storage - Georg thinks users still want to see all messages on all clients, not whichever random subset happens to remain. Georg believes there would be great benefit to improving the perceived reliability of XMPP for legacy clients, such as Pidgin, at a very low cost. Jonas sees that there are arguments about how MAM catch-up might be improved, but those are only tangentially related to whether 0013 should be deprecated. Kev questions what the proposal is, other than using Bind2 (or something similar) to inform the server that you're a MAM capable client and not to send offline messages - Georg's proposal was simply not to send offline messages to any MAM capable client (using MAM already indicates MAM capability.) Zash: +1 Georg: +1 Daniel: +1 Jonas: +1 Dave: [pending] Jonas directs further matters in this enthralling discussion towards the still active XEP-0313 Last Call thread [1], or into a separate discussion for Bind2 design. 5) Pending Votes None. 6) Date of Next 2021-04-07 1500 UTC 7) AOB Jonas queries the possibility of moving Council meetings into the XSF MUC, given that many discussions start in here and should really be carried over into there. Zash isn't opposed - it always seemed weird for Board to hold their meetings there, but not Council; Kev sees no reason to do it, and possible reasons not to. Jonas thinks it might encourage more non-Council input, though also more noise. Georg thought the Council meeting was moved away from the XSF MUC precisely to separate it from the additional noise. Kev thinks the significant advantage to leaving it in here is filtering, as the XSF MUC is quite noisy and can safely be ignored most of the time, while anything happening in here is expected to be more worthwhile. Daniel isn't a fan of Board meetings being held in the XSF MUC, and would prefer Council meetings aren't held there either - if only not to interrupt others'
[Standards] Council Minutes 2021-03-24
https://logs.xmpp.org/council/2021-03-24?p=h#2021-03-24-6f9e9aac8b614c65 1) Roll Call Present: Zash, Daniel, Dave, Georg, Jonas 2) Agenda Bashing None. 3) Editor's Update * Georg Lukas added as author to XEP-0280 * Last Call for XEP-0280 (announcement emails still to be sent) 4) Items for Voting None. 5) Pending Votes Georg votes +1 on PR #1044. Georg votes +1 on Content Rating Labels. 6) Date of Next 2021-03-31 1500 UTC [Note the time change, as Europe will be on DST, technically making the meeting time one hour earlier for those outside of the change (thus back to 'normal' for those who changed earlier.)] 7) AOB Georg mentions the suggestion raised earlier [1] in the XSF MUC, that XEP-0013 (Flexible Offline Message Retrieval) might be deprecated and/or replaced [with a tiny XEP to cover offline message purging], given the prevalence of XEP-0313 (Message Archive Management) - Jonas thinks this discussion may have happened before - Georg thinks it was discussed repeatedly, with the conclusion of handling it in XEP-0386 (Bind 2.0) at the next summit (a suggestion repeated every year since 2015.) Kev notes that XEP-0386 does already cover clearing offline messages in the presence of MAM - Jonas suggests that a few Bind 2.0 implementations could help to iron out the edge cases, which would solve a number of things that really need solving - Zash mutters something about SASL2, IBR2, and AllTheThings2 - Jonas agrees this should ultimately result in XMPP 2.0 (Zimpy Reloaded). Dave notes that usage of (something akin to) XEP-0430 (Inbox) appears to have obviated the need for offline messaging. Jonas suggests that a new RFC might be appropriate - Daniel would like to make it RESTful - Georg wonders whether the tribal knowledge of the RFC-writing elders has been lost. Sam, who raised the point earlier, would like this to be discussed properly next week as he believes there is real harm in recommending a spec which has significant overlap with MAM just for one tiny feature, and little harm in deprecating it. Jonas advises reminding him next week to add it to the agenda - Sam sets a reminder for himself to send a reminder. 8) Close Thanks everyone. [1] https://logs.xmpp.org/xsf/2021-03-24?p=h#2021-03-24-e9834b39af947f41 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-03-17
https://logs.xmpp.org/council/2021-03-17?p=h#2021-03-17-85765ff0a73eae60 1) Roll Call Present: Jonas, Zash, Georg, Daniel, Dave 2) Agenda Bashing Georg wishes to guide XEP-0280 through The Process™ on its way to adulthood. Jonas recommends that people should make their intentions for AOB known through random outbursts during the meeting, in the hope of avoiding a prolonged silence while everyone looks awkwardly at each other before eventually realising there is nothing more; thanks go to Dave for that excellent idea. 3) Editor's Update * Last Call issued for XEP-0313 (Message Archive Management) - implementers should respond [1] 4) Add Georg to the XEP-0280 (Message Carbons) authors - https://xmpp.org/extensions/xep-0280.html Georg notes that this was already discussed on the list [2], and Georg graciously volunteered; one of the original authors, Joe Hildebrand, has no objections to someone else taking over. Dave: +1 Jonas: +1 Georg: +1 Zash: +1 Daniel: +1 Jonas directs Georg to make any necessary changes to XEP-0280 and add himself as an author. Georg, as an official author, requests a Last Call - The Editor shall process that forthwith. 5) Pending Votes Votes required on PR #1044 from Dave, Georg, and Jonas - Jonas notes there was discussion on-list [3]. Georg thanks Fippo for the feedback, and will read up on that before voting. Dave votes +1. Jonas votes +1 (based on the positive feedback, lack of negative feedback, and own judgement that it's 'probably fine') Georg is also missing a vote on Content Rating Labels. 6) Date of Next 2021-03-24 1600 UTC [Note: DST is now in effect in North America, so the meeting time will appear to be one hour later for those affected; European DST begins on the 28th.] 7) AOB There were no random outbursts during the meeting. Georg laments the awkward silence. 8) Close Thanks everyone. [1] https://mail.jabber.org/pipermail/standards/2021-March/038252.html [2] https://mail.jabber.org/pipermail/standards/2021-March/038234.html [3] https://mail.jabber.org/pipermail/standards/2021-March/038232.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-03-10
https://logs.xmpp.org/council/2021-03-10?p=h#2021-03-10-46a8e412b5f68829 1) Roll Call Present: Daniel, Zash, Dave, Jonas, Georg 2) Agenda Bashing None. 3) Editor's Update * New ProtoXEP: Content Rating Labels Sam would like for XEP-0280 (Message Carbons) to be considered for advancement again soon - Jonas suggests poking the authors to ask the Editor, as with MAM. 4a) PR #1044 (xep-0294: add mapping for a=extmap-allow-mixed) - https://github.com/xsf/xeps/pull/1044 Daniel asks whether there are best practices for adding new elements in the same namespace, as there was a similar case for rtcmux recently - Jonas thinks the general consensus is "don't"; Dave says that if it's an optional element then it's technically breaking XML namespacing rules, but thinks it should be fine pragmatically. Zash ponders whether this ought to have been discussed on the list first - Dave was going to raise this too; Jonas had conveniently forgotten that rule, and this PR wasn't even originally on the agenda. Daniel thinks the PR is probably fine and doesn't see it breaking anything in practice, though the proper solution should be to put this in a new namespace - Dave thinks that's more pedantic than proper (namespace bumps are to prevent interoperation failures, which this presumably shouldn't cause - it should be safe to omit this element, and to ignore it.) Zash thinks the general principle of ignoring unknown elements should make this fine without a namespace bump. Zash is irked by the (less visible) discussion on GitHub, rather than on the list. Jonas thinks raising it on-list would be good, especially as it relates to Jingle. Dave is also irked and would prefer it were run past people on-list first. Daniel: +1 Zash: +1 (PR comments are reassuring, and Trust In Fippo®) Dave: [on-list] Jonas: [on-list] Georg: [on-list] 4b) Proposed XMPP Extension: Content Rating Labels - https://xmpp.org/extensions/inbox/content-ratings.html Daniel: +1 Jonas: +1 (author) Georg: [on-list] Zash: +1 (noticed some issues, but sure the author will fix them in Experimental) Dave: +1 (seems worth working on) Zash is particularly impressed by the extensive plain-text compatibility conversion algorithm (§4.1) - Dave thought it seemed overly simplistic and even misses some key cases. 5) Pending Votes None. 6) Date of Next 2021-03-17 1600 UTC Georg will be in a video conference, which may require several seconds of his attention. [Note: North America participates in its bi-annual clock-fiddling on the 14th, so the meeting time will appear to be one hour later for those affected, until Europeans play the same game on the 28th.] 7) AOB None. 8) Close Thanks Jonas, Tedd, all. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-03-03
https://logs.xmpp.org/council/2021-03-03?p=h#2021-03-03-ff70d22f35a5a358 1) Roll Call Present: Daniel, Zash, Georg, Jonas, Dave Dave has definitely not just arrived from a secret gathering (which definitely did not happen) with a clandestine cabal (with which he definitely has no association) in a secret room (which definitely does not exist). 2) Agenda Bashing Georg hopes it's possible to fit the extensive list of items comfortably into half an hour. 3) Editor's Update Nothing. 4) PR #1041 (Update mix namespace for XEP-0406 and XEP-0408) - https://github.com/xsf/xeps/pull/1041 The Editor requests guidance on whether this requires a namespace bump in the two XEPs, since it changes which elements are allowed/expected in the affected PubSub nodes - Dave thinks this looks like an errata correction, so no. Editor ponders the implications for namespace bumping in future modifications of XEP-0369 (Mediated Information eXchange (MIX)) - would it propagate through the whole stack of MIX XEPs? Daniel thinks this particular PR is fine, but isn't sure if the same will apply to others - Jonas agrees - Daniel adds that since the XEPs are Experimental, the authors are free to make radical changes. Georg asks whether it makes sense to bump all MIX elements together - Jonas says that's the ultimate question, and will probably need to be judged per case. Georg will just continue to pretend that MIX doesn't exist. Daniel doesn't expect it will be possible to namespace bump MIX once it's widely implemented - Jonas thinks it's useful during Experimental, at least. The author of the PR, Mathieui, notes that the namespace bumps are primarily to help avoid confusing implementers, as MIX has seen increased interest lately. 5) Pending Votes There are none. 6) Date of Next 2021-03-10 1600 UTC 7) AOB None. 8) Close Thanks everyone. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-02-24
https://logs.xmpp.org/council/2021-02-24?p=h#2021-02-24-2af2318de06a7009 1) Roll Call Present: Zash, Jonas, Daniel, Georg, Dave 2) Agenda Bashing The very late agenda is woefully empty, but nobody has any better suggestions at this moment. 3) Editor's Update "nada" 4) Updated PR #1032 (Data Forms Clarifications) - https://github.com/xsf/xeps/pull/1032 Jonas notes that the author, Flow, approves of the proposed change [1] and there was no other feedback. Georg looks for the exact sequence of changes leading to this version - Jonas squashed everything into one update to keep the versioning tidy. Jonas: +1 Daniel: +1 Zash: +1 Georg: +1 Dave: +1.4 (as before, but this is an improvement, so even more than 1) Sam decides this would be an appropriate time for Agenda Bashing, and requests that XEP-0313 (Message Archive Management) be considered for advancement (to Draft) once again - Editor would prefer the request came from one of the authors, considering they might have pending updates to apply first. 5) Pending Votes None (even from today.) 6) Date of Next 2021-03-03 1600 UTC 7) AOB Dave didn't bring any worms this time. 8) Close Thanks everyone and all. [1] https://mail.jabber.org/pipermail/standards/2021-February/038188.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-02-17
https://logs.xmpp.org/council/2021-02-17?p=h#2021-02-17-a7279024de1951f7 1) Roll Call Present: Daniel, Georg, Zash, Jonas, Dave 2) Agenda Bashing There are no complaints. 3) Editor's Update Nothing to report. 4) Items for voting None. 5) Pending Votes Dave votes on PR #1032: +1 (doing otherwise will break several implementations, including anything based on Smack; think this is the original intent [of XEP-0004] and early implementations appear to follow it.) Georg hasn't yet caught up on the really long thread. Zash thinks the thread appears to have a rough consensus, and votes +1. Jonas says that the behaviour of aioxmpp on the client side matches what Drew described [1] - Dave doesn't think reordering matters much when consuming, but does when producing, and seems entirely wrong when forwarding - Jonas agrees that forwarding shouldn't reorder things. Kev doesn't think breaking Smack is a motivation to do things, but that creating headers after their content is probably broken, and hopes any forwarding entity which changes the order is only used within a closed deployment. Daniel doesn't see how the existing text intended for 'reported' to come first, nor why it's desirable - Jonas agrees - Kev thinks it seems like the Right Thing, but even though it doesn't appear the original text necessarily mandated it, it's clear that was the intention (exemplified in §3.4 "…describing the data to follow") - Dave agrees that it's not very clear, but the intent is there. Georg verifies that the decision is to break implementations which don't follow this - Dave suggests the alternative would be to break implementations which do - Georg says they don't have an explicit right to rely on it, rather a vague implication. That said, Georg is okay with changing the vague implication to a formal requirement. Jonas is quite reluctant about the 'MUST' because this is Final (less issue if it were Draft or Experimental), and thinks this needs a good rationale and text content explaining the change - Georg suggests adding a note about earlier versions of the XEP not strictly mandating order. Dave would be okay with a 'SHOULD', though aioxmpp and ejabberd would still need to be fixed. Georg votes: -1 (as-is, with the MUST; +1 for a MUST with explanatory textbox, or just a SHOULD.) Daniel could be on board with a SHOULD, since this shouldn't be a big deal in practice (ignoring those who need to fix their code) - Dave asks why a SHOULD is preferred here - Daniel feels it's less bad when changing a Final XEP. Georg proposes some text to go in a box. Dave thinks the standards list should be consulted - Jonas considers the addition of a box as editorial - Dave says that means Council don't get to vote, not that the community is bypassed. Kev thinks that adding a box is editorial, but adding text about implementations and encouraging behaviour certainly isn't (even if that happens to be inside a box.) Jonas will put it to the list, but doesn't see the necessity given that this PR wouldn't have been discussed there otherwise - Dave thinks that's a problem in itself, and prepares a can of worms for AOB. Zash can't handle any worms today. Jonas pushes a patch onto the PR, and plans to vote on the updated version next week after possible list feedback [2]. Jonas votes once again: -1 (the new diff looks better considering the current state of the world.) 6) Date of Next 2021-02-24 1600 UTC 7) AOB Dave notes that the Data Forms discussion on-list was very useful, but only started once voting had already begun, which feels awkward; it would be better to discuss things first, and only add them to the agenda once they have been discussed, so Council can just vote - Jonas agrees. Jonas thinks it would be great if some CI magic could be used to automate announcements of PRs tagged with 'Needs List Discussion' and 'Needs Council'. Dave suggests advising that things don't get added to the agenda until after somebody starts the discussion on-list - Jonas doesn't see any significant issue with that; Zash approves of subverting the GitHub flow. Jonas continues to fantasize about automation, but likes Dave's proposal as a first iteration. Dave admits that it pushes extra work onto the submitter, but encourages them to add some rationale and convince people. Daniel is somewhat fine with the current flow (Council gets to decide on uncontroversial things and refers others back to the list), but is also fine with this new suggestion - Dave doesn't think Council deciding what is actually controversial is optimal, given potential bias and the lack of an appeals process. Jonas prepares an email explaining the proposed change [3]. 8) Close Thanks Jonas, Tedd, All, Sundry. Dave apologises for his contribution to the meeting overrun - Jonas thanks Dave for the neat idea. [1] https://mail.jabber.org/pipermail/standards/2021-February/038175.html [2]
Re: [Standards] XEP-0393 styling directive logic still incorrect
Greedy matching means take as many characters as you can while still satisfying the condition, i.e. find the longest match. Lazy matching means take the first match you find, i.e. find the shortest. In the form of regular expressions, we have: * greedy = /\*.+\*/ * lazy = /\*.+?\*/ The text is already correct. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Announcing Slummit 2021
I'd like to say yes, but there doesn't appear to be a lot of active interest. If enough people are prepared to do talks then that would be great, but if there are only two then I'm not sure it's worth wasting those people's time and effort. Maybe I should have made more noise about it and sent frequent reminders and encouragement. I'm also aware that the past year has been draining for many and hasn't provided much in the way of motivation - this was partly an attempt to counter that by encouraging some engagement, though it also suffers from the same effects. So, how many are willing and able to provide content? Or shall we postpone it indefinitely, with a vague suggestion of picking it up at the end of the Summer? From: Standards on behalf of goffi Sent: 18 February 2021 16:10 To: XMPP Standards Subject: Re: [Standards] Announcing Slummit 2021 Hello, is this virtual summit still at thing? I see that it's supposed to happen this week-end, but I see no activity either here on on summit@ MUC room. I was willing to propose a short talk about what I've worked on lastly, and I can still do it if it's not too late, but I would like to be sure that it is still happening. Thanks! Goffi P.S.: this should be probably on summit@ mailing list, but the original thread was here. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-02-10
https://logs.xmpp.org/council/2021-02-10?p=h#2021-02-10-f8b1c3d52716488e 1) Roll Call Present: Daniel, Zash, Jonas, Dave Apologies: Georg 2) Agenda Bashing Silence. 3) Editor's Update * New XEPs: - XEP-0455: Service Outage Status 4) Items for voting None. 5) Pending Votes Jonas notes the lack of discussion on PR #1032 (Data Forms Clarifications), which he did intend to start, but his eventful life had other ideas. Dave votes on Implicit WebSocket Endpoints: -1 (veto without prejudice, on the assumption that a different proposal will emerge; it implies a server default of listening on unencrypted sessions, and devalues XEP-0156; expecting something closer to a 'suggested defaults' with both test and production recommendations.) Jonas notes a small PR to update the XEP [1]. Daniel is glad Dave is doing the vetoing, so he doesn't have to - Dave suggests he still should, in case of other interesting reasoning. Daniel votes: -1 (a XEP that defines a recommendation for default ports and paths is interesting, but this one goes way beyond and tries to influence client behaviour, which might lead to poor choices with regard to XEP-0156; agree with Dave that starting a fresh XEP is preferable to heavily editing this one.) Jonas votes: -1 (let's not repeat the A/ fallback mistake when there's no evidence it's needed for practical interoperability concerns.) Kev isn't convinced that A/ fallback was a mistake at the time. Jonas expects '.well-known' will require some IANA interaction. Dave can see that defaults are nice for ease of testing and deployment, and recommendations for production deployment are great too, but that seems like a fundamentally different XEP than this one. Kev wonders why production deployment recommendations are so great - if a client is doing lookups, isn't that entirely the deployment's choice, in which case why is one recommendation better than another? Dave thinks that suggesting websockets run on port 443 over TLS is useful advice, and materially better than 5280 without TLS; Jonas suggests that would be an Informational XEP - Zash and Daniel support that idea. Kev agrees that TLS is great advice, though is less sure on port 443, but can see an argument for it (and any other port recommendation would be a bad thing). Kev thinks an XEP saying "always use TLS, and port 443 might be a good choice" would likely be less harmful than other possibilities - Zash thinks there might already be RFCs saying "always use TLS!" Jonas asks whether anyone is willing and able to take on the work of making this happen - Dave was assuming Flow (the author) or Sonny would want to; Jonas thought Sonny looked interested in moving this towards a default recommendation. Zash votes: -1 (fallbacks bad, TLS good, what everyone else said; try again with a new proposal.) Jonas assumes PR #1032 will be discussed on-list. Daniel doesn't see how it wouldn't require a namespace bump - Zash prays to a deity - Dave thought it seemed okay - Jonas thinks it's worth going the whole way and also killing the 'reported' element at the same time. Daniel thinks the usage of "clarifying" has been pretty liberal in the past - Jonas would prefer to forbid that word from defiling any XEP PRs again. Dave presumes that either people do care about the ordering, or they don't; a fix would be to say "SHOULD send in order" and "MUST accept in any order" - Jonas and Daniel could live with that; Daniel queries why anyone would send in order if it will always be accepted in any order. Dave accepts this needs further discussion. Jonas sent a reply on-list [2]. 6) Date of Next 2021-02-17 1600 UTC 7) AOB Jonas has a pleasant conversation with his echo, over kaffee und kekse. 8) Close Thanks all for one, and one for all. [1] https://github.com/xsf/xeps/pull/1035 [2] https://mail.jabber.org/pipermail/standards/2021-February/038148.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-02-03
https://logs.xmpp.org/council/2021-02-03?p=h#2021-02-03-16c5bf8a7f6e3e9d 1) Roll Call Present: Daniel, Zash, Dave, Georg, Jonas 2) Agenda Bashing None. 3) Editor's Update * Proposed XMPP Extensions: - Implicit WebSocket Endpoints 4a) Proposed XMPP Extension: Implicit WebSocket Endpoints - https://xmpp.org/extensions/inbox/xep-iwe.html Daniel isn't the biggest fan - Georg thinks Daniel brought up a good point [1] and his own HAProxy deployment seems to agree. Daniel might be less opposed to an Informational XEP titled "Recommendation for default port and path for websocket connections", which would address Sonny's point [2] - Dave asks whether that would mean every XMPP server would need to change its defaults - Daniel admits it would, though the current XEP makes an even stronger requirement, hence including 'recommendation' in the title. Dave isn't sure listening on non-TLS websockets should be encouraged these days - Daniel agrees. Georg thinks the only reason would be for local development and CI/CD, but there are possibly more elegant solutions for those. Zash is sceptical and thinks no-SRV fallback seems like a mistake in hindsight, so maybe it shouldn't be repeated - Jonas agrees and thinks it causes annoying issues. Zash asks whether it at least qualifies for Experimental - Daniel thinks so, as he expressed on-list - Zash agrees. Daniel thinks the Informational XEP might be a compromise, as Sonny does have a point. Dave might veto, but will post an explanation to the list [3] - in summary: non-TLS websockets seem bad; 'suck it and see' doesn't seem like an approach to be encouraged; and it's highly restrictive having the websocket default to the same domain with a different port. Georg finds that ~6% of client connections to yax.im use the non-SRV fallback - Daniel confirms he found ~10% the last time he checked for his server. Jonas mentions Pidgin has regularly fallen back to A/ records because SRV lookup was failing due to the resolver not being ready - doesn't think that accounts for all of those connections, but such issues are a factor; could be addressed by abolishing that endpoint and mandating SRV (i.e. retry SRV instead of fallback). Georg says that old SOHO router resolvers lack SRV support. Daniel agrees that resolving SRV over crap wifi is an issue, but that's not the case for XEP-0156 (Discovering Alternative XMPP Connection Methods) over HTTP. Dave would be amenable to a default path and default port for WSS, as Daniel proposes, which should satisfy much of the local development use case. Jonas: [on-list] (haven't read it yet) Zash: [on-list] Georg: [on-list] Daniel: [on-list] (+0 at best) Dave: [on-list] (likely to veto) 4b) PR #1032 (Data Forms Clarifications) - https://github.com/xsf/xeps/pull/1032 Jonas sees this as a massive normative change, rather than the clarification it claims to be; it introduces a precedent of requiring relative ordering of unrelated elements. Dave doesn't think that's actually a new precedent - the existing text says the 'reported' element describes the data to follow; also recently noticed that SleekXMPP/SliXMPP already assumes an order. Jonas isn't sure that imposes a strict ordering requirement, and knows of at least one implementation which doesn't guarantee the order and would become non-compliant with such a change. The author, Flow, says that form-field type-aware parsing of data forms becomes more complex if the order isn't specified, and it appears to be the norm to have 'reported' first because people copy directly from the examples. Daniel thought the lack of element ordering was the reason schemas are non-normative - Flow says that's why it's specified in the normative text and not the schema. Jonas still isn't convinced this is a clarification - Flow suggests that any change which clarifies a normative requirement that wasn't previously explicitly spelled out could be considered a normative change; sees it as a trade-off. Flow would tolerate implementations changing the order of first-level stanza extensions, but not the order of arbitrary elements while en route. Georg seeks agreement that the updated first commit is indeed a clarification - Jonas and Zash agree. Dave is happy to discuss this further on the list - Jonas will reluctantly start a thread. Jonas: -1 Daniel: [on-list] (too distracted by the bike shed and forgot to read this) Georg: [on-list] Dave: [on-list] Zash: [on-list] 5) Pending Votes Dave votes on Service Outage Status: +1 (pretty sure the general concept is fine.) 6) Date of Next 2021-02-10 1600 UTC 7) AOB None. 8) Close Thanks everyone! [1] https://mail.jabber.org/pipermail/standards/2021-February/038115.html [2] https://mail.jabber.org/pipermail/standards/2021-February/038117.html [3] https://mail.jabber.org/pipermail/standards/2021-February/038127.html ___ Standards mailing list Info:
[Standards] Council Minutes 2021-01-27
https://logs.xmpp.org/council/2021-01-27?p=h#2021-01-27-96c9dcda82e34fee 1) Roll Call Present: Jonas, Daniel, Zash, Dave Stuckinendlessmeetings: Georg 2) Agenda Bashing Millions of voices suddenly cried out in silence and were suddenly silenced. 3) Editor's Update * Accepted as Experimental: - XEP-0452 (MUC Mention Notifications) - XEP-0453 (DOAP Usage in XMPP) - XEP-0454 (OMEMO Media Sharing) 4) Items for voting public final SortedSet items = new TreeSet(); 5) Pending votes Daniel and Dave are pending on 'Service Outage Status', which expires next week. 6) Date of Next 2021-02-03 1600 UTC 7) AOB Jonas asks whether anyone knows of initiatives in the community to implement interoperable group A/V calls - Daniel says Dino got funding for that - Jonas is aware they have something planned [1] - Daniel hopes to join the bandwagon once they're successful. Jonas is less impressed by Jitsi's official stance [2]. Dave suggests having these discussions on the mailing list, so relevant people can make good contributions. Daniel checks whether he needs to clarify XEP-0363 (HTTP File Upload) with regard to an earlier discussion [3] - Jonas thinks adding extra wording would benefit the reader, but isn't strictly necessary; Dave thinks it's clear enough and isn't something for Council to worry over, but one can always a start a mega-thread on the list. 8) Close Thanks everyone. While still knee-deep in patching half the country, Jonas reminds everybody else to patch their sudo versions (due to CVE-2021-3156 [4]). [1] https://dino.im/blog/2020/08/setting-out-for-calls-and-conferences/ [2] https://github.com/jitsi/jitsi-meet/issues/6235#issuecomment-616721373 [3] https://logs.xmpp.org/xsf/2021-01-27?p=h#2021-01-27-8ff21c99fd537374 [4] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3156 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Announcing Slummit 2021
Due to forseen circumstances, this will be postponed until 20-21 February. I was trying to fit it into what would have been the usual Summit time, but it was obviously a last minute idea and not really enough time for people to prepare anything worthwhile. Since there's no strict reason to keep with that time, I hope three weeks from now is adequate; 20-21 is also a weekend, which I hope is preferable. I was asked whether content should be aimed at members & devs only - I don't think there's any reason to limit it only to members, but I think it's safe to assume some familiarity with XMPP. A separate event for a wider, novice audience would be good for marketing, but this isn't it. If anybody wants help, advice, suggestions for content, or "would this be okay?" then I'll be available for discussion, brainstorming, and talking nonsense. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Slummit 2021 - Talks
If you'd like to give a talk then record a presentation (e.g. slides/pictures & voice-over, or talking in front of the camera) of around 15-20 minutes, save it somewhere, and provide a title+link in this thread (to keep them together.) I'd suggest trying to record it all in one take as if you were doing it live, if only to avoid spending too long trying to get it perfect (you can always edit out major mistakes afterwards, though too many jump cuts is worse than the odd slip-up.) I will collect them on Wednesday (submissions before then, please!) and schedule them for Thursday and Friday. Inevitable late submissions will be slotted in somewhere. People may want to watch them beforehand, but I'll arrange 30 minutes per talk (20 for the talk and 10 for questions) plus some breaks in between. The sum...@muc.xmpp.org MUC already exists and many of you are already there, so it makes sense to use that - talk givers should be present to answer questions during and after their talk. The following week, I'll try to put together a digest of the talks and interesting questions for more media noise. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Slummit 2021 - Tales
Post your tales of projects, developments, and other fascinating XMPP-related stories in this thread to keep them all in one place. Write a few short paragraphs about what you've been working on, participating in, any projects you feel others should be made aware of, or anything XMPP-related that you think others would find interesting. Add any links to related blog posts, dev diaries, project websites, and code repositories at the end. Worry less about getting the perfect wording and more about being enthusiastic - your passion will encourage others to be interested in what you're doing. Next week I will gather them into a nice review for some XMPP Blog posts and Newsletter & social media announcements. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Announcing Slummit 2021
Alright, short talks it is! If you'd like to give a talk, record a presentation (slides & voice-over, or dancing in front of the camera if you prefer) of around 15-20 minutes, save it somewhere, and provide a link. If for some reason you'd prefer to stream it live, we could arrange that, though I expect it's beneficial for people to be able to watch/pause/rewind at their leisure and it gives them chance to come up with useful questions. I'll work out a schedule for Q sessions for each talk (and get slum...@muc.xmpp.org setup ..?) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Announcing Slummit 2021
In lieu of an official Summit, I invite all interested parties to participate in the unofficial Slummit! Reply in this thread with a few short paragraphs about what you've been working on, participating in, any projects you feel others should be made aware of, or anything XMPP-related that you think others would find interesting. Feel free to include a link to a longer, more detailed description elsewhere, but provide a digestible summary first. It doesn't need to be a well-edited masterpiece, and you don't have to apologise for your less-than-perfect English, just get some words out and let people know what's going on in the XMPP-world! Additionally, if there's interest, I was considering organising a few voice/video call mini-conferences for groups of 3-7 people (larger groups become a communication burden), each focusing on a particular topic. (Dates 3-5 Feb, times according to participants' availability.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-01-20
https://logs.xmpp.org/council/2021-01-20?p=h#2021-01-20-5e7069fcb50ec8c9 1) Roll Call Present: Georg, Zash, Jonas, Daniel, Dave 2) Agenda Bashing Georg think it's a good agenda; nobody says otherwise. 3) Editor's Update * Proposed XMPP Extensions: - Service Outage Status * New XEPs: - XEP-0451 (Stanza Multiplexing) 4) Proposed XMPP Extension: Service Outage Status - https://xmpp.org/extensions/inbox/service-outage-status.html Georg: +1 Jonas: +1 (will send a few notes to the list [1]) Daniel: [on-list] Dave: [on-list] Zash: [on-list] Georg has no idea about the PubSub parts; not sure if the part in section 2 (This information MUST be scoped using a FORM_TYPE of "urn:xmpp:tmp:sos") mandates actually implementing that feature. 5) Pending Votes Jonas votes +1 on 'MUC Mention Notifications', and +1 on 'DOAP usage in XMPP' Georg asks if there was any news from the Council Process Task Force regarding submitting a Historical XEP - Dave thinks people agreed that Historical sounded sensible; Jonas says nobody objects. Georg duly votes +1 on 'OMEMO Media Sharing'. Jonas awards Georg the Honorary Medal of Zero Pending Votes (the others try to conceal their envy.) Trying to earn his own medal, Dave votes +1 on 'OMEMO Media Sharing', and +1 on 'DOAP usage in XMPP' (noting that it should be tidied-up, change the namespace, etc.) Dave isn't sure he understood the implications of the SupportedXep XML blob within RDF - Zash thinks that might just be RDF doing what RDF does best. 6) Date of Next 2021-01-27 1600 UTC 7) AOB None. 8) Close Thanks everyone, stay alive and (reasonably) sane. Good night. [1] https://mail.jabber.org/pipermail/standards/2021-January/038088.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-01-13
https://logs.xmpp.org/council/2021-01-13?p=h#2021-01-13-826319346f6c3f7a 1) Roll Call Present: Daniel, Zash, Jonas, Dave, Georg 2) Agenda Bashing Item 4c is found to be unnecessary, as an extra vote was overlooked. 3) Editor's Update * Proposed XMPP Extensions: - DOAP usage in XMPP - OMEMO Media Sharing 4a) Proposed XMPP Extension: DOAP usage in XMPP - https://xmpp.org/extensions/inbox/doap-usage-in-xmpp.html Jonas: [on-list] Zash: [on-list] Georg: +1 Dave: [on-list] (heavily leaning toward +1) Daniel: +1 Daniel questions whether XEPs are the right format for specifying something that isn't a protocol extension - Jonas thinks it might be passable if defining how XEPs are to be used or referenced. Dave is happy for this to be an XEP, though not sure which track - possibly Procedural; Zash thinks Informational is fine; Jonas suggests Informational, as it's not a procedure of the XSF or Council. Jonas consults the wisdom of crowds [1]. 4b) Proposed XMPP Extension: OMEMO Media Sharing - https://xmpp.org/extensions/inbox/omemo-media-sharing.html This was previously submitted for the Standards Track, but not accepted; is now resubmitted as Historical. Jonas checks whether Link Mauve has the IPR agreement from Daniel to resubmit his work under a different track… Daniel vaguely remembers his offer to move this to a different track was rejected, so accepting now would be overruling a previous Council decision. Jonas rummages through history and finds the relevant Minutes [2] - thinks the gist is that Historical might be acceptable. Dave feels uneasy about the URI scheme - Georg doesn't think there are ambitions to establish 'aesgcm' as a generic URI scheme - Dave expects it would still have to be registered - Georg thinks defining a non-standard URI scheme for use in a specific, strictly defined context is fair game. Dave will voice his concerns on the venerable list. Georg: [on-list] (waiting for the XEP-0001 Task Force to make a ruling on legitimate options) Zash: [on-list] Daniel: [on-list] Jonas: +1 (with any editorial fixes needed; better to have it documented than not) Dave: [on-list] Daniel would like to fix the example before publishing - Dave is happy to accept now and fix examples after. Jonas recommends RFC 7595 (Guidelines and Registration Procedures for URI Schemes) [3] as light bed-time reading. 5) Pending Votes Georg, Jonas, and Zash pending on MUC Mention Notifications, expiring next week. 6) Date of Next 2021-01-20 1600 UTC 7) AOB Dave asks Daniel whether he has formally given permission to resubmit the 'OMEMO Media sharing' proto-XEP - he has not; Dave doesn't believe it can be accepted unless and until that happens. Daniel hereby officially grants permission for Link Mauve to resubmit the proto-XEP. 7) Close Thanks everyone. Jonas makes a quick exit. [1] https://mail.jabber.org/pipermail/standards/2021-January/038057.html [2] https://mail.jabber.org/pipermail/standards/2018-June/035135.html [3] https://tools.ietf.org/html/rfc7595 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2021-01-06
https://logs.xmpp.org/council/2021-01-06?p=h#2021-01-06-750969cd5c94569f 1) Roll Call Present: Dave, Jonas, Zash, Georg, Daniel 2) Agenda Bashing Jonas checks whether anyone wishes to mutate the agenda - having enjoyed the experience several times already this week, Georg (the masochist) invites everyone to spend twenty minutes explaining how they marked the year increment - Jonas considers that an appropriate addition to AOB. 3) Editor's Update * Updated: XEP-0372 (References) * New ProtoXEP: MUC Mention Notifications 4a) Proposed XMPP Extension: MUC Mention Notifications - https://xmpp.org/extensions/inbox/muc-mention-notifications.html Dave: +1 Daniel: +1 Zash: [on-list] Georg: [on-list] Jonas: [on-list] Georg thinks this should be configurable per member, not just per room by admin, otherwise mentioning somebody in all rooms you're present in could serve as a DoS redirection vector. Jonas notes a typo: "… is encapsulated inside a Server IP Check (XEP-0279) [5] element" [should be 'Stanza Forwarding (XEP-0297)'.] 5) Pending Votes Stanza Multiplexing expired during the break. 6) Date of Next 2021-01-13 1600 UTC 7) AOB Jonas encourages enthralling tales of New Year's Eve; also pokes Dave about a certain video call - Dave pretends to know exactly what that means. Apparently, most spent their evening watching other people's firework displays. Daniel suggests a breakout session during Summit - Dave wonders what planning has occurred so far in that regard (should ask Board to ask SCAM to keep Council informed) - Daniel notes that the FOSDEM date has been fixed (6-7 February [1]), but SCAM has made no plans as yet. Jonas and Zash question the need to stick to the pre-FOSDEM date given the lack of physical presence - Daniel expects the date is as good as any other, and organising an alternative would be additional overhead [and we're really good at organising video calls!] 8) Close Thanks all, thanks Tedd, thanks Jonas, thanks all, thanks Jonas. [1] https://fosdem.org/2021/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-12-16
https://logs.xmpp.org/council/2020-12-16?p=h#2020-12-16-3e8f4fb185a2515b 1) Roll Call Present: Zash, Jonas, Georg, Daniel, Dave 2) Agenda Bashing None. 3) Editor's Update * XEP-0450: Automatic Trust Management accepted as Experimental 4) Items for Voting None. 5) Pending Votes Jonas votes +0 on PR #1014; Georg votes +0 too. Daniel votes +1 on PR #1008. Dave votes +1 on PR #1001 (this is an improvement, but it's getting really complicated and not sure it lends itself well to a formal grammar) 6) Date of Next Jonas will be unavailable next week; Dave doesn't expect to be available either, possibly for two weeks. Jonas suggests skipping the next two weeks and meeting fresh-faced and well-fed in the new year - all are happy to go along with such a maverick plan. 2021-01-06 1600 UTC 7) AOB Georg would like to wish everybody a nice and calm holiday season. Zash wishes everyone a merry whatever and happy new pandemic next year. Jonas will send a nice email to the standards list in an attempt to excuse Council's plans for blatantly neglecting their duties, and some well-wishes. 7) Close Thanks Jonas, Tedd, and al. [Wishing everyone happy Yule/Christmas/Hanukkah/Solstice/Festivus/December celebrations, and hoping next year will bring better times and good health.] ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-12-09
https://logs.xmpp.org/council/2020-12-09?p=h#2020-12-09-b1b9c3afef6268d5 1) Roll Call Present: Dave, Jonas, Zash, Georg, Daniel 2) Agenda Bashing Ook. 3) Editor's Update * New ProtoXEP: Stanza Multiplexing 4) Proposed XMPP Extension: Stanza Multiplexing - https://xmpp.org/extensions/inbox/mux.html Zash: [on-list] Daniel: [on-list] Georg: +1 (liked it, but sure the Montagues and Capulets will never co-host on the same server) Jonas: [on-list] Dave: +1 (plenty to fix, but nothing preventing Experimental) Georg notes that the IQ is missing an ID for the domain to be authenticated, leading to possible race conditions with multiple parallel muxes. 5) Pending Votes There are a lot. Dave votes +1 on PR #1014 (change has been updated); Daniel is also +1; Georg was waiting for a list discussion by the International Association of WebRTC Greybeards and Enthusiasts - Dave notes that the PR has been updated with a conversation. Georg and Daniel vote +1 on ATM; Dave votes +0 (won't veto). Daniel doesn't think it will solve the problems with OMEMO, but is ready to be proven wrong; Georg thinks it will solve part of the biggest usability problem - Daniel isn't convinced it will, or that there aren't easier solutions. Daniel expects it will be implemented regardless, since there is funding, so it's good to get it under XSF IPR. 6) Date of Next 2020-12-16 1600 UTC Jonas will probably not be around for the last two weeks of the year; others may follow his excellent example. 7) AOB Zash is suffering the irony of being so technologically advanced that it limits his ability to send email, due to the rest of the world still not managing to update to IPv6 - Jonas suggests messaging the wonderful people of iteam. Dave hasn't yet looked at XEP-0001 regarding Council voting. 8) Close Oook. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
XML is a sequence of characters (not bytes.) References mark a portion of displayed text which is rendered as a sequence of characters (not bytes.) So it makes perfect sense to define references in terms of bytes. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
>> The decoding _should_ be done upfront - that's how you get a valid XML >> document. > I don't think this is true. XML is defined as UTF-8 (in this case), > which is a collection of bytes. They don't have to be separated out and > transformed into some higher representation of code points. Just because > Python et al. convert things into UTF-32 strings first doesn't mean > everything has to. > > Regardless of what language you're using it's trivial to deal with this > as a UTF-8 byte stream, it is not always trivial to handle this as a UTF- > 32 integer stream as the example shows. XML is defined as a sequence of characters, it doesn't specify how those character must be encoded (though it does require support for both UTF-8 and UTF-16.) UTF-7/8/16/32 are encoding schemes, not character representations - people do make the mistake of conflating the two things, but that doesn't mean they are the same. Unicode doesn't specify the size of characters - they don't have a specific bit-width, they are as large as required; the encoding scheme is then a method to transform characters into a sequence of bytes. It shouldn't matter what encoding scheme is used - UTF-8, UTF-16, ISO-8859-9, ISO-2022-JP, Shift_JIS, EBCDIC, are all possibilities - because you're supposed to decode the data into characters before doing anything it. The fact that you're able to take advantage of the foreknowledge of your data being encoded using UTF-8 is purely because XMPP happens to define it that way, not because XML is defined using any specific encoding scheme. Basing your entire implementation around the expectation of UTF-8 allows you to take some convenient short-cuts, but much of that only works because XML markup uses ASCII-compatible characters, which conveniently have an equivalent single-byte representation when encoded as UTF-8; if it were almost any other encoding then it simply wouldn't work without some form of decoding first. If you insist on not decoding and then run into difficulties with handling characters because you're purposely avoiding handling characters while simultaneously using XML which is defined as a sequence of characters, an appropriate response is "what did you expect?" It's not trivial to handle everything as UTF-8 in implementations where the application receives already decoded strings (a sequence of characters, not bytes) from the XML parser. The most likely approach to dealing with that will be to re-encode the already decoded data back into UTF-8 just to deal with the offsets, which is precisely the kind of inefficient processing you're suggesting should be avoided. And considering the whole purpose of references is for marking sequences of characters, those characters are going to be decoded at some point; you're trying to avoid decoding early, while still validating offsets, so that the decoding can be done later anyway. Regardless, your argument is still "bytes is more convenient for me, so everyone else should do what's best for me." I don't think that's a good argument. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
Sam, your argument appears to be "I want to handle everything as bytes without doing any string decoding, so any other option would be more effort (less efficient) for me." XML is defined as a sequence of characters, not bytes - those characters subsequently need to be transformed into bytes for the purpose of storage/transmission, and that's defined by the encoding scheme (UTF-8 in this case.) Bytes is convenient for you, but not for everyone else using a language that does the decoding upfront. The decoding _should_ be done upfront - that's how you get a valid XML document. If you're trying to handle XML without first decoding from UTF-8 so you can save a few clock-cycles, that's cool, but you are going to run into awkward annoyances when it comes to trying to handle such alien concepts as characters. The reason you can mostly get away with not decoding is because the lower half of ASCII is represented the same way when using UTF-8, so you can pretend the XML tags are encoded as ASCII characters and just treat any Unicode strings as opaque binary blobs - but that is only a convenient hack. If everyone else is to go along with your convenient hack, that only means they will have to deal with their own awkward annoyances because they made the terrible decision to decode strings before handling them (as if that's what you're actually supposed to do.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-12-02
https://logs.xmpp.org/council/2020-12-02?p=h#2020-12-02-a37594276c1a8a41
1) Roll Call
Present: Georg, Zash, Jonas, Daniel, Dave
2) Agenda Bashing
No.
3) Editor's Update
* New ProtoXEP: Automatic Trust Management
* Restart of two LCs which affect Council
4) Items for voting
Jonas checks whether Council members agree to the working agreement that voting
periods shall end 14 days after the first meeting at which the agenda item is
discussed, as the website appears to suggest otherwise [1] - Zash thinks it has
worked well enough thus far; Georg objects that this wasn't on the agenda.
Georg likes that 14 days gives two Council Meetings to catch up.
4a) PR #1014 (XEP-0176: Improve compatibility with WebRTC clients) -
https://github.com/xsf/xeps/pull/1014
Daniel: [on-list] (not entirely sure about the implications)
Dave: [on-list] (need to find some WebRTC expertise)
Jonas: [on-list]
Georg: [on-list]
Zash: [on-list]
Zash thought it mostly looked editorial, with only the schema being changed -
Jonas suggests asking the author, Link Mauve, to add some wording to the
normative part to tie down the change - Link acknowledges.
Zash wonders if anyone with WebRTC expertise could be dragged into reviewing
this - Dave is talking to Fippo; Georg thinks it would be great to have WebRTC
folks' feedback on-list.
4b) PR #1008 (XEP-0047: fix incorrect max sequence number) -
https://github.com/xsf/xeps/pull/1008
Zash: +1
Daniel: [on-list]
Jonas: +1 (think this is fair enough)
Dave: +1 (just fixing a typo in a parenthetical remark)
Georg: +1
4c) PR #1001 (XEP-0393: clarify rules for span directives) -
https://github.com/xsf/xeps/pull/1001
Jonas blames Dave for this expiring last time - Dave remains appropriately
silent.
Jonas: +0 (still)
Daniel: +1
Zash: +0 (again)
Georg: +1
Dave: [on-list] (don't recall this one at all; not sure I understand it)
Dave might have to write this out as ABNF in order to understand it - Jonas and
Zash think that would be great, and then it could be added to the XEP.
4d) Proposed XMPP Extension: Automatic Trust Management -
https://xmpp.org/extensions/inbox/automatic-trust-management.html
Jonas: [on-list]
Daniel: [on-list]
Georg: [on-list]
Zash: [on-list]
Dave: [on-list]
Georg bemoans the tradition of XEP authors redefining commonly-used acronyms
('ATM' in this case.)
Dave thinks this looks somewhat familiar - Zash suggests Dave might be thinking
of XEP-0434 (Trust Messages (TM)) which is the wire format, while this seems to
be mostly policy.
5) Pending Votes
None so far, amazingly.
6) Date of Next
2020-12-09 1600 UTC
7) AOB
The current voting policy/system seems to have remained unchanged for years, so
if it can be adequately codified then Dave will attempt to write it up in
appropriately cryptic standards-speak and sneak it into XEP-0001; Jonas adds
that much of it is already codified in the XSF Bylaws [2]. Dave will try to
come up with some text for next week, but everyone should think about how to
conduct voting.
8) Close
Thanks everyone.
[1] https://xmpp.org/about/xsf/council-policies-and-procedures
[2] https://xmpp.org/about/xsf/bylaws
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Proposed XMPP Extension: Character counting in message bodies
> FWIW I was a big proponent of doing it this way too, but I've changed my > mind after seeing too many grapheme segmentation implementations be > broken in small, different, ways. My new position is that we have to > just count bytes and figure out a sane behavior in case someone sends us > an invalid offset in the middle of a codepoint or something. This is > encoding agnostic (not that it matters for XMPP) and makes it very easy > to count: go to that byte offset, check if we're on any sort of UTF-8 > boundary, if so call it a day, if not do whatever the fallback is. Codepoints are preferable: https://mail.jabber.org/pipermail/standards/2019-October/036589.html If you're indexing by clusters then you're just asking for trouble. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Off-by-one error in XEP-372 "References"
"How to specify character ranges" is a problem that keeps appearing - can we resolve this once and for all, and then ensure we're consistent with that in all XEPs? There are only three sensible options: 1. Start = first character (inclusive), end = last character (exclusive); 2. Start = first character (inclusive), end = last character (inclusive); 3. Start = Boundary before first character, end = boundary after last character. Option 1 is what I presume most are familiar with as that's how indexing works in many programming languages, and option 2 makes some sense as you're pointing to the first and last characters to be included. The problem with the first two options is that it leads to this inclusive/exclusive confusion where the text seems to say one thing and the example says another. Option 3 sidesteps that issue by indexing the positions between characters, rather than the characters themselves - so a character is either before or after a boundary, and is explicitly included or excluded from a range. Numerically, this is actually equivalent to option 1, but by describing it in this way, the confusion never arises. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-11-25
https://logs.xmpp.org/council/2020-11-25?p=h#2020-11-25-802c09a26780f647 1) Welcome to our transition meeting Members of the previous Council are present to ensure a smooth transition of responsibilities. Previous Council: Daniel, Dave, Georg, Jonas, Zash New Council: Jonas, Daniel, Zash, Dave, Georg 2) Election of Chair Zash asks Jonas whether he wishes to continue his role as council furniture; Dave has already expressed a disinterest; nobody else volunteers. 2a) Confirm Jonas as Chair Jonas: +1 Daniel: +1 Zash: +1 Dave: +1 Georg: +1 3) Meeting schedule The duly elected Chair, Jonas, proposes meeting weekly on Wednesdays at 1600 UTC (subject to DST adjustments) - there are no objections. Date of Next: 2020-12-02 1600 UTC 4) AOB Dave wonders whether Jonas will be acting as Board Liaison, which could be Chair or possibly delegated - Jonas is happy to bear this great responsibility. Chair will instruct Editor to check for any votes needing to be restarted for collection into the agenda for the next meeting. 5) Close Thanks everyone. Georg is glad for the convenient re-use of the meeting time slot. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-11-18
https://logs.xmpp.org/council/2020-11-18?p=h#2020-11-18-b43c59f0d77acd68 1) Roll Call Present: Daniel, Zash, Dave, Georg, Jonas 2) Agenda Bashing None. 3) Editor's Update * Editors have been very busy. 4a) Proposed XMPP Extension: File metadata element - https://xmpp.org/extensions/inbox/file-metadata.html Dave thinks this already had some on-list discussion, others seem to have missed that; at least, Dave thought it looked familiar and so assumed he'd seen it before - Zash demands a reference to this clandestine discussion. It appears to Georg that this is copying the 'file' element from XEP-0234 (Jingle File Transfer) for the sake of copying the 'file' element from XEP-0234 - wonders whether he's missing something - Jonas believes the idea is to separate it out for use in other XEPs, without necessarily being bound to the 0234 namespace. Dave: +1 (seems fine) Daniel: +1 Jonas: +1 (have remarks, but will suggest those to authors on-list [1]) Zash: +1 Georg: +1 (given that 0234 is deferred, it's worth a try) Zash isn't entirely convinced that another XEP really fixes anything - Georg doesn't disagree, but thinks that smaller, reusable elements in their own XEPs are a good idea - Zash doesn't disagree. Georg questions what will happen if this is ever given the forbidden namespace bump - will clients have to send two 'file' elements with different namespaces? - Daniel doesn't think the idea is to make it resilient against bumps, but to better use it outside of Jingle; Georg assumes making it reusable will make it prone to bumping. 4b) Proposed XMPP Extension: Stateless file sharing - https://xmpp.org/extensions/inbox/sfs.html Zash wonders whether this was made in preference to re-authoring SIMS (XEP-0385). Dave thinks this is basically SIMs but based around the file metadata instead. Georg suggests allowing Marvin, the author, to co-author SIMS and make the fixes in there - Dave also considered this. Daniel questions whether there has been a clear consensus on the need for such a re-factor of SIMS, as SIMS might still be useful for other things - Dave is unsure; Jonas questions whether such a consensus is needed before accepting this as Experimental. Zash suggests throwing SIMS and SFS into the arena and letting them fight to earn their place upon the throne of OOB. Georg imagines a post-apocalyptic future where clients send multiple different 'file-attached' elements for compatibility reasons, even though each client supports the same set of mechanisms; Dave is impressed by the optimism of expecting that any two clients will ever have any file-transfer mechanisms in common. Daniel expects that, with the body fallback, it should be relatively safe to drop OOB at some point; Dave hates body fallback [nobody mention XEP-0428.] Zash suggests everything will be okay with Fallback Indication (XEP-0428), though it is lacking a fallback for itself. Daniel: +1 Zash: +1 Jonas: +1 Dave: +1 (don't object) Georg: [on-list] 4c) Proposed XMPP Extension: Encryption for stateless file sharing - https://xmpp.org/extensions/inbox/esfs.html Dave thinks this has issues, but nothing insurmountable, so publish then fix (hopefully). Georg likes the extensive Security Considerations. Jonas: +1 (feedback on-list [2]) Daniel: +1 Zash: +1 Dave: +1 (unclear if every cipher suite will have/need separate key and IV) Georg: [on-list] 4d) Proposed XMPP Extension: Stickers - https://xmpp.org/extensions/inbox/stickers.html Jonas thinks the hash calculation looks very reminiscent of XEP-0390 (Entity Capabilities 2.0); suggests the author, Marvin, might consider replacing ASCII separators (invalid in XML 1.0, but valid in 1.1) with NUL (invalid in both) - Marvin would rather enforce that name, desc, and summary should be displayable to end-users and not include ASCII separators - Jonas thinks doing both would be provide low-cost additional resilience. Dave admits to possibly being too old to understand what a 'sticker' is - Georg suggests "something like a large custom emoji" - Dave asks why they hunt in packs. Daniel wonders whether stickers might be better suited to SIMS rather than file-sharing (unsure how stickers work/are used). Georg: [on-list] (need to think about the technical implications and copyright violation issues) Jonas: [on-list] Dave: [on-list] Daniel: +1 Zash: +1 5) Pending Votes Dave votes +0 on "Advance XEP-0443 (XMPP Compliance Suites 2021)". Georg votes +1 on "PR #1001 (XEP-0393: clarify rules for span directives)"; everyone else is slacking. Jonas pushes everyone to cast remaining votes on the list. 6) Date of Next To be decided by the incoming Council. 7) AOB Georg suggests advancing XEP-0423 (XMPP Compliance Suites 2020) to Final, as it's now officially over a year old; hopes it might yield useful input for CS-2021 - Jonas is unsure how a CFE would work across council terms. Zash considers asking Board to add a special Compliance Suite Thing into XEP-0001.
[Standards] Council Minutes 2020-11-11
https://logs.xmpp.org/council/2020-11-11?p=h#2020-11-11-5233da80fee8a079 1) Roll Call Present: Jonas, Zash, Daniel, Georg Apologies: Dave 2) Agenda Bashing None. 3) Editor's Update * Nothing out of the ordinary. 4) Items for voting Jonas notes that, as this is the penultimate meeting of this Council, any votes started now will run the risk of expiring with the end of the term. 4a) Advance XEP-0443 (XMPP Compliance Suites 2021) - https://xmpp.org/extensions/xep-0443.html Daniel questions whether the feedback was addressed - Jonas notes there was an update yesterday [1]. Daniel: +1 Jonas: +1 Zash: +1 Georg: +1 Dave: [pending] Zash feels there could have been more feedback, though there isn't such a great difference from the previous Suites which was obviously accepted. Jonas is glad it didn't turn into a huge war of semantics and pedantry this time. 4b) PR #1001 (XEP-0393: clarify rules for span directives) - https://github.com/xsf/xeps/pull/1001 See [2] for relevant war of semantics and pedantry discussion. Jonas: [on-list] (didn't look into it yet) Daniel: [on-list] Georg: [on-list] Zash: [on-list] Dave: [pending] Jonas begs for everyone not to let this one expire. 5) Pending Votes One each for Daniel and Dave on Pre-Authenticated In-Band Registration (expiring next week.) 6) Date of Next 2020-11-18 1600 UTC Jonas may forget about the meeting while repenting next Wednesday, which is a public holiday in parts of Germany, but will try hard not to. 7) AOB Zash wishes everyone good luck in the elections. Jonas reminds everyone to cast their votes, and thanks Alex for his efforts in organising it all. 8) Close Thanks everyone, Tedd, Alex, and all. [1] https://gitlab.com/xsf/xeps/-/merge_requests/35/ [2] https://mail.jabber.org/pipermail/standards/2020-November/037859.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Council Minutes 2020-11-04
https://logs.xmpp.org/council/2020-11-04?p=h#2020-11-04-51d2be3786d1879f 1) Roll Call Present: Jonas, Dave, Daniel, Zash, Georg 2) Agenda Bashing Georg wanted to add his XEP-0401 (Easy User Onboarding) changes, but they don't depend on Council. 3) Editor's Update * LC ended: XEP-0443 (XMPP Compliance Suites 2021) 4a) MR !29 (XEP-0045: specify use of in subject message) - https://gitlab.com/xsf/xeps/-/merge_requests/29 Jonas: +1 Zash: +1 Dave: +1 Daniel: +1 Georg: +1 4b) Proposed XMPP Extension: Pre-Authenticated In-Band Registration - https://xmpp.org/extensions/inbox/ibr-token.html Georg: +1 Daniel: [on-list] Jonas: [on-list] Zash: [on-list] Dave: [on-list] The author, Georg, thanks Dave for his review [1] - Dave still needs to think about this, given Sam's comments [2]; Georg think's Sam made a very generic point that applies to the whole pre-authenticated phase. 4c) Advance XEP-0443 (XMPP Compliance Suites 2021) - https://xmpp.org/extensions/xep-0443.html The author, Georg, notes there was some feedback; Jonas thinks there were comments which should be addressed in some way. The Editor apologises for the automation weirdness that happened with the extra announcement email which appeared yesterday. Jonas doesn't think it makes sense to vote on this until the feedback has been addressed; Georg will endeavour to satisfy all interested parties - would also like to see even more feedback, e.g. are there any XEPs missing or to be removed. 5) Date of Next 2020-11-11 1600 UTC Dave may or may not make it, in between transporting his vintage beer bottle collection between homes. 6a) AOB i: Election Season Jonas notes there are more applications now [3], which is nice. 6b) AOB ii: Compliance Suite 2021 Georg thanks Daniel very much for his A/V additions, and the LC feedback; is looking for specific feedback regarding further XEPs to be added, any to be moved from non-normative to normative, and any that might be removed. MDosch has suggested adding XEP-0425 (Message Moderation) - Georg thinks that it might be a good addition for Advanced IM, though it's still Experimental; Daniel thinks there's a lack of experience with that, not only because it makes use of Fastening - Zash suggests adding it under Future Development. Georg kindly asks Council to review and consider the XEPs touched in the last year for inclusion - Zash requests such a list - Editors will oblige. 6c) AOB iii: XEP-0401 and ibr-token Zash queries the intended relation between these two and XEP-0379 (Pre-Authenticated Roster Subscription) - Georg explains that 0379 is the roster-adding part, ibr-token is the account-creation part, and 0401 connects it all together. Zash notes there is a conflicting overlap with 0401 - Georg had a slight disagreement with 0401's author about its direction, and isn't yet confident how to resolve that; Jonas notes MR !33 [4] - Georg adds that this removes everything IBR related from 0401. Zash may have stated before, but would very much like all of this moved into IBR2 in The Future™ (once SASL2, IBR2, etc2 are in shape) - Georg says this is the intended goal: they will be referenced in 0401 once it's ready; but, until then, the status quo is documented in ibr-token and referenced from 0401. 7) Close Thanks all and everyone. [1] https://mail.jabber.org/pipermail/standards/2020-November/037846.html [2] https://mail.jabber.org/pipermail/standards/2020-November/037852.html [3] https://wiki.xmpp.org/web/Board_and_Council_Elections_2020 [4] https://gitlab.com/xsf/xeps/-/merge_requests/33 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Need sanity check on an example in XEP-0393: Message Styling
I'm afraid this might still be a little ambiguous. "Matches of spans between two styling directives MUST contain some text between the two styling directives, otherwise neither directive is valid." So where does this leave "**text*" as an example? If 'neither directive is valid' does that mean the second asterisk wouldn't be a valid open simply because it wasn't a valid close when paired with the first? Should the implication be that "neither directive is valid when considering this sequence as a span," while still allowing the possibility of the second being an open for another span? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Need sanity check on an example in XEP-0393: Message Styling
I'd actually be tempted just to change it to explicitly format sequential runs
of the same directive, and remove the intervening text requirement - i.e.
{***}, which is how I'd expect it to appear as a user.
It clears everything up nicely, and apparently no implementations have taken
notice of that anyway.
After a long and productive conversation with Ted, I think I have a
better understanding of this situation and the answer is that it's just
underspecified and there are multiple valid interpretations of "***" and
"" depending on how you build your parser (though I would still very
much love to get other opinions).
This is not likely to matter in the real world, but it's also not ideal.
I've written implementations that work both ways, so I wanted to see
what existing implementations do, and have come up with the following
list (things in square parens are bold, each set of asterisks was sent
as a separate message):
Conversations: ** [***]
Dino: [**] [***] []
Gajim (not technically message styling): nothing bold
Yaxim: Nothing bold
Converse.js: Nothing bold
Spark: Unsure (does not make styling directives bold at all, just the
enclosed text)
Interestingly, Converse.js and Dino both do things incorrectly
(regardless of which rules you follow) if you actually send "** ***
" on one line and appear to be able to wind up with unmatched (but
highlighted) directives.
Unfortunately this means that either way I clarify it I'd break some
existing application. I'd be curious if others think one way is better
than another. Luckily this isn't the kind of thing that's likely to be a
problem or confusing in the real world for real users.
—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
