Re: [Standards] Security issues with XHTML-IM (again)
On 2017/10/13, Kevin Smith wrote: > > So I’d like to strike “Stupid people will do stupid things” from the agenda > of the discussion, and move it towards “What do we need so that diligent but > fallible people are likely to get it right”. The problem is that you can't just get rid of this argument. I also saw you write in xsf@: > I'd really like the discussion to move away from "People will do what's easy, > not what the spec says" Context: Ge0rg saying that people could use markdown libraries that would not entirely be in sync with the spec. This ^ is exactly what is happening with XHTML-IM at the moment, and that's what started this thread. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Security issues with XHTML-IM (again)
On 2017/10/12, Jonas Wielicki wrote: > TL;DR: I strongly prefer revising XHTML-IM to a more sane subset of XHTML > plus > providing a reference implementation of a sanitizer in JavaScript over > anything else. I strongly agree with this. I don't think that getting rid of XHTML-IM and introducing $NEW_MARKUP is going to fix things, the issue is not here. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0337 Event Logging: Why is PubSub discouraged?
Hi Standards, I came across 0337 and I like the idea. Reading the security considerations, it is said in [7.3.2]: """ [..] even more care should be taken to log only information that can be published openly. If there's risk for sensitive information to be logged, the publish/subscribe pattern should be avoided. """ As PubSub does have access models, I am not sure I understand the risks mentioned in this paragraph. Does anybody have any insight on why this was written this way? [7.3.2]: https://xmpp.org/extensions/xep-0337.html#sect-idm140133614364832 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Security issues with XHTML-IM (again)
On 2017/10/14, Jonas Wielicki wrote: > PART A > > Okay, there has been some discussion in xsf@ yesterday which changed my mind > a > little. The key point which convinced me was that Dave brought up the concept > of protocol breaks, and implied that a protocol break [1] is the only way to > prevent this kind of injection attacks [*]. > > Now this makes a lot of sense, and I can see that this trumps the elegance of > > leveraging that we can embed XHTML semantics into the XML stream directly. So > I’m now on the position that XHTML-IM is harmful (I’ve been there before, > which is why I proposed fixes) *and* that we indeed might want to move to a > different type of markup as intermediate representation of the protocol break. I can definitely see the benefit in this, but I see this mostly as an implementation detail. Having XML->NotXML and not XML->XML would make it a bit more obvious, but one cannot get rid of validation. I would like to reiterate that not validating/filtering XML, particularly in web clients, will lead to vulnerabilities, and so this is a much bigger issue, and not specific to XHTML-IM. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Body Markup Hints
I am going to repeat what I said on xsf@ a bit. On 2017/10/16, Florian Schmaus wrote: > So the case for BMH are things like > - Bots sending potential large status information, where there's a > desire to bring some structure into that information by using a markup > language This can be achieved with XHTML-IM already. > - Bridges sending textual content which is already formatted using a > certain markup language to an XMPP client (guess who is currently > writing on a discourse to XMPP bridge *cough* *cough*) This can also be achieved with XHTML-IM. The bridge developer would know what markup is being used on the other side, and could translate it directly for each client, thus sparing clients from each having flawed/vulnerable implementations. > It was pointed out that this could also be achieved with XHTML-IM, which > is, of course, true. > But not every client implements XHTML-IM. Not every client implements $MARKUP. > And there are the security implications of XHTML-IM. This is being discussed on another thread, though, how does that compare to vulnerable markdown implementations? Thanks, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Body Markup Hints
On 2017/10/16, Maxime Buquet wrote: > I am going to repeat what I said on xsf@ a bit. > > On 2017/10/16, Florian Schmaus wrote: > > So the case for BMH are things like > > - Bots sending potential large status information, where there's a > > desire to bring some structure into that information by using a markup > > language > > This can be achieved with XHTML-IM already. > > > - Bridges sending textual content which is already formatted using a > > certain markup language to an XMPP client (guess who is currently > > writing on a discourse to XMPP bridge *cough* *cough*) > > This can also be achieved with XHTML-IM. The bridge developer would know > what markup is being used on the other side, and could translate it > directly for each client, thus sparing clients from each having > flawed/vulnerable implementations. > > > It was pointed out that this could also be achieved with XHTML-IM, which > > is, of course, true. > > But not every client implements XHTML-IM. > > Not every client implements $MARKUP. > > > And there are the security implications of XHTML-IM. > > This is being discussed on another thread, though, how does that compare > to vulnerable markdown implementations? Just to clarify a bit, I can see a point for the XEP, that could indeed help clients identify $markup. Be it markups that are randomly being implemented by other clients lately, or anything that comes from different sources and where the user doesn't convert it for $reasons to its client's markup of choice, (though clients allowing this would have to allow the user to specify what they're using, and not defaulting to one.) I fear though that most would take the easy road and have this become a replacement of XHTML-IM, even if you say these are not the motivations behind. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Body Markup Hints
On 2017/10/18, Jonas Wielicki wrote: > On Mittwoch, 18. Oktober 2017 20:09:28 CEST Florian Schmaus wrote: > > On 18.10.2017 19:58, Jonas Wielicki wrote: > > > On Mittwoch, 18. Oktober 2017 18:12:54 CEST Florian Schmaus wrote: > > >> The situation BMH tries to improve is the following: I do have a bunch > > >> of data formatted using a markup language, say CommonMark, that I want > > >> to send over XMPP to an XMPP client. Because there is no converter from > > >> CommonMark to XHTML-IM(-NEXT) and since I don't want to write one (for > > >> various reasons), I'm just going to stuff CommonMark into . > > > > > > I think if you’re doing that, you’re already doing it wrong. Really. There > > > should be a separate non-body element for markup, and body should only > > > contain simple, unformatted plain text > > > > How would you image a plain text version of CommonMark to look like? > > Ugh. Now I actually see your use-case. Somehow I lost that, probably because > I > mentally mixed the XHTML-IM thread and this ProtoXEP. I apologize. I definitely see the use case for this XEP, (even if I disagree with its usefulness), and I am purposefully mixing it with the XHTML-IM/$markup thread, because it is deeply related, even if it's not Flow's goal. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Security issues with XHTML-IM (again)
On 2017/10/18, Jonas Wielicki wrote: > On Mittwoch, 18. Oktober 2017 10:57:19 CEST Sam Whited wrote: > > On Sat, Oct 14, 2017, at 07:06, Jonas Wielicki wrote: > > > (b) The ecosystem will fracture in islands of different, underspecified, > > > > > > plain-text markups put in . > > > > With (b) I think that's only likely to happen if the council decides to > > accept multiple different formatting specs as experimental and work on > > all of them in parallel. With my council hat on, I don't think that's > > likely to happen. > > I’m not confident that (b) is not going to happen. We are already seeing > implementations massively endorsing use of some type of markup in . > > But I see your point and I’m not as opposed as I was before. Thanks for > taking > the time to discuss this. > > > I would also be interested in a protactive measure to > > prevent this, say, starting a group to come up with requirements and > > eventually a spec for the next generation of formatted messages (this is > > something I was already planning on proposing, I'm sure many people who > > have spoken up on this list would be interested in working together > > towards a single spec). > > I am very much interested here. Count me in. I don't want to shut all doors, but I have a hard time seeing what benefit this will bring. I only see wasted time and effort, and years of incompatibilities and tensions between clients. All of this to bring more or less the same product on the table, in a slightly modified way. We have one XEP that allows embedding rich content in messages, and that is XHTML-IM. I do agree that the XEP is not perfect, and that we can garnish it a bit more with security recommendations, etc., but in general it does the job. Replacing it with JSON or another specified format will certainly lead to the same kind of issues that start this thread. Yes, developers have to be careful, and no, not everybody is. Once we've reached this stage I don't think there is any point in discussing if it's going to be more or less prone to vulnerabilities. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0392: Consistent Color Generation - Issues using JID
Hi there, A few remarks regarding 0392 after having it implemented in poezio, thanks to Jonas. Using JIDs as the source for the hash brings at least an issue to me in MUCs. You'll see the same person in different colors depending on what room you're looking at. Another point I feel about but I don't know how to defend is that people not using MSN would see their different nicks colored the same. Thanks, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0045: Handling presence type='error' coming from s2s
Hi Standards! I have been trying to find indications on how to handle the following kind of presence in MUC (and any other valid error): ``` ``` This discussion started with a potential issue in prosody[0]. This is the answer that I get from it when the payload above happens: ``` Kicked: undefined condition http://jabber.org/protocol/muc#user";> ``` This is displayed as a kick in clients I've tested with, like gajim or poezio. Some display nothing (conversations, dino), I suppose it is handled like any presence, or bug? as this should be a kick if I'm correct? Maybe the presence of `` at the top-level and `` is confusing? I would like if anybody could point me in the right direction! [0]: https://prosody.im/issues/939 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045: Handling presence type='error' coming from s2s
On 2017/12/15, Maxime Buquet wrote: > Some display nothing (conversations, dino), I suppose it is > handled like any presence, or bug? as this should be a kick if I'm Small clarification here after talking to daniel, Conversations displays kicks to the person who's been kicked but not to others. Apparently that's the expected behaviour. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] 34C3 XMPP meeting minutes
Hi Standards, Below are a few notes of an unofficial meeting held during the 34C3 at Leipzig. There was 18 attendees, among which a few client/lib developers, XEP authors, XSF members, and other generally interested people. Thanks to all attending. https://events.ccc.de/congress/2017/wiki/index.php/Session:XMPP Agenda: - vcard avatar on rooms - vcards avatars on pubsub nodes - Tooling (Compliance Tester, TLS tester, uptime monitor -> aggregating to human readable short list of recommended servers). - Exchange about the DOAP proposal by Link Mauve (contrary to the previous point, about implementation rather than deployments), see the [DOAP thread] on standards@. - About e2ee, proposal to make the [OX stanza container example] a separate XEP, and use it in OMEMO. [DOAP thread]: https://mail.jabber.org/pipermail/standards/2017-August/033123.html [OX stanza container example]: https://xmpp.org/extensions/xep-0373.html#example-2 ## VCard avatar on rooms - Would clients/libraries break if MUC services started sending presences from their bare JID? - MUC vcard already implemented in ejabberd and used by Movim, but requires polling. - Link Mauve being volunteered for writing/modifying a XEP. ## Tooling / TLS Tester, Uptime Monitor / List of recommended servers - Need for a list of services that can be used as recommendations in clients, and/or by client developers. - Current tools that generate/use such a list (not necessarily fully automated yet): * TLS Tester (xmpp.net), * Conversation's compliance tester. - Updating a server entry on the TLS Tester is a manual operation. The suggestion would be to run tests against services regularly. - Also need to take into account non-metrics data such as service policies, (e.g., EULA), who runs the service, where, etc. - Some client devs would rather use the list themselves (not automatically fetched into the application) and include servers they think better meet requirements for their app, and propose that to users. ## DOAP Proposal - Documenting client metadata for automatic use https://mail.jabber.org/pipermail/standards/2017-August/033123.html - How is "support" of a XEP defined. (XEP reading subject to interpretation etc.) - How much information is needed? Do we just want general information? Do want details such as MDN includes for HTML, Javascript, etc. (e.g., JS functionX supported by BrowserX.Y, bugZ also opened) - Who would publish it? Suggestion is client devs on their website, with the current PR system against xmpp.org. ## E2EE - full stanza encryption Proposal to more or less take the [example 2] of the [OX XEP], -- container inside `` that contains to-be-encrypted elements -- and make it its own XEP. - Whether to replace elements into the enclosing message, replacing everything, or to wipe its content and interpreting the encrypted payloads as the only ones in the message. - See [Daniel's post to standards@] about what elements from the outer stanza is going to be processed after decryption. This should be a **very** strict whitelist. - Complaint about having to fire up the parser once more (mostly handwaived by the current method invoking a protobuf parser every time). - Daniel proposed to start the discussion with current XEP authors. After the meeting: - [Encrypted Session Negociation] is already a thing and does full stanza encryption, but it is only implemented in Gajim. What is wrong with it? Why is nobody using it? What can we learn from its full-stanza encryption method? [Daniel's post to standards@]: https://mail.jabber.org/pipermail/standards/2017-December/034028.html [Encrypted Session Negociation]: https://xmpp.org/extensions/xep-0116.html [OX XEP]: https://xmpp.org/extensions/xep-0373.html [example 2]: https://xmpp.org/extensions/xep-0373.html#example-2 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0283 Moved - Security and Usability
On 2018/03/09, Georg Lukas wrote: > 1) the Security Considerations spoil all the fun of automatic account > transfers: > > | In order to prevent other users from maliciously altering contacts the > | client SHOULD NOT automatically subscribe to a JID when it > | receives an unsubscribe and SHOULD NOT automatically unsubscribe to a > | JID when it receives a subscribe. > > I think that if our contact proves ownership of both accounts by > publishing a element on each, containing the respective other > JID, there should be no security problems with automatically replacing > the contact's JID on our roster. > > While in theory, someone with short-term access to our account will be > able to permanently steal all our contacts, I would consider that > account as fully compromised anyway, and the attacker can well perform > any other kind of impersonation or social engineering attack they want. I'm all in favour for this! -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
On 2018/03/20, Jonas Wielicki wrote: > On Dienstag, 20. März 2018 19:12:57 CET Georg Lukas wrote: > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > Title: Bookmarks 2 (This Time it's Serious) > > > > A number of issues I have with the current Bookmarks XEPs, and that I'd > > like to see addressed in the mid-term future (ideally by adding them to > > Bookmarks2): > > > > 1) Auto-Join > > > > The 'autojoin' flag name is a bit misleading in the time of always-on > > clients. Maybe we should change the text to indicate that a client is > > supposed to join and stay joined(!) if this flag is set, and maybe also > > to automatically leave when the flag is unset. > > I’d argue that clients should always stay joined in MUCs the user hasn’t > explicitly left. So autojoin is just saying "join the MUC on startup" (and > thus, by extension, stay joined). Agreed with Jonas. A user should explicitely leave the MUC. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
On 2018/03/21, Sam Whited wrote: > On Wed, Mar 21, 2018, at 12:01, Kevin Smith wrote: > > I’d argue (and did at the Summit) that the opposite is true and that if > > we want (especially impromptu) MUC to start working nicely across > > multiple accounts we need clients to react to the user leaving rooms > > manually by disabling the autojoin and then having other clients leave > > as well. They only joined because the autoflag was set, so isn’t it > > logical for them to leave when it’s no longer set? > > I agree with this; when I do something on one client, I almost always want it > synced to my other clients. Room joining and parting is the same. Similarly, > just because my connection dropped and came back up a moment later doesn't > mean I should suddenly not be joined to rooms anymore. If I'm in a room, I > should autojoin it from all my clients on startup, if I close the room, it > should close immediately in my other clients and no longer be autojoined on > startup. When I do join or part on one client, I almost never want it synced to my other clients. I have pretty different use between clients. If my connection dropped and came back a moment later, I would want my client to rejoin MUCs I was in. I use bookmarks mostly as a way to remember MUC JIDs, not to know which state my clients should be in. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
On 2018/03/21, Maxime Buquet wrote: > On 2018/03/21, Sam Whited wrote: > > I agree with this; when I do something on one client, I almost always want > > it synced to my other clients. Room joining and parting is the same. > > Similarly, just because my connection dropped and came back up a moment > > later doesn't mean I should suddenly not be joined to rooms anymore. If I'm > > in a room, I should autojoin it from all my clients on startup, if I close > > the room, it should close immediately in my other clients and no longer be > > autojoined on startup. > > When I do join or part on one client, I almost never want it synced to my > other clients. I have pretty different use between clients. > > If my connection dropped and came back a moment later, I would want my > client to rejoin MUCs I was in. I use bookmarks mostly as a way to > remember MUC JIDs, not to know which state my clients should be in. To complete the above, to summarize and see if I understand what you want exactly: if a bookmark is set to autojoin=false, then all my clients should part or not join this MUC. This seriously disrupt my workflow, and I don't think there is any other equivalent at the moment, is there? Can I propose to dissociate the bookmarking from the syncing bit? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)
On 2018/03/22, Matthew Wild wrote: > We're discussing the protocol, but there is nothing stopping clients > having their own overrides (i.e. local autojoin rooms). This could be > as simple as, when you join a room for the first time "Do you want to > join this room on all devices?" -> if the user answers positively, > then a bookmark with 'autojoin' is set. If not, a bookmark may still > be set, but the autojoin flag is only remembered locally. I agree with the local overrides, mostly what I am (should be) doing at the moment. > And while we're here, I think "autojoin" is a silly concept. A client > should just remember what rooms it has open, and keep them open. If I > close my client and re-open it (or it crashed, or my computer crashed, > etc.), I'd expect to still be in the same rooms, unless I explicitly > asked it to leave them. Indeed. > > If my connection dropped and came back a moment later, I would want my > > client to rejoin MUCs I was in. I use bookmarks mostly as a way to > > remember MUC JIDs, not to know which state my clients should be in. > > That's fine, and I see that as a completely valid use of the protocol. > Just don't set autojoin on any of your bookmarks, and use clients that > remember which rooms they are joined to. One of your comments in another branch of this thread suggests this would not be possible anymore, also similar to what SamWhited said above: > My argument is slightly different, I'm arguing that removing autojoin > should cause clients that joined automatically to leave automatically. It's not exactly said like this, but I would read this as "if autojoin is false, leave the room and/or don't join it.". You suggest that this would only be the case when first joined automatically though, which is different from what SamWhited said above, and probably fixes the issue I have. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0045 Room (JID) aliases
Hi Standards, I was wondering if it was possible to have aliases for a chatroom. Say I want to have foo@muc as a proper room, and bar@muc as an alias, joining bar@muc would make me join foo@muc instead. Is there a solution for this already? I was told to have a look at `` (10.9), but it does seem a bit under-specified: > The address of the alternate venue MAY be provided as the value of the > element's 'jid' attribute When I send this element with a jid attribute to prosody or ejabberd, every participant gets an unavailable presence, with a `` child. But the server doesn't remember and next time I join bar@muc, it creates the room again. I am also curious about client support, poezio doesn't do anything with this 'jid' attribute at the moment. Though, tbh this seems a bit convoluted for an alias. Thanks! -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 Room (JID) aliases
On 2018/05/01, Dave Cridland wrote: > On 1 May 2018 at 00:43, Maxime Buquet wrote: > > > Hi Standards, > > > > I was wondering if it was possible to have aliases for a chatroom. > > > > Say I want to have foo@muc as a proper room, and bar@muc as an alias, > > joining bar@muc would make me join foo@muc instead. > > > > Is there a solution for this already? > > > > > Well, no... But given your description this is something that could be done > entirely server-side, isn't it? > > (Assuming "@muc" really does mean the same domain in both cases). Yes I had in mind to stay on the same domain. > Why did you want to do this? I wanted to have fancyname@muc and serious-business@muc, pointing to the same room. For this particular use case an alias might be best, The component knows what other has joined what JID and speaks to them via this JID. I would also be ok with a redirect though, having the component state "business happens _there_". Redirect implies client support I assume, but that would also allow for redirects to other components. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 Room (JID) aliases
On 2018/05/01, Dave Cridland wrote: > > I wanted to have fancyname@muc and serious-business@muc, pointing to > > the same room. > > > > For this particular use case an alias might be best, The component knows > > what other has joined what JID and speaks to them via this JID. I would > > also be ok with a redirect though, having the component state "business > > happens _there_". > > > > Redirect implies client support I assume, but that would also allow for > > redirects to other components. > > > > > Right. > > But if you have it in the same domain, then the domain can manage all this > without the client being at all aware - there's no need for a specification > here, since you're just using the existing one. Which existing one? Can you point me to the place in 0045 for this? Or are you talking of 0045 in general? In this case it would just seem like an implementation detail (the aliasing) and nothing actually specified? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 Room (JID) aliases
On 2018/05/02, Florian Schmaus wrote: > On 01.05.2018 13:03, Maxime Buquet wrote: > > On 2018/05/01, Dave Cridland wrote: > >>> I wanted to have fancyname@muc and serious-business@muc, pointing to > >>> the same room. > >>> > >>> For this particular use case an alias might be best, The component knows > >>> what other has joined what JID and speaks to them via this JID. I would > >>> also be ok with a redirect though, having the component state "business > >>> happens _there_". > >>> > >>> Redirect implies client support I assume, but that would also allow for > >>> redirects to other components. > >>> > >>> > >> Right. > >> > >> But if you have it in the same domain, then the domain can manage all this > >> without the client being at all aware - there's no need for a specification > >> here, since you're just using the existing one. > > > > Which existing one? Can you point me to the place in 0045 for this? > > I think what Dave means is that a MUC service could simply merge two > rooms, so that all participants appear in both rooms and both rooms have > a single configuration, subject, etc. As a muc admin, how do I tell the muc component that I want this feature? Maybe this can be specified somewhere? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0045 Room (JID) aliases
On 2018/05/02, Maxime Buquet wrote: > On 2018/05/02, Florian Schmaus wrote: > > On 01.05.2018 13:03, Maxime Buquet wrote: > > > On 2018/05/01, Dave Cridland wrote: > > >> But if you have it in the same domain, then the domain can manage all > > >> this > > >> without the client being at all aware - there's no need for a > > >> specification > > >> here, since you're just using the existing one. > > > > > > Which existing one? Can you point me to the place in 0045 for this? > > > > I think what Dave means is that a MUC service could simply merge two > > rooms, so that all participants appear in both rooms and both rooms have > > a single configuration, subject, etc. > > As a muc admin, how do I tell the muc component that I want this > feature? Maybe this can be specified somewhere? I realize I should have been more precise. There's no need for more specs if you assume the operator is the one making the change here indeed. I'll try to come up with a PR. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0384] OMEMO: MUST silently discard [..]
Hi Standards, When trying to implement OMEMO support in poezio, I came across a few points that make me shiver like chalk on blackboard each time I read them. All 3 points are in https://xmpp.org/extensions/xep-0384.html#usecases-messagesend. > When an OMEMO element is received, the client MUST check whether there > is a element with an rid attribute matching its own device ID. > If this is not the case, the element MUST be silently discarded. > If the element's contents are a SignalMessage, and the client has a > session with the sender's device, it tries to decrypt the > SignalMessage using this session. If the decryption fails or if the > element's contents are not a SignalMessage either, the OMEMO element > MUST be silently discarded. > If the OMEMO element contains a , it is an OMEMO message > element. The client tries to decrypt the base64 encoded contents using > the key and the authentication tag extracted from the element. > If the decryption fails, the client MUST silently discard the OMEMO > message. Can anybody explain why as a library dev I would want to silently discard messages and not let the end-users know they just lost messages? So that they can then take appropriate actions, (e.g., ask the other party to resend, file a bug in the library). I understand that in these cases the library is not able to decrypt these messages. My point is to let users know. Is there a reason I should respect these MUST? What happens if I don't? Is there any security/privacy implications? I would love to see a rationale added alongside if it is the case. Cheers, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: MUST silently discard [..]
On 2018/12/01, forenjunkie wrote: > Hi, > As Daniel wrote, MUST is probably to strong here, it is enough to mention > that it can lead to problems if you dont discard such messages. As I am not especially knowledgeable on OMEMO or the implications yet, I would appreciate if somebody PR'd against the XEP to change this, and provide some kind of rationale. If it's just a matter of s/MUST/SHOULD/ for these 3 cases, or even MAY, I can do this. > If you have a client that always shows the user if a decryption fails, this > also means you need a client that has absolute perfect deduplication in any > kind of scenario. I would prefer to send too much than not enough. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0283 (Moved) - offline/shutdown servers
Hi Standards, I had the opportunity to discuss with people interested in at the 35C3. The current state of is not ideal, it is pretty much ephemeral, and I Ge0rG has been working on it, and we've been discussing it at the Düsseldorf sprint[0]. I'll keep this thread focused on my question though, this is to provide a bit of background. One question that came back was how to cope with servers going offline, or shutting down. When this is the case, a user has no way to prove their identity. What was suggested from a user at CCC (owl, for credit), was to be able to define "metacontacts". Not in the way of 209[1], where metacontacts are purely a client-side feature, but as something that a user would be able to declare for themselves. userAB has accountA and accountB, they tell their contacts that both accounts are their own. In the context of , when serverA if offline, userAB wants to tell their contacts that they are moving their main account on accountB. AccountB now has the authority to do this, as accountA has agreed beforehand. This should probably get its own XEP and does not need to be linked to specifically. This is also pretty much at the "thoughts" level at the moment, and there are lots of unanswered questions, like the obvious security concerns. Any strong arguments against this? There isn't much to bikeshed at the moment as there isn't anything specified. Are there any resources out there already that are worth looking into? Cheers, [0]: https://wiki.xmpp.org/web/Sprints/2018_November_Dusseldorf/Pad grep [1]: https://xmpp.org/extensions/xep-0209.html Metacontacts -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0345 (Form of Membership Applications)
On 2019/01/12, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0345. > > Note: Since this is a Procedural XEP under control of Board, the Last Call > mail goes to both standards@ and members@ (only for XSF members) mailing > lists. This may lead to fragmentation of feedback. The archives of the lists > are at [1] and [2] respectively. > > Title: Form of Membership Applications > Abstract: > This specification outlines the form and mandatory content of > membership applications. > > URL: https://xmpp.org/extensions/xep-0345.html > > This Last Call begins today and shall end at the close of business on > 2018-01-27. > > Please consider the following questions during Last Call and send your > feedback to either or both of the members or the standards discussion list. > > 1. Is this document needed to fill gaps in the XMPP Standards Foundation's > policies and procedures, or to clarify an existing XSF policy or procedure? Yes. I just reread the bylaws, and there does not seem to be any indication of what information is required to apply for membership. > 2. Does the document address the problem stated in the introduction and > requirements? Yes. > 3. Should the XSF adopt this document as part of its policies and procedures? Unsure. See concerns / questions below. > 4. Do you have any concerns about the effects of this policy? §2 of the XEP -- "Who May Apply" -- specifies that it is not normative, but it states: > only "natural persons" The bylaws directly conflict with this in §2.1 "Admission of Members": > [..] to be eligible for membership, a person, corporation, organization, > or other entity [..] This is confusing to say the least. Another concern that has surfaced not so long ago, and which is the reason of this LC, is about requiring a Legal Name, §6 "Mandatory Information". Would it be possible to know if there is actually any legal requirement for this? Board members are not actually required to be members to apply. As for council, do they have any legal authority? It was also mentioned on xsf@ that using a pseudonym might be used to apply for membership multiple times, and thus influence votes. When in reality, I could just as well use a Real-looking name, since I don't think there is any verification in place. If legal name becomes a requirement, will we have to do verifications? I am personally not for enforcing the legal name if there is no legal requirement. > 5. Is the document accurate and clearly written? Not entirely sure what "accurate" is supposed to mean, but the document is clearly written. Cheers, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] One true final way to mark up messages
On 2019/03/27, Sam Whited wrote: > On Wed, Mar 27, 2019, at 17:14, W. Martin Borgert wrote: > > 0393 is not bad, IMHO. It might need two or three additions, esp. > > hyperlinks, but most typical use cases are covered. > > What is the use case for hyper links and who does it benefit? I > keep hearing people say they want them, but I don't really > understand why they're necessary over just auto linking things that > look like URLs. Thanks. At work we use Mattermost (Slack-like alternative). Mattermost allows one of the many markdown variants to be used[0]. Out of about 100 people, I see hyperlinks being used every single day. Of course autolinking is also used (when it doesn't fail), but people also seem to be using them to shorten the displayed sentences[1], or provide a bit of context to a link. For example: "I'm working on [implementing that teleport machine](https://linktoourtracker.company.com/T12345) we talked about. See also [that related ticket](https://linktoourtracker.company.com/T12346)." [0]: https://docs.mattermost.com/help/getting-started/messaging-basics.html [1]: Yes, Mattermost doesn't allow me to disable this formatted display. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Markdown needed by a modern messenger [WAS One true final way to mark up messages]
On 2019/03/27, Sam Whited wrote: > > > On Wed, Mar 27, 2019, at 19:33, Ненахов Андрей wrote: > > How do I turn off markdown processing on your side? I don't even know > > you do have some thing that misformats my message despite having no > > intent to be misformatted that way. This is especially a problem when > > someone is trying to pass parts of computer code or config. > > What I'm saying is that *I* want to decide what messages I receive look > like, why would I want you to be able to arbitrarily turn on or off *my* > formatting? If you send me a message, I should be the one to decide if I > use your plain text fallback (eg. *bold*) or the actual markdown (bolded > text). You shouldn't get to decide what I see and don't see. If you > don't want me to see styling, don't send me something with styling > directives. I agree with this. I agree with this so much that I fail to see how you relate that to 0393. In 0393, there is no "sending client" per se, there is only receiving clients. One cannot distinguish between intended and accidental markup. I, as a receiver, can choose not to display markup, or to display what may or may not be markup. Also with 0393, I as a sender cannot ensure the semantic meaning will go through. I generally use "*foo*" to indicate an action. This has nothing to do with bold. My next "*foo*" might actually just be bold, but you can't distinguish between the two. I would like to be able to tell you that, so you(r client) make(s) the correct decision when displaying it. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
On 2019/03/26, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Automatic Trust Transfer (ATT) > Abstract: > ATT specifies an automatic transfer of trust in public identity keys > used by the end-to-end encryption protocol OMEMO. > > URL: https://xmpp.org/extensions/inbox/automatic-trust-transfer.html In the series of body semantics rants, I feel the need to mention that I don't like the wire format. I don't see any reason to overload body semantics with this new feature. Clients that don't support this XEP won't be able to do anything with it and that would only appear raw to the user who would most likely be clueless about it. Is there anything we can do here? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Automatic Trust Transfer (ATT)
On 2019/03/29, Maxime Buquet wrote: > On 2019/03/26, Jonas Schäfer wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Automatic Trust Transfer (ATT) > > Abstract: > > ATT specifies an automatic transfer of trust in public identity keys > > used by the end-to-end encryption protocol OMEMO. > > > > URL: https://xmpp.org/extensions/inbox/automatic-trust-transfer.html > > In the series of body semantics rants, I feel the need to mention that I > don't like the wire format. I don't see any reason to overload body > semantics with this new feature. > > Clients that don't support this XEP won't be able to do anything with it > and that would only appear raw to the user who would most likely be > clueless about it. > > Is there anything we can do here? We did discuss this a bit offline and I'll try to summarize my points and what I understood here. From what I understand this is due to OMEMO only encrypting the , and the melvo wanting[0] to have that ATT payload not being distinguishable from any other encrypted payload. To address the point about OMEMO not doing full/partial stanza encryption I have only one answer: can we please do it already. This is hurting so many other specifications as well. As for the second point, not wanting an attacker to be able to distinguish that payload from any other, I have a few non-crypto-aware thoughts about it. My first though was: End-users do not do fingerprint verification anyway, their only possible threat model is to protect against a passive attacker, and thus this is not big deal. This does not work in the context of ATT though, because it explicitely requires a trust anchor, (in an OMEMO-only world, fingerprint verification, maybe that would change with EAX, MLS, etc.). For users who do validate then, and thus include an active (server) attacker in their threat model, I still do not think this is such a big deal. In this context, the only thing I can see a server doing is dropping ATT payloads. All this does is putting me back in a non-ATT world. I don't think there is a scenario where the server can forge these payloads. As a client, I am not sure if/how I can detect this automatically though, which might be problematic. I am wondering if it would be possible for an active attacker to some extent to predict when these ATT payloads are going to be sent anyway. A really evil server: PEP device_list notification from contactA appears with new device in it, server drops first encrypted message sent right after. With all this said, and if "making ATT payload indinstiguisable" is not a requirement anymore, I hear OMEMO key transport elements could be used to have an tag instead of putting it in the (encrypted) body. I'd love to have somebody give a bit more details on this. [0]: He might not have formulated it this way, or it might not have been a strong point, please correct me if so. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0050 (Ad-Hoc): "next" and "complete" actions
Hi Standards, A Slixmpp user ran into an issue[0] with assumptions that the library has when it shouldn't. When playing with the `adhoc_provider` example of Slixmpp, I realized though that it sends ``, and none of Gajim and Poezio send `complete`. Gajim sends `execute` to progress while Poezio sends `next`. While it does make sense in english, I have not found in the XEP evidence that these steps are equivalent. I am saying this because the XEP explicitely states that `execute` is equivalent to `next` in paragraph 3.4: > The action "execute" is always allowed, and is equivalent to the > action "next". Am I missing something in the XEP? Is it something that is taken for granted? If so should we add something about it? [0]: https://lab.louiz.org/poezio/slixmpp/issues/3432#note_8082 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Compliance Badges, prototype feedback requested.
On 2019/05/23, Guus der Kinderen wrote: > There's an effort under way to have developed visual badges associated to > the XMPP Compliance Suites. I'm not entirely sold on the idea of Compliance Suite the way it is currently, and I'm waiting for that magical answer (maybe, maybe not) that was mentioned during a council meeting some time ago[0]. > To my knowledge, three variants of badges are under development: > >- https://op-co.de/tmp/xmpp-compliance-badges/ >- https://bitbucket.org/mrtedd/compliance-badges/src >- > > https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels > > We're looking for feedback on the visual quality and content of these > prototypes. Anything that will help the authors to improve them, as well as > for us to eventually choose between them, is highly appreciated. First of all I think there's too many combinations available with all the categories, (core, advanced, server/client, web, mobile). However visually I do like the alternative mray on OSD gave us with the different colors, I think it's making it easier to differenciate. I like Tedd's idea of shortening the labels, using "+" (or something similar). And I also like that Ge0rG uses different colors for the different years, even though I don't like these specific colors (especially the red). [0]: https://mail.jabber.org/pipermail/standards/2019-April/036074.html -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Stanza Content Encryption
On 2019/06/24, Dave Cridland wrote: > On Mon, 24 Jun 2019 at 20:11, Paul Schaub wrote: > > Am 24.06.19 um 19:04 schrieb Ненахов Андрей: > > > So much for deniability. > > > > Yeah, I'd rather keep it flexible and let the encryption XEP which > > defines a SCE profile decide, which fields to use and not to use. OX for > > instance should probably use the "full stack" of affix elements, while > > OTR would stay away from most of them (except maybe timestamp). > > > I would rather everything used the same. I think the point of this XEP is to enforce only meaning of elements it provides for other XEPs to use. As Paul said, I also think profiles of this XEP (other XEPs reusing SCE) should define how these elements are used. Somebody might come up with an encryption mechanism that doesn't fit our model of REQUIRED elements. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Stanza Content Encryption
On 2019/06/24, Florian Schmaus wrote: > On 18.06.19 11:03, Philipp Hörist wrote: > > Hi, > > > > Im not quite sure what you want to negotiate, > > Roughly speaking which secured, i.e. encrypted and/or signed, extension > elements an entity is going to send to another entity. We may not have > to negotiate it for all extension elements, but probably for some. > > > but making any part of the > > encryption process depending on disco info of a online resource is a fail. > > Potentially true. Zash already said that "we might have to re-think how > XEP-0030 should work in this new world.", and I believe that we should > do so. We probably need a public PEP node with "user-declared" features > for that (or should the features be announced on bare JID as disco#info > result?). > > > Feature negotiation in encryption process is a fail in General. Its > > simply not needed, we have 2 encryption methods right now (OMEMO and > > PGP) that dont depend on any kind of negotiation and this works fine. > > I do not think that both of those statements are true. It does not work > fine, I receive OMEMO encrypted messages on my non-OMEMO enabled client > all the time. Sure, one can argue that this is by-design and/or somehow > desired behaviour. But maybe we can do better. Also both use some kind > of negotiation, otherwise how do you know that you can send a secured > message using the particular mechanism to the recipient? > I receive OMEMO encrypted messages on my non-OMEMO enabled client > all the time. I assume this is very much a feature indeed. You probably wouldn't like your client to send your message encryption to one device, and plain to another. You also wouldn't like your client to prevent you from sending a message at all I guess? And as the receiver I that I have received a message, even if my client doesn't support it (and this is not the only reason we tend to remove resource-locking nowadays anyway) As Zash said it's pretty much impossible to know where your message will arrive with carbons and MAM. The current way of doing opportunistic encryption seems fine to me: if you can find keys, then it means at least a device has published them and thus supports the encryption mechanism. This discovery mechanism can be defined on SCE profiles. I don't think SCE should worry about this. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Anonymous unique occupant identifiers for MUCs
On 2019/07/17, Jonas Schäfer wrote: > On Montag, 15. Juli 2019 17:57:12 CEST Jonas Schäfer wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Anonymous unique occupant identifiers for MUCs > > Abstract: > > This specification defines a method that allows clients to identify a > > MUC participant across reconnects and renames. It thus prevents > > impersonification of anonymous users. > > > > URL: https://xmpp.org/extensions/inbox/occupant-id.html > > (Council Hat) I am +1 on this. > > I think this should be supported in all modes of operation of MUC, no matter > the anonymity. It helps with things like Message Correction as someone else > has already pointed out. It doesn't especially help with Message Correction in non-anon MUCs, as you can track the identity with the real jid. I also want this anyway, if only to be able to unify the way things are handled. > As to the concern raised by someone about admin tasks: Moderation tasks > should > of course be able to use the occupant-id (future work). Regarding actual > server administration tasks, server admins surely have a way to reveal the > true JID of anyone connected to any MUC on their server, so they can still > ban > the entire domain. The MUC service could also expose such a feature for full- > anon rooms, via Ad-Hoc command or similar, to room owners. I can definitely get behind this. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Backwards compatibility in rich messaging XEPs [Was: Proposed XMPP Extension: Message Reactions]
I assumed this does not apply only to reactions, as you mentioned on xsf@ yesterday, so I'm using this as a start for these comments. On 2019/07/19, Georg Lukas wrote: > 2. Backward compatibility > > This XEP does not provide any way for legacy clients to see reactions. > > This (silently) precludes a large number of users from a subset of the > discussion. I personally don't have an issue with this as a developer. If I want support I can implement the XEP. I am also certain many users wouldn't mind either, as you can see a trend for example in clients not displaying presences anymore and thus making users lose quite some context in discussions (join/parts, nick changes, kick/bans, status, etc.) > I propose(d) the following addition: > > a) Each reaction SHOULD contain a legacy reaction body, consisting of: > > | : (only for group chats) > | > (quotation according to XEP-0393 §5.1.3; > limited to e.g. first line/40chars) > | > > b) the MUST NOT contain any other content than a legacy rendering >of the reaction(s). > > c) a compliant client SHOULD ignore the body element and just obtain the >data from the actual element. > > This would allow legacy clients to see the reaction, making use of > XEP-0393 formatting, and potentially notify the original author by > mentioning their nickname. Apart from the fact that you use the abomination that is 393, I am mostly curious what you're expecting with all this. What is your target? I can see clients easily get away with never implementing any of the XEPs and just using your fallback body, and I am not ok with it. I don't want more pidgins out there getting by doing nothing and tainting the little UX wins we got with recent clients. I also don't want to encourage the use of 393. With what you propose, we're definitely going on the slippery slope that started when 393 was introduced. "Why implement anything else than 393?" I can also see this being misguiding for new developers first seeing this. "It's already there! I don't need to do anything!". Lastly, as a developer you're now forcing me to support the XEP if I don't want to support it (the irony). -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Combining features in disco#info
Hi standards, With edhelas we've been looking at changing XEP-0413: Order-By a bit, for it to be allowed in disco#items requests. Order-By is currently mostly used with PubSub (if it is implemented at all). That is, a PubSub service would advertize it in disco#info, thus meaning that it's possible to use when making a PubSub request. We would want to also be able to say "it's possible to disco#items using on this service". This brings us to a more generic subject, since RSM (0059) has the same issue. Side-note: MAM does require RSM so it shouldn't be necessary to advertize it alongside, but it is usually done. MAM on PubSub is a thing, as well as RSM on PubSub, which could lead to MAM and RSM being advertized on a PubSub service. Does that mean this PubSub service supports RSM or not? We would like to be able to say in disco#info "Order-By is an option of disco#items", or "RSM is an option of PubSub". Ge0rG proposed to use the following: I kind of like it as it reflects the meaning really well, but it seems 0030's schema doesn't allow it so it could get rejected by parsers. Another solution would be to declare features per combination. I don't find it pretty, but it would certainly do the job. Any more suggestions? Has there been any discussion around this in the past? Flow also pointed out that it might not be necessary to advertize RSM for some services, as one could just send a request including it and if they get back RSM then it means the service supports it. (Still annoying when I don't want to get 18k? MUCs in a single result, see conference.jabber.org). This might work for RSM but it won't for Order-By, as we want to have guarantees on the result. Happy Hacking! -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0359: Origin-id - When to include it
Hi standards, I have implemented Origin-id in Slixmpp[0]. I am not entirely sure if it should be included in every single though, is there any business rules concerning this? The XEP almost only talks about stanza-id in there. [0]: https://lab.louiz.org/poezio/slixmpp/merge_requests/21 Happy Hacking! -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Voting Summary 2019-08-18
On 2019/08/20, Dave Cridland wrote: > On Tue, 20 Aug 2019 at 13:03, Georg Lukas wrote: > > * Tedd Sterr [2019-08-18 23:00]: > > > PR #805 - XEP-0060: Add a pubsub#rsm disco#info feature to clear > > confusion - https://github.com/xsf/xeps/pull/805 > > > > +1. I'd prefer to use `pubsub+rsm` and not `pubsub#rsm` (similar to > > +notify, and to make `disco#items+rsm` look less ugly), but this is not > > a hill I'm going to die on. > > > > > I quite like that idea, as well. I don't mind, I can update the PR if that's the preferred option. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0163: Notify after directed presence
Hi standards, I found about this issue while working on the OMEMO implementation in poezio (that should be available soon(tm)), but I guess this can be applied to other things. The issue goes as follows: - Start encrypted chat with non-contact recipient. At this point, my OMEMO code will fetch devicelist and bundles via PEP. - Recipient then updates his OMEMO status (adds a device, removes a devices from the devicelist) - ??? I am not aware of changes as I am not being notified through PEP because of not being a contact. I continue encrypting same as I was before the changes. One obvious answer is to add the recipient as contact, but this might not always fly. Asking quickly in jdev@ [0], I was suggested to use directed presences, and [even if it might not be specified yet?] it would make sense if I now received PEP notifications for items with an access_model of "open". Thoughts? Happy Hacking! [0]: https://logs.xmpp.org/jdev/2019-08-24#2019-08-24-bf845f259b5e8576 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0163: Notify after directed presence
On 2019/08/26, Holger Weiß wrote: > * Maxime Buquet [2019-08-24 20:26]: > > I found about this issue while working on the OMEMO implementation in > > poezio (that should be available soon(tm)), but I guess this can be > > applied to other things. The issue goes as follows: > > > > - Start encrypted chat with non-contact recipient. > > At this point, my OMEMO code will fetch devicelist and bundles via > > PEP. > > - Recipient then updates his OMEMO status (adds a device, removes a > > devices from the devicelist) > > - ??? > > I am not aware of changes as I am not being notified through PEP > > because of not being a contact. I continue encrypting same as I was > > before the changes. > > What about explicitly subscribing to the devicelist node (assuming the > node's access_model allows you to)? That should be doable indeed, but then I'm not sure when to unsuscribe, (which I would very much like to do at some point I think.) Unless I still get directed presences, then it would probably be ok? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Message Retractions
On 2019/09/04, JC Brand wrote: > I just read the latest Council minutes (thanks Ted Sterr!) > and noticed that message retractions came up. > > https://mail.jabber.org/pipermail/standards/2019-September/036391.html > > > Link notes that multiple people have noticed previous Councils appear to > > have forgotten about Message Retraction [3] and, like Reactions, it's > > being held-up by the current 'message attachment' contention. > > I'm a bit out of the loop here, can someone please explain to me what the > "message attachment" contention is in regards to message retractions? There doesn't seem to be any tl;dr on this yet. The idea is that Message Reactions[0] is currently being held hostage[1] by council because there is no """proper""" solution for referencing a message. I suggest you read the thread about reactions if you have time. There was also a (quite long) discussion[2] on xsf@ recently about how to tackle the problem. Funnily enough you're not the only one to ask about Message Retractions lately: - https://logs.xmpp.org/xsf/2019-06-26#2019-06-26-31c023899b7ed4f9 - https://logs.xmpp.org/xsf/2019-08-26#2019-08-26-c043182b2d770bac [0]: https://mail.jabber.org/pipermail/standards/2019-July/036271.html [1]: https://mail.jabber.org/pipermail/standards/2019-July/036322.html [2]: https://logs.xmpp.org/xsf/2019-08-29#2019-08-29-b9d6a6d670715887 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Message Retractions
On 2019/09/23, JC Brand wrote: > Based on our off-list discussion, I'm going to go with sending an IQ to the > MUC > JID in order to ask for a message to be retracted. > > The MUC then sends out the retraction message to all participants. This solves > the problem of temporary moderators retracting messages and clients then later > being unable to verify that the operation was done by someone with the > necessary permissions. > > The MUC can then decide to replace the message with a tombstone in its > XEP-0045 > message history or in the MAM store. > > I guess for MAM tombstoning the MAM service needs to advertise it via disco > and > the client needs to specifically ask for it in the IQ? > > When it comes to one-on-one conversations, I'm not sure what the equivalent > interaction would be given that there isn't a dedicated service as in the case > of MUC and because two MAM archives are involved. Perhaps sending the > retraction message yourself (instead of asking for it to be sent via an IQ) is > the preferred way there. > > I'd be happy to hear some suggestions. I'm leaning towards restricting > the scope of this XEP to only MUCs (and MIX?) and ignoring the one-on-one > usecase entirely. What about looking at it the other way around? 1:1 being the general case and MUC something that modifies/enhances it. In 1:1, one would be able to send a retraction, referring to a previous message that has been sent with the same barejid. I think this should also be possible in MUCs. Additionally in MUCs, one could send an IQ to the room so that the MUC itself broadcasts it to all participants of that room. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Message Retractions
On 2019/09/24, JC Brand wrote:
> On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote:
> > What about looking at it the other way around? 1:1 being the general
> > case and MUC something that modifies/enhances it.
> >
> > In 1:1, one would be able to send a retraction, referring to a previous
> > message that has been sent with the same barejid. I think this should
> > also be possible in MUCs.
> >
> > Additionally in MUCs, one could send an IQ to the room so that the MUC
> > itself broadcasts it to all participants of that room.
>
> I don't like the idea of there being two ways of doing the same thing in a
> MUC.
> IMO there should be only one way of doing this,
I think these can/should be taken as semantically different.
One being retracting your own messages. The other being retracting other
people's messages ("moderating a room"). They're essentially not the
same thing to me.
It might have been mentioned before, but it would make sense to split
them. Rename this XEP "moderation" and keep the "retraction" case for
own messages.
A client implementing both will have to use a similar logic as described
below anyway though.
> and given that sending the
> retraction message yourself can cause problems with verifying validity
A client would have to verify the validity of any incoming retraction
message anyway. Having the MUC broadcasting this for you doesn't mean
you're exempt of spoofing attacks.
Here is an exemple of validation logic:
If retraction message (RM) @type is 'groupchat':
- (Moderation) Check if @from is a barejid and equals room barejid, if not
- (Participant retraction) @from is a fulljid.
- Ensure the fastened message (FM) is of the same type.
- If RM @from is a valid room barejid as defined above, stop here.
- RM is a fulljid, ensure RM's fulljid equals FM's fulljid.
If retraction message (RM) @type is 'chat' or 'normal':
- This is not moderation.
- Ensure the fastened message (FM) is of the same type.
- If message is MUC-PM[0], (and client is joined to this MUC?), ensure @from is
a fulljid,
* Ensure that RM @from equals FM @from fulljid
- If not MUC-PM, ensure RM @from equals FM @from barejid.
This is probably not perfect but I think that's a good start(?)
[0]: Indicated by the presence of
or previous knowledge that the barejid is a MUC (a general problem of
MUC-PMs anyway).
--
Maxime “pep” Buquet
signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Proposed XMPP Extension: Message Moderation
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Moderation Abstract: This specification defines a method for groupchat moderators to moderate messages. URL: https://xmpp.org/extensions/inbox/message-moderation.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Moderation
On 2019/09/25, Maxime Buquet wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Moderation > Abstract: > This specification defines a method for groupchat moderators to moderate > messages. > > URL: https://xmpp.org/extensions/inbox/message-moderation.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. Two small things I noticed: §3.1, "Only then, does groupchat the service respond with an IQ result stanza." Is "Only then" really necessary? Do we need to worry about the order these stanza are sent? §9, Schema. I know this is still a protoXEP, and schema are non-normatives, so I'll forgive you. I just wanted to point it out that it's not matching the XEP very much :P -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0070: SPOF, DoS, and privacy concerns
Hi Standards, I've had this in my backlog for quite some time, and while I am not planning to work on this right away, I thought it might be good to share it anyway. I have looked through the list quickly and I haven't found much about what I'm going to describe. As much as I would like to, I also don't think 0070 is being used much in the wild. I also haven't implemented anything using it yet. 1. The way the XEP is written (as of 1.0.1), it means that web services using 0070 have to use one (or multiple) static endpoint that act as "Single" Point Of Failure. 2. While having a SPOF might be fine in some cases, that single endpoint also now acts as the identity provider for the whole XMPP network as seen from the web service, allowing it to: 2.1 refuse even legit users on (other) servers, 2.2 being able to see the activity of anybody authenticating against the web service, (that is, only when authenticating). All of these issues seem to go away with the use of 0156, introducing a new well-know entry. This has the effect though that it increases the deployment hurdle, (which is already almost non-existent). Thus a web service using 0070 as authentication method might want to poke 0156 on the user-provided JID, and keep using a static endpoint as a fallback. Happy Hacking! -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0070: SPOF, DoS, and privacy concerns
On 2019/09/30, Maxime Buquet wrote: > Hi Standards, > > > I've had this in my backlog for quite some time, and while I am not > planning to work on this right away, I thought it might be good to share > it anyway. I have looked through the list quickly and I haven't found > much about what I'm going to describe. > > As much as I would like to, I also don't think 0070 is being used much > in the wild. I also haven't implemented anything using it yet. > > > 1. The way the XEP is written (as of 1.0.1), it means that web services > using 0070 have to use one (or multiple) static endpoint that act as > "Single" Point Of Failure. > > 2. While having a SPOF might be fine in some cases, that single endpoint > also now acts as the identity provider for the whole XMPP network as > seen from the web service, allowing it to: > 2.1 refuse even legit users on (other) servers, > 2.2 being able to see the activity of anybody authenticating against > the web service, (that is, only when authenticating). Obviously it's only after sending the email that I realized that the XEP might have been intended for web services to run their own HTTP/XMPP component, in which case all of this is moot because they already have the data. There are XMPP services providing these endpoints though already, (such as JabberFR iirc), and I believe it's probably best for adoption if the effort comes from the XMPP side anyway. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: max-items (publish-options et al) council action required
On 2019/10/06, Daniel Gultsch wrote: > Therefor I propose wording for XEP60 that 'clarifies' that max-items 0 > means unlimited. Is there a way to know as a client when we're going to run into the limit? Or when we've gone over the limit? Or is the pubsub service just overwritting stuff and nobody ever noticies? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0423 (XMPP Compliance Suites 2020)
On 2019/10/14, Florian Schmaus wrote: > On 14.10.19 14:28, Georg Lukas wrote: > > * Florian Schmaus [2019-10-11 12:35]: > Please do not mention all MIX XEPs in the compliance suite. The main > entry point to MIX is a single XEP, and this is the only one the > compliance suite should mention. I agree with this. There is no need to mention all the MIX XEPs but the entry point, which already lists them all, and how they interact: https://xmpp.org/extensions/xep-0369.html#family -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0423 (XMPP Compliance Suites 2020)
On 2019/09/11, Jonas Schäfer wrote: > Version 0.1.0 of XEP-0423 (XMPP Compliance Suites 2020) has been > released. > > Abstract: > This document defines XMPP protocol compliance levels. Some feedback, based on the current state of PR[0]. Overall I still don't know what to think about Compliance Suites in general. I do agree though they're improving the status quo for discoverability a bit, so thanks for the continuous work on it. This said, a few things caught my attention as mentioned on xsf@ these past few days. So here it is: I don't think 0392 (Consistent Color Generation) should be included at all. I don't think Council is competent when it comes to UI/UX, as in it doesn't have to be within their expertise, it's not required from them. It's also not what I look for when I vote for council members, it's only bonus. I have a similar opinion when it comes to 245 (this XEP is bad in lots of possible ways), but I'm not going to argue over it because it is implemented in every possible clients one can think of. And I'm already present on too many hills. The mention to "Private XML Storage" should probably refer to a previous version 0048 using it as a protocol, and not the generic storage mechanism, at least for clients. HTTP Upload and OOB are mentioned, but it is not said how to use them together (I am thinking about the ugly hack of body == oob url). We might want to detail this or point somewhere that describes it, as much as I dislike it. May I suggest to add a "Social" category (or any other appropriate terminology) to include clients like Movim or Salut-à-Toi. Such category could contain microblog, and more pubsub related things. I guess edhelas and goffi have more insights about this than me. XMPP is not simply for Instant Messaging. On a positive note, I like the idea of §1.1 "Changes since 2019". I think this is something that is missing on most XEPs as I always find it a pain to have to look for changes somewhere else. I hope this is something that can be worked on in the future. I also liked §3 "Future Development", which makes it clear that what is required by the Compliance Suites is not especially here to last and only the current state. This makes me more enclined to agree with what's being added to the CSs in general. Happy Hacking! [0]: https://github.com/xsf/xeps/compare/master...ge0rg:dd07e90 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0423 (XMPP Compliance Suites 2020)
On 2019/10/15, Maxime Buquet wrote: > I don't think Council is competent when it comes to UI/UX, as in it > doesn't have to be within their expertise, it's not required from them. > It's also not what I look for when I vote for council members, it's only > bonus. This certainly came out wrong, and I'm sorry if I offended somebody. I do mean what I said, but.. not in a bad way :) -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0423 (XMPP Compliance Suites 2020)
On 2019/10/15, p...@bouah.net wrote: > Version 0.2.0 of XEP-0423 (XMPP Compliance Suites 2020) has been > released. > > Abstract: > This document defines XMPP application categories for different use > cases (Core, Web, IM, and Mobile), and specifies the required XEPs > that client and server software needs to implement for compliance with > the use cases. > > Changelog: > Update before LC: > * IM Category: > * Mobile Category: > (gl) > > URL: https://xmpp.org/extensions/xep-0423.html > > Note: The information in the XEP list at https://xmpp.org/extensions/ > is updated by a separate automated process and may be stale at the > time this email is sent. The XEP documents linked herein are up-to- > date. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ Some of you have noticed that the page is not up-to-date yet. Worry not! I sent this before the end of the build. It should arrive at some point (I hear about 1h). -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Members] A Short Note about "Tedd Sterr"
On 2019/11/25, Jonas Schäfer wrote: > On Montag, 25. November 2019 10:45:37 CET Dave Cridland wrote: > > I can't begin to adequately explain how useful this is. The minutes Tedd > > sends out are highly engaging summaries of what happened in the meetings > > and I hope they're as useful to others as they are to me and the rest of > > the Council. > > Very very much. I forgot (I think) to officially thank Tedd Sterr in our last > council session, but I’d like to do it here. The voting summary has been > tremendously helpful for the Editors and to me as a Council member. I think this thread could go on with thanks for a very long time. While there are many people that would need to be thanked, this is Tedd's turn, and I must add to it myself :) Even if I read council meetings on a regular basis and sometimes contribute to these meetings a bit, these regular emails are very helpful for somebody who wants to follow the XSF life. They are also really helpful as an editor to keep track and give us pointers (making things easier to verify). -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]
On 2019/12/30, Dave Cridland wrote: > On Mon, 30 Dec 2019 at 17:16, Philipp Hörist wrote: > > Am Mo., 30. Dez. 2019 um 17:57 Uhr schrieb Dave Cridland < > > d...@cridland.net>: > > > >> That specification isn't linked from XEP-0384 at all, so how are we > >> supposed to be able to tell it affects OMEMO? > >> > > > > You can't, and the XEP does not mandate any specific implementation or > > protocol version of the non-standard SignalProtocol. The XEP says > > > > > The signal protocol currently only exists in GPLv3-licensed > > implementations maintained by OpenWhisperSystems. > > > > So it means, you use the libraries OpenWhisperSystems currently offers and > > if you want to know what they do you read the docs on their page. > > > > I know this is not a beautiful thing in Standards world, but that's what > > it is at the moment. > > > > > The Council has consistently rejected such specifications as a result. I'll > raise this at the next Council meeting, and move to Reject it - it should > be Deferred at this point anyway. I'm curious if you have any viable alternative to propose while you reject the only widely used encryption mechanism? If not, I think doing this is only going to harm the community. "You don't have any standard viable E2EE mechanism", "The only E2EE mechanism that's used is not even standard, how do I do interop?" (Note that this is similar to how aesgcm is currently done, or oob+link, or..) As much as I am concerned with these being adopted by implementations in the first place because. They're here because there was a need that wasn't filled. It feels to me our current process doesn't reflect the reality of things. If you need a standard for your company use-case, OX is a thing. Otherwise maybe in 5-10 years we'll have MLS? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]
On 2020/01/01, Dave Cridland wrote: > On Wed, 1 Jan 2020 at 18:40, Maxime Buquet wrote: > > I'm curious if you have any viable alternative to propose while you > > reject the only widely used encryption mechanism? If not, I think doing > > this is only going to harm the community. > > > I don't think the only harm possible is by rejecting the only widely used > encryption mechanism we have. Another harm to the community is possible by > changing what we are without discussion from a standards group interested > interoperable solutions into a ... well, I honestly don't know what we are > if not that. OMEMO is already the status quo. It got accepted I don't exactly know how (I was just getting in the community at the time) but that's not the point. We don't have any viable alternative and my suggestion is to keep it while we find something else. Yes it's not perfect and that's fine with me. I can think of plenty of other cases that didn't happen perfectly in the last few months and we're still alive. > > If you need a standard for your company use-case, OX is a thing. > > Otherwise maybe in 5-10 years we'll have MLS? > > > Or someone else can publish a non-standard, call it OMEMO. "Someone can publish a non-standard" is exactly what this is, a non-standard. As for OTR, most of the community has been criticising OTR for years, I don't think bringing it back would do us any good. > Or is your view that we should allow XEPs based on specifications and > libraries with restrictive licenses? > > If that is your view, I suggest you raise this at Board level; it would be > a radical departure from previous policy as established by precedent, and > would in my view represent a radical change in the XMPP Standards > Foundation's mission. This would certainly not pass board, but my view about this specific point is not relevant anyways. This should have been thought through when the XEP was accepted. Now we're in it, I say we deal with it. As the XEP hasn't yet been submitted for Draft, this feels to me as coming back on previous council decisions and as I remember you seemed to have an opinion on this. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]
On 2020/01/02, Marvin W wrote: > But this spontaneous "let's get rid of what many use in practice and > what significantly boosted XMPPs popularity in the last years" without a > proper replacement plan makes little sense to me. I can only agree. > > The bigger problem is the change by Daniel back in 2017, that changed > > the specification to be based on the so-called Signal Protocol. It is > > unclear to me if it is possible to implement OMEMO without libsignal > > and/or in non-GPL implementations. If that is indeed not possible, it > > violates one of the XSF Objectives set out in section 2 of XEP-0001: > > > > 4. To guarantee that any person or entity can implement the protocols > > without encumbrance. > > > > And thus, unless this restriction is somehow lifted, XEP-0384 cannot > > progress within our standards process. Eventually rejecting it seems a > > valid course of action to me, and I am not even sure if it can remain > > Experimental or Deferred because of this. > > As mentioned before, we have a a number of Experimental XEPs that cannot > be implemented due to lack of documentation. I don't see why the partial > lack of non-GPL documentation is a bigger issue than the lack of any > appropriate documentation. > > Nobody argues to propose the XEP for becoming a Draft (well Dave just > did, but merely to bypass the rules). I also agree that this is not entirely clear procedure-wise. > > The earlier mentioned MLS effort at IETF specifies a new protocol based > > on the Double Ratchet Algorithm, which would be free to implement for > > everyone. Maybe we should put more effort in supporting this. > > Funny that you mention MLS. I am all for looking forward for MLS, but I > am also pretty certain that the current state of MLS can not be fully > implemented from its documentation (because it is not finished). Also what I said. Maybe in 5 years we'll have a XEP and a few years after we'd have imlementations. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for XEPs to Adavance in the Process
On 2020/01/22, Sam Whited wrote: > And finally (I hope) XEP-0412: XMPP Compliance Suites 2019 [1] and XEP- > 0423: XMPP Compliance Suites 2020 [2] are both in draft, which is just > confusing. The 2019 ones should be obsoleted (which wasn't one of the > original questions, I know, but it seems worth pointing out in a thread > about cleaning up XEPs). https://github.com/xsf/xeps/pull/879 "Obsolete CS-2019" This was voted today by council. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Inbox
On 2020/01/21, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Inbox > Abstract: > This specification proposes a mechanism by which clients can find a > list of ongoing conversations and their state. > > URL: https://xmpp.org/extensions/inbox/inbox.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. The discussion has popped up a few times, but we quickly discussed again keeping the opened tabs/chats in Poezio between restarts yesterday[0]. We already have a "reorder" plugin that does that but it's all manual work atm. One has to edit a text file themselves and then /reorder at runtime to apply (generally not long after starting). You can of course move tabs without any plugin. I was also curious and read Inbox again today, thinking it could help. I am missing important things though, a dumb list of JIDs that I can set and retrieve, also keeping the order in which my tabs/chats are. That seemed to correspond to the abstract of the protoxep so I'm curious if there could be something done about it. [0]: https://lab.louiz.org/poezio/poezio/issues/3515 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))
My answer is a mix of what Sam, Daniel, and lovetox say. :) > This Last Call begins today and shall end at the close of business on > 2020-02-12. > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes > 3. Do you plan to implement this specification in your code? If not, > why not? I have not implemented it yet, but I would. As this spec allows to handle bookmarks separately, it's easier to handle group/Enterprise(tm) bookmarks. The server can return an appropriate answer for a specific bookmark and not reject an update on the whole list without any hint. I also don't understand why the password field has been removed, same as lovetox. While I might agree with a push towards using MUC member-only rooms (I would think that's the intent?), I don't think we're there yet. Password-MUCs are still a reality, and also still used in transports. While a password field could be added to the XEP, I'm curious if anything happened around the issue Link Mauve raised a few weeks ago about allowing for a extensions in the XEP? This would avoid having to rewrite an entire bookmark XEP everytime we think about a new feature. > 4. Do you have any security concerns related to this specification? As Daniel says, it would be good to mention PEP access_model in security concerns. > 5. Is the specification accurate and clearly written? I agree with Sam in saying that the last part of the title is silly, does not add any value, and makes it harder to cite. I like my XEPs dull and straight to the point. On Sunday, 30. January 2020 08:45:22 CET Daniel Gultsch wrote: > Maybe the benefits of Bookmarks 2 over Bookmarks need to be spelled > out more. Otherwise neither developers (as demonstrated by Phililpp) > nor the approving body will know why they should use or accept this > XEP. > > The arguments for 402 I'm raising above are good; but I don’t want to > personally tell them to every developer in order to convince them. > That's the XEPs job. I agree. (and jonas' answer in the thread looks closer to the intent of the XEP already). -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))
On 2020/02/03, Maxime Buquet wrote: > > 3. Do you plan to implement this specification in your code? If not, > > why not? > > I have not implemented it yet, but I would. > > As this spec allows to handle bookmarks separately, it's easier to > handle group/Enterprise(tm) bookmarks. The server can return an > appropriate answer for a specific bookmark and not reject an update on > the whole list without any hint. > > I also don't understand why the password field has been removed, same as > lovetox. While I might agree with a push towards using MUC member-only > rooms (I would think that's the intent?), I don't think we're there yet. > Password-MUCs are still a reality, and also still used in transports. > > While a password field could be added to the XEP, I'm curious if > anything happened around the issue Link Mauve raised a few weeks ago > about allowing for a extensions in the XEP? This would avoid having to > rewrite an entire bookmark XEP everytime we think about a new feature. I forgot to add that the "autojoin" attribute is likely going to conflict with 0430 Inbox' features. Which one should I respect if I implement both XEPs? As Dave authored both it might be interesting to sync up on that. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))
On 2020/02/13, Florian Schmaus wrote: > On 1/29/20 5:33 PM, Jonas Schäfer (XSF Editor) wrote: > > This message constitutes notice of a Last Call for comments on > > XEP-0402. > > > > Title: Bookmarks 2 (This Time it's Serious) > > Abstract: > > This specification defines a syntax and storage profile for keeping a > > list of chatroom bookmarks on the server. > > > > URL: https://xmpp.org/extensions/xep-0402.html > > > > This Last Call begins today and shall end at the close of business on > > 2020-02-12. > > Besides my feedback regarding arbitrary extensions being added by the > client and/or the server, I believe it is a missed opportunity that this > XEP is MUC specific. > > Instead it should be able to also deal with 1:1 chats, MIXes, MucSub, > MUC-light, and all future (group)chat protocols. This also means we no > longer have to discuss if we put MIXes into the roster, instead the > user's server could just inject the joined MIXes into this. The Inbox > XEP would then just provide mechanism to deliver the unread count and > timestamp of unread conversations (potentially linking to the related > bookmark2 node). > > So ultimately this should not be Bookmarks 2, but Roster 2, based on > PubSub [1]. I like the idea -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] UPDATED: XEP-0384 (OMEMO Encryption)
On 2020/03/10, p...@bouah.net wrote: > Version 0.4.0 of XEP-0384 (OMEMO Encryption) has been released. > > Abstract: > This specification defines a protocol for end-to-end encryption in > one-to-one chats, as well as group chats where each participant may > have multiple clients per account. > > Changelog: > * Incorporate the double ratchet protocol specification. > * Use one node to store all bundles. One item per bundle. > * Recommend 'open' access model for both PEP nodes. > * Specify OMEMO encryption for XEP-0045 Multi-User Chats. > * Use XEP-0420: Stanza Content Encryption. > * Use AES256/CBC to encrypt SCE payload. > * Change namespace to 'urn:xmpp:omemo:1' It seems the script didn't pick on up this. Thanks to those who told me :) > * Use wrapping 'keys' element for key elements in 'header'. > * Define threat model (dg) The XEP is also being moved back to Experimental with this update. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Registrar: disco-categories: Add 'telegram' gateway type
On 2020/04/04, Linus Jahn wrote: > Hello, > > I opened a pull request more than 1.5 years ago and received a +1 from > stpeter, > but no further interaction. The pull request was not merged. > > The pull request can be found here: > https://github.com/xsf/registrar/pull/30 > > Can I do something to speed up this? Is writing a mail here the correct way? > > Thanks in advance, Hey Linus, Sorry for the lack of response on this issue. For some reason I entirely missed this. I'm now subscribing to this repo. This is editor realm. The registry has been somewhat "off" for a long time now. I don't know the details but I believe not easy to update because something something infrastructure. As you can see in the xsf/xeps repo[0] some PRs are also blocking on this. I hope iteam gets to have a look at this soon. [0]: https://github.com/xsf/xeps/pulls?q=is%3Apr+is%3Aopen+label%3A%22Needs+Registry%22 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0357 (Push Notifications)
On 2020/04/07, Andrzej Wojcik wrote: > > > > However, can we please stop with JSON encoding in XML "because it's > > smaller". That claim is not true i all cases (not even most) and also > > not in your specific case: > > [..] > > And representation may be smaller in XML unless someone will use characters > which > need to be escaped or until someone will put XMLNS on top of this element. "xmlns" is not just some random keyword people add because they fancy it. It's a namespace declaration and namespaces are not reserved to XML. Any JSON payload could also be namespaced with some fancy rules that people would come up with, and surprise! they did! [0] Sorry I'm also tired of hearing JSON this JSON that supported by all these biased and unfair comparisons.. [0]: https://www.w3.org/TR/json-ld/ -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0393 (Message Styling)
On 2020/05/12, Jonas Schäfer wrote:
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
No.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Partly.
| This specification aims to provide a single, interoperable formatted
| text syntax that can be used by entities that do not require full layout
| engines.
I don't think this format can be defined as interoperable. I also don't
think it solves the issue it describes in XHTML-IM wrt. bugs in
implementations. See security concerns below.
| Messages formatted using this specification MUST NOT hinder
| readability on receiving clients regardless of client background
| color, contrast, or window size.
Not exactly because of background color, contrast, or window size, but
readability will be hindered when a receiving client interprets part of
the message that wasn't supposed to be interpreted.
> 3. Do you plan to implement this specification in your code? If not,
> why not?
No.
I might be ok implementing 393 as the input format for something else.
In general terms, this XEP mixes input format and wire format.
1. It is thus impossible for the sending client to indicate that it is
using this XEP.
Some people seem to see as a fatality the issue that some things the
user types will be wrongly interpreted.
Except that if a client were to properly distinguish markup from
plaintext, there would be no such issue. For example:
- I type "*foo*" in the input, and it directly gets converted to "foo" (in
bold) in the input.
- I type backspace, and the input displays "*foo*" (not bold) again. I
can then continue writing.
- The client sends something meaningful on the wire.
2. It is impossible for a receiving client to know how to interpret the
received payload.
Same story, "it's what users do anyway". I disagree. Users do what their
clients allow them to do.
Applying the method above, a user can type "mark{up,down,left,right}"
for the parts where it matters, using the same sigils (meaningful chars)
as normal chars where it's not the case.
This has been largely ignored and unanswered in the community.
One possible answer was 0394 "Markup", from which the original author is
now retracted and supports the idea of an XHTML-IM2.
0394 also has its flaws, and that can be discussed in a different
thread.
> 4. Do you have any security concerns related to this specification?
Same as the concerns described against XHTML-IM.
It seems developers interpret this XEP as a "markdown" XEP and use
markdown libraries to implement it (which also include HTML parsers),
even if it explicitely introduces sigils that are not matching those of
markdown.
In the same way, developers interpret XHTML-IM as an "HTML" XEP, and use
HTML parsers to interpret unfiltered user input, even if it explicitely
describes a strict subset of XHTML.
> 5. Is the specification accurate and clearly written?
Yes.
--
Maxime “pep” Buquet
signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Server status pages
On 2018/12/03, Matthew Wild wrote: > Hi all, > > I'd like to allow servers to advertise status pages to their users. > See for example https://statut.jabberfr.org/ > > This information could be cached by clients, and linked to in case of > problems connecting, for example. > > The question is where and how to advertise it. Someone suggested it > might fit into XEP-0157, as if you squint hard enough, it is a > communication channel about the service. The link could also be a URL > to a Twitter, Mastodon feed, or whatever. > > This is one possibility, there are others. Anyone have thoughts to contribute? All those who expressed feelings against adding this to 157 at the time you sent this didn't mention why. I personally don't see much issue with it, so I just PR'd against it to add that registry entry. https://github.com/xsf/xeps/pull/949 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Mathieu Pasquet wrote: > Greetings, > > I want to raise an issue that appears with bookmarks in their current > form in the multi-client scenario. It appears as long as we have more > than one client, and gets worse for every added client and MUC bookmark. > > XEP-0048 and XEP-0402 both re-use the element, which has > an autojoin flag. In a single-client scenario this is fine because that > represents what the user wants in terms of joined rooms. In a > multi-client scenario however, that quickly changes as you probably do > not want the same view everywhere. I agree. > The use cases I have in mind are a bit extreme (e.g. people with > 100 > MUCs in their autojoined bookmarks), which are unusable on mobile, for > example, where screen space is limited and you probably want to limit > yourself to the "important" ones. Or when joining big IRC channels with > more than 1000 users, you also do not want that on mobile as that much > activity is never good for battery life, however optimized the client > might be. Even for smaller cases, such as 20-30 rooms, this can be a > limiting factor. > > Bookmarks in themselves only represent MUCs we want to keep in memory, > and that is fine. However tying the "autojoin" attribute in there means > we are now syncing client state, and that is not often desirable, for > the reasons stated above (different constraints, different platforms, > different attention spans). > > The following is probably over-engineered for a nerdy edge case, but one > viable solution would be the ability to manage sets of client "profiles" > which would hold client state independently from bookmarks. This could > be stored in PEP as well, and could be a list of pubsub URIs to the > stored bookmarks. Removing a bookmark would automatically remove the > autojoin in all profiles that link to it. I'm thinking that even if some clients don't want to implement support for multiple profiles, they could "just" implement support for a single/default profile, still allowing advanced clients to use different ones. This would allow for the bookmark list would to be a bookmark list and not a syncing mechanism. That list could be used in various cases where completion/suggestions are helpful. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0430: Inbox and chatrooms [Was: LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))]
Hi Standards, I was reading Inbox again yesterday and I notice that it mentions "chatrooms" twice, but not how it's supposed to work with such chatrooms. How does it work? Is that only meant to work with MIX? If so can that be made explicit? I'm apparently not the first one to notice: On 2020/02/09, Daniel Gultsch wrote: > I think there is less overlap with 'Inbox' as this just gives us > faster access to messages from MAM (and won’t even properly handle > MUCs) than there is overlap with a potentially upcoming 'list of open > conversations'. Thanks, -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Philipp Hörist wrote: > What first comes to mind is, that 402 now can hold extended payloads in > each bookmark item. > So we just add the profile there? Not against the idea, even though I'm not entirely sure how it would work. 0402 is not a bookmark XEP, just like the multiple versions of 0048 are not bookmark XEPs either, they're some loose client state syncing mechanism for chatrooms only. Which is fine but has never been made explicit. So expecting 0402 to behave as a dumb bookmark list when adding this profile extension (that other clients may not support) is changing the semantics of the XEP entirely. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0430: Inbox and chatrooms [Was: LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))]
On 2020/05/24, Dave Cridland wrote: > On Sun, 24 May 2020 at 10:24, Maxime Buquet wrote: > It doesn't actually distinguish between chatrooms and individuals, if you > look closely - it just references the conversation endpoints by bare jid, > which works for 1:1, MUC, and MIX. I'm not sure I understand how it would work for MUC as I need to know it's a MUC already to query to the barejid and not to my account. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0430: Inbox and chatrooms [Was: LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))]
On 2020/05/24, Maxime Buquet wrote: > On 2020/05/24, Dave Cridland wrote: > > On Sun, 24 May 2020 at 10:24, Maxime Buquet wrote: > > It doesn't actually distinguish between chatrooms and individuals, if you > > look closely - it just references the conversation endpoints by bare jid, > > which works for 1:1, MUC, and MIX. > > I'm not sure I understand how it would work for MUC as I need to know > it's a MUC already to query to the barejid and not to my account. Would this depend on @type='groupchat', or.. "bookmarks" etc. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Stefan wrote: > Am Sonntag, den 24.05.2020 um 00:41:53 +0200 schrieb mathi...@mathieui.net: > > The use cases I have in mind are a bit extreme (e.g. people with > 100 > > MUCs in their autojoined bookmarks), which are unusable on mobile, for > > example, where screen space is limited and you probably want to limit > > yourself to the "important" ones. Or when joining big IRC channels with > > more than 1000 users, you also do not want that on mobile as that much > > activity is never good for battery life, however optimized the client > > might be. Even for smaller cases, such as 20-30 rooms, this can be a > > limiting factor. > > I think this is a valid use case and not only for a big set of MUCs. > An idea I had in mind is to use the client-submitted resourcepart of > the full jid [1] to disable the autojoin feature. > > Let's imagine the bookmark looks like this. > > > autojoin='true' > jid='coun...@conference.underhill.org'> > Puck > > > > The user has 3 clients. Those clients supports the client-submitted > resourcepart and the user (or the client) defines the names: > > * profanity.7abc > * Laptop > * Conversations.ABC > > If the User decides in the client "Disable autojoin on this device", > the client will set something like this in the : > > Conversations.ABC > > The result will look like this: > > > autojoin='true' > jid='coun...@conference.underhill.org'> > Puck > Conversations.ABC > > > > The client can check if his resource is defined as disable-autojoin. > If this is the case, the client will skip the autojoin. I think we're on the same track with profiles, just that this approach seems a bit clumsy to me. First this example uses 0048, for which clients may not accept extensions and overwrite anything they don't know when publishing again. This is I guess the reason why 0402 has this new tag. Then relying on potentially unstable resource names is risky, even if the trend seems to be to use somewhat stable names (again?). Do we leave inexisting resources lingering indefinitely? Do we GC at some point, based on what? This would also not prevent clients from removing an entry altogether when they leave a room as some seem to do (instead of toggling the autojoin flag off), losing completion/suggestion features and also some information when they're potentially readded later etc. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Bookmarks and autojoin issues
On 2020/05/24, Philipp Hörist wrote: > Hi, > > let me try with XEP-0402 > > > > > > name='The Play's the Thing' > autojoin='true'> > JC > > > > > > > > > > > > - Clients offer a option to set one or more profiles for the device > - Clients can ask the user on joining a bookmark which profiles should be > added (one or multiple) > - Default is no profile > - If a Client has no profile set, it honors the autojoin attr > - If a Client has a profile set, he autojoins all bookmarks that have the > corresponding profile, effectively ignoring the autojoin attr > - If a client leaves a muc he removes the profile from the bookmark Might seem obvious for some, but I would add regarding in general: - If there is an extension that you didn't add yourself, don't automatically remove the entry (that is, without explicit user input). > Still sounds complex to me, not easy to make that user friendly in my > opinion -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2020-05-27
On 2020/06/01, Jonas Schäfer wrote: > [..] > > First off, as Dave mentioned already (and as "everyone" will already know), > arguably this is deployed very widely. And not because of '393, specifically, > but because people have been using these types of metamarkers for so long > already that nobody could possibly trace it down to a single source. In a > way, > they are similar to quotation marks; they’ve become part of an additional > grammar used by many people throughout the internet. > > There are "cultural dialects" (e.g. the various markdown flavors), but there > is basic compatibility. Pinning down the XMPP dialect of this is a good` > thing™. I disagree. I think this is a bad idea and that we shouldn't endorse this as the XSF. XMPP is not a product line, it's a protocol. What specific sigils are being used (as input format) shouldn't be enforced at the protocol level. > However, we need a way forward which will not have to rely on transmitting > these markers on the wire. And we also need to be able to deal with entities > which send text which is strongly not intended to be formatted based on those > markers. > > With the proposed mandatory opt-in and opt-out solution, we get both of that. > I *hope* that clients which unambiguously support '393 will start to add the > opt-in so that the default behaviour (in absence of any marker) can move back > from "styled" to "unstyled". In addition, should we ever have to iterate on > this document (either in a new XEP or in this thing while it’s in draft), we > now have a wire format element of which the namespace can be bumped. > On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote: > > [..] > > If we have a hint and (approximately) the text above in the specification, > > is this enough to make people... if not actually happy, at least willing to > > grudgingly accept the document? The proposed changes are indeed better than 393 as is for reasons jonas mentioned. These changes de facto make the XEP an opt-out XEP though, as long as the default is to interpret for markup. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Evaluating gitlab.com as new location for XEP Editor repositories (xeps+registar)
On 2020/06/16, Jonas Schäfer wrote: > Hi again, > > Thanks Sam and Kevin for your valuable feedback. I think what you say > definitely has merit. > > In light of that, we came up with a hybrid solution which may be better or > worse. We need input on that. > > [..] > > Again, thank you very much for your feedback. Just to add my +1 on-list as well. I would happily dismiss skepticism and fear of change considering the benefits this would bring to the editor team. Also as Jonas says in some other mail in this thread: > If we find that the complexity of this solution is too high, we will > find another approach, probably at cost of more complexity elsewhere in the > infrastructure. > We would still have to sort out a few legal bits (e.g. around the CLA/IPR > stuff) as well as actually test if this plan is workable on a technical level > in practice. This legal bit might be the most annoying. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Very Simple Questions about Compliance Suites
On 2020/09/02, Tedd Sterr wrote: > I suspect their main benefit, rather than for implementations to claim some > level of compliance, is as a guide to which features are in use across the > ecosystem, and therefore worthwhile to implement. As federation requires > overlapping feature-sets, this neatly answers the question: "if there are 440 > XEPs, which ones am I meant to implement - surely not all of them?!" This ^ I don't particularly aim for compliance with poezio or anything else XMPP I have a hand on. I came to the conclusion compliance suites are not actually interesting apart for what Tedd said. See also: https://bouah.net/2020/07/what-about-design/ TL;DR: I think we'd need a lot more profiles for all the various design guidelines out there and that's certainly not the role of the XSF to dictate what e.g. Snikket wants to do. -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0060: max #max_items
Hi Standards, A year ago during a sprint we worked on implementing bookmarks2 and submitted a few changes to the spec at the same time. We also submitted a change to PubSub [0] [1] to allow a client to say “Set pubsub#max_items to whatever the server max is” so that multiple clients don't rewrite each other's max value every single time (alternatively saving the "get" step when configuring the node). This change to PubSub has been met with some ““resistance”” by the prosody team because the proposed value “max” is not a number and doesn't fit the way they currently handle things with XEP-0122 (Data Forms Validation), setting this value to “integer”. While this is more restrictive than what PubSub mandates (text-single), it does indeed make sense to have a “maximum number of items” be restricted to an int (not discussing which particular type of int, if there is). And while it's certainly not impossible for them to handle this “max” value, that would mean going through various hoops with 0122 to get this right. “-1” was proposed as a placeholder instead. While it doesn't exactly sit right with me wrt. semantics, I don't particularly mind and I am currently looking for the path of least resistance. So I just opened a PR. https://github.com/xsf/xeps/pull/984 Now I'm not entirely sure which path is gonna resist me most.. Prosody or Council? :x I'm indeed introducing breaking changes for a one-year old feature with this. I have to admit I'm not entirely fond of introducing yet another disco feature for the exact same meaning and for a feature that's probably not used[2], but I would update the PR with some guidance if necessary. Happy Hacking, [0]: https://mail.jabber.org/pipermail/standards/2019-October/036502.html [1]: https://github.com/xsf/xeps/pull/840 [2]: Some clients implemented bookmarks2 during the sprint, but most have put it behind a flag and/or not even merged yet. I don't think any publicly available server implements it? -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: max #max_items
On 2020/09/17, Maxime Buquet wrote: > This change to PubSub has been met with some ““resistance”” by the > prosody team because the proposed value “max” is not a number and > doesn't fit the way they currently handle things with XEP-0122 (Data > Forms Validation), setting this value to “integer”. > > While this is more restrictive than what PubSub mandates (text-single), > it does indeed make sense to have a “maximum number of items” be > restricted to an int (not discussing which particular type of int, if > there is). And while it's certainly not impossible for them to handle > this “max” value, that would mean going through various hoops with 0122 > to get this right. After a chat on xsf@, we agreed on another way forward, which is to declare a (integer-or-max or similar) type to be used with 0122. So I'll retract the PR and try to tackle this instead. Concerning the specification of this type, I'm a bit annoyed conceptually because 0122 allows stuff like , but a range applied to a union type doesn't really make sense / isn't defined. Even if it does seem obvious that it's gonna be applied to the only integer type in the union, what does that mean when a union has more than one of the same type that accepts ranges. I was looking for union with variants somewhere in XML -- so I can say to which variant apply -- but that doesn't seem to be defined. Suggestions? As a workaround, whether I end up modifying 0060 or creating a new document, I'll specify that applies to the integer value of this type. Happy Hacking! -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: max #max_items
On 2020/09/18, Maxime Buquet wrote: > On 2020/09/17, Maxime Buquet wrote: > > This change to PubSub has been met with some ““resistance”” by the > > prosody team because the proposed value “max” is not a number and > > doesn't fit the way they currently handle things with XEP-0122 (Data > > Forms Validation), setting this value to “integer”. > > > > While this is more restrictive than what PubSub mandates (text-single), > > it does indeed make sense to have a “maximum number of items” be > > restricted to an int (not discussing which particular type of int, if > > there is). And while it's certainly not impossible for them to handle > > this “max” value, that would mean going through various hoops with 0122 > > to get this right. > > After a chat on xsf@, we agreed on another way forward, which is to > declare a (integer-or-max or similar) type to be used with 0122. So I'll > retract the PR and try to tackle this instead. > > Concerning the specification of this type, I'm a bit annoyed > conceptually because 0122 allows stuff like , but a range > applied to a union type doesn't really make sense / isn't defined. > > Even if it does seem obvious that it's gonna be applied to the only > integer type in the union, what does that mean when a union has more > than one of the same type that accepts ranges. I was looking for union > with variants somewhere in XML -- so I can say to which variant apply > -- but that doesn't seem to be defined. Suggestions? > > As a workaround, whether I end up modifying 0060 or creating a new > document, I'll specify that applies to the integer value of > this type. New PR: https://github.com/xsf/xeps/pull/988 -- Maxime “pep” Buquet signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Namespaces
On 2022/01/08, Dave Cridland wrote: > On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer wrote: > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: PubSub Namespaces > > Abstract: > > This extension defines a new PubSub node attribute to specify the type > > of payload. > > > > > Oh no it doesn't! > > > > URL: https://xmpp.org/extensions/inbox/pubsub-ns.html > > > What this extension appears to be trying to do, based on the (entirely > unreferenced and unmentioned on this list) Github discussion, is to define > the pubsub node *semantics*. That's a different thing to a namespace, and > certainly different from the "type of payload". Indeed, this is based off a PR[0] that I made a while back on 277, that got somewhat-rejected-but-not-really by one of its authors (stpeter). I got asked to go to standards but I thought that would get no interest as pubsub stuff usually does and we would redo the same discussion just the two of us. So I gave up, until this. > The canonical example given was microblogging with Atom, where you don't > just want random Atom payloads - the node might require Atom to work, but > it has additional semantics around it that can be expected. IOW, the need > is to know it's a microblog node, and not just an Atom node. So this isn't > really about payload formats, it's about node semantics, and that's a > radically different thing. And definitely not a "namespace". Yes! I think you captured very well what we wanted to say! We do want a way to express semantics. “Payload” may not be the word, then we'll change it. “Namespace” annoys people, we're also happy to change it. Suggestions welcome for a field(?) name, and also another XEP name! If that is the meaning that is generally given to (payload) “type” (a very generic word), then I understand stpeter's resentment to accept the PR. > The pubsub#type form field we already have (and rarely use) is stipulated > as being the "type of node data, usually specified by the namespace of the > payload (if any)". I think this covers what's needed here, whereas this > specification as written actually doesn't - and isn't any clearer than > pubsub#type. Suggestions on how to make the document clearer is also very welcome. As you can see edhelas and I are not particularly great at writing, especially in english. I do want to say though that some more words on pubsub#type would be great. I am definitely not the only one to be confused. > This specification is also unimplementable as written, due to the > requirement in 5.1.1 to have realtime access to the registry, but that's > really a non-issue - the specification isn't clear enough to even know what > the intent is. Once we understand the intent, we can then compare it with > pubsub#type, and decide if it'd be better to make better use of that. I guess we'll fast-forward to the time the XSF has a working registry. I'm not sure that should prevent a spec from getting in. Thanks for the feedback! [0]: https://github.com/xsf/xeps/pull/986 signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Namespaces
On 2022/01/09, Dave Cridland wrote:
> On Sat, 8 Jan 2022 at 23:04, Maxime Buquet wrote:
> Therefore, I would:
>
> * Replace the new field with the existing one.
> * Strike section 5.2 (pubsub node, no longer needed)
Maybe only just §5.2.2. §5.2.1 could be moved up in §5.1.
> * Make 5.3 and 5.1 operate on the pubsub#type field.
> * Also: Put in a PR against XEP-0060 (sorry Ralph/Peter) to indicate that
> the pubsub#type means a label for the node semantics, and while it is often
> the same as the payload namespace it can also be any other URN.
Will do.
> > I guess we'll fast-forward to the time the XSF has a working registry.
> > I'm not sure that should prevent a spec from getting in.
> >
>
> Well, impossible isn't a reason not to work on fixing it, for sure.
>
> I'd be inclined to downgrade the MUSTs in that section to MAYs and move on,
> though.
>
> I like the registry, but I don't actually think we want to block private
> extensions with MUSTs here in any case.
I was going to say that an extension would “just” need to fill in that
field with whatever value. Because I did want the field set in any case.
But then I remembered Eventual Consistency, and made up my mind. If a
client doesn't fill the field then they won't benefit from the
features. Too bad.
Note that this same line of thought had me wondering if we really wanted
to reuse pubsub#type, because it's already empty in many places.
Anyway. The requirements on the registrar in §5.1.1 were mostly for
backward compatibility. To help servers / client transition
progressively. We're happy to relax the requirements.
With this out of the way, the registrar in itself isn't necessary
anymore, it's just an easy way for devs to lookup existing standard
values (in XEPs).
What we will do though in a later stage, is to go through existing specs
and update them to fill in this foo field (e.g., microblog{,-comments},
omemo-{devicelist,bundles}, bookmarks, user mood).
Agreed it's less crucial on PEP where node name equals our foo field,
but it does open up new features that the spec (and/or futher specs)
could bring.
I guess this requirement of setting the field will apply when a service
decides for some reason to use an allow/block list. I would also still
want to give a way for servers to force setting a value here if they so
choose, (for the same arbitrary reasons they'd choose to allow/block).
signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Proposed XMPP Extension: PubSub Namespaces
On 2022/01/12, Maxime Buquet wrote: > On 2022/01/09, Dave Cridland wrote: > > * Also: Put in a PR against XEP-0060 (sorry Ralph/Peter) to indicate that > > the pubsub#type means a label for the node semantics, and while it is often > > the same as the payload namespace it can also be any other URN. > > Will do. https://github.com/xsf/xeps/pull/1148 signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Events
On 2022/09/23, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Events > Abstract: > This specification describe how to handle events with XMPP. Thanks Jonas! Thanks Goffi! I have skimmed over the spec, and here are a few comments that shouldn't pose any issue for the move to experimental. > § 5. Events Nodes > [..] > Otherwise, a node may be published on any pubsub service. An events node > SHOULD be prefixed with 'urn:xmpp:events:0/', which SHOULD be followed > by an unique identifier. I suggest using XEP-0462[0] (PubSub Type Filtering) instead, as it's exactly what it is here to do. Fill in `pubsub#type` with `urn:xmpp:events:0` and use an opaque unique identifier as a node name. I would also argue this should be used for nodes on PEP, but I agree advantages are less obvious when node name equals ns. > § 6.4.1 > If the online location is on an XMPP MUC, an element qualified by > the 'jabber:x:conference' namespace as described in Direct MUC > Invitations (XEP-0249) can be used. Shouldn't this “can” be a MAY or SHOULD instead? in case of a MUC. I wonder how else the information that it is a MUC would be transmitted, as I only see elements to describe HTTP addresses. I understand your main use-case is to convert from AP, which happens in the HTTP world, but maybe there should be a way to add a URI instead of just a URL? > § 6.5 > The element MUST contain form as specified in Data Forms > (XEP-0004) “a form”. It's obvious in the sentence below that it's a single form, but this one is ambiguous. > Example: Romeo Submit his RSVP Answer > >urn:xmpp:events:rsvp:0 Contains an additional ">". That's it. Thanks a lot for the work on the AP gateway! signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Social Feed
On 2022/11/02, Goffi wrote: > 'pubsub#type' would be "http://www.w3.org/2005/Atom"; in any case here, I > don't > see how you would use it to get comment nodes or gallery node. You would have > to add an other metadata for that (which can be done). Just reacting to this because I feel this is largely misunderstood. No `pubsub#type` wouldn't be `http://www.w3.org/2005/Atom`. The whole point of `pubsub#type` is to be able to distinguish the payload, which isn't just Atom here, it's Atom, but used in a way to do (micro)blogging. Tomorrow say I want to use pubsub/atom to send in my accounts and I use the same Atom namespace, how do I distinguish with your blog articles? How do I have a UI/behaviour in my client/server that is different for my accounts and my blog articles? `pubsub#type` is how we do this. By using `urn:xmpp:social:foo` and `urn:xmpp:accounts:bar` I know of course that it's Atom, but I also know what rules on top of Atom are being used (type of content, etc.) signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] standardization process
On 2023/01/07, Florian Schmaus wrote: > I believe we would be able bring back the good old days where new protocols > ideas could be explored and bootstrapped without being bogged down in > process by having such numberless XEPs and by the XSF to provide the > infrastructure to host, develop and publish those XEPs. And supporting > numberless XEPs is trivial with our existing infrastructure. I am very much in favour of opening the gates even more. We're not there yet, but however small this is additional load that will be put on editors so I'd ensure everybody (in the editor team) is on board, if it ever gets adopted. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] uppercase/lowercase of keywords
On 2023/01/18, Peter Saint-Andre wrote: > On 1/18/23 9:26 AM, Thilo Molitor wrote: > > In Appendix F: Requirements Conformance all our XEPs refer to RFC 2119 > > defining > > "MUST", "SHALL" etc. > > But since RFC 2119 does not specify which case should be used for these > > keywords, a XEP using "shall" or even "sHaLl" uses normative keywords, no? > > My personal practice in writing RFCs has been to studiously avoid lowercase > conformance terms. It's quite easy and natural in English to use other > words: might instead of MAY, ought instead of SHOULD, etc. But it seems that > most authors are too lazy to do this, which is why we ended up with RFC > 8174. I'd like to nuance this here. Not everybody has english as their native language and many contribute to standardization nonetheless. Maybe standardization should be made more accessible, and I think 8174 is an ok step towards this, rather than having to be careful about subtle nuances of the language. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0466: Opt-in/out mechanism with messages
I've been trying to work on Ephemeral Messages (XEP-0466) again, and I still can't figure out remaining TODOs. These are my changes on top of the current state of the spec, but they're here just for information, they don't contain anything related to this question. https://github.com/Ppjet6/xeps/commits/0466-todo https://bouah.net/specs/ephemeral.html (commit 08c9b46) So, opt-in/opt-out with messages. This issue has been bugging me for a while. I think this is a pretty generic problem to solve has isn't proper to this protocol. I'd like that we don't get hanged up on the specifics of the protocol here, which is generally what has been happening and never really been helpful (often derogatory), unless of course it becomes necessary because of specific constraints that it imposes. I'm sorry this isn't very clear to me how to formulate all this, and it shows in the mail. I think I'm having conceptual issues with implementing clients possibly missing messages (MAM expiry too short, etc.), but also non-implementing clients. Also the fact that I can't know if a client implements the protocol as a sending client some of the time, because of being in MUC of missing a directed presence. The protocol is currently defined to only use messages. It's also not possible in the protocol to have asymmetrical behavior. (I'm not dead set on this, but this is a different question I think) Opt-in seems to be easy, include the tag when sending messages, and receiving clients will start picking it up as soon as they see it (live, or MAM). I currently mandate that receiving clients reply including this element if they wish to opt-in themselves. Some time passes, all clients included in the chat are sending the element, now I want to opt-out. Do I need to start including an element indefinitely until all clients pick it up? And when we think we're finally done (that all clients have seen it), one client starts being used again after weeks and sends the element again, goto 1. This () is obviously not a solution? Maybe the issue is that I don't specify anything if receiving clients don't include the element. The issue here is that I can't mandate that when a receiving client doesn't include the tag, the sending client stops including it, because of non-implementing clients (and because I can't know if it's a non-implementing client or not in some context). Thoughts? Will this just "not work"? Are they any other similar protocols? Should I give up using only messages and combine this with something else? signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0060: Tell the client when a node is full
I have just submitted https://github.com/xsf/xeps/pull/1275 I remember first mentioning it here[0] and jonas giving me a quick answer[1] at the time. I've seen this happen again recently and I decided to give it some time. What happens when a client publishes on a full node seems to be unspecified at the moment. This change proposes to add a new configuration option to specify new behaviour, namely retraction, or rejection. Please do provide suggestions for better naming. When configured to "reject", I propose to have the service return cancel/conflict. It seems conflict is already returned on publish-options error so a element SHOULD be returned alongside to differenciate. When configured to "retract", I propose to allow the item to be published, retracting an existing item beforehand. It is currently worded as "the item with the earliest creation date MUST be retracted", but I wonder there should be more options for this, such as "retract_created", "retract_updated", etc. For backwards compatibility, which is implementation defined, this option simply won't be set. I am not sure there is a way to unset a node option though, so maybe there should be a "¯\_(ツ)_/¯" (shrug) variant to this new option. I have also added a disco feature for discoverability. Have a missed a place to edit in the spec? Feedback welcome! [0]: https://mail.jabber.org/pipermail/standards/2019-October/036503.html [1]: https://mail.jabber.org/pipermail/standards/2019-October/036506.html signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: Tell the client when a node is full
On 2023/03/17, Matthew Wild wrote:
> I actually think the current behaviour of Prosody (and I think
> ejabberd? others?) is definitely desirable in some cases, and I
> propose making it an explicit option ('discard-oldest'?) - in this
> mode the node is effectively a cache of the most recent items.
So a chat on xsf@ brought some more light to this.
It appears that the “retract” option that I am adding is already a
SHOULD (RECOMMENDED).
So in addition to “retract” that I'll probably rename “retract-oldest”
to be slightly more explicit, I don't mind adding a “discard-oldest”
option. Retracting being the default.
§ 7.1.2 https://xmpp.org/extensions/xep-0060.html#publisher-publish-success
> Note: If the service or node is configured so that there is a maximum
> number of items cached at the node and the maximum is reached when an
> item is published, the service MUST delete one of the existing items.
> It is RECOMMENDED for the service to follow the "first in, first out"
> rule and delete the oldest item. Depending on node configuration,
> deletion of an existing item MAY result in sending of a delete
> notification to the subscribers.
This “delete notification” configuration the text talks about is
probably “pubsub#notify_retract”. Confusing terminology. “Delete“ seems
to be used in the case of nodes, “retract” in the case of items.
This paragraph also uses the word “oldest” which isn't exactly clear in
this document, but from what I gather, there are only two operations
possible for an item, publishing and retracting. There is no specified
way to update an item, but only some text that suggests it. See below.
For “oldest”, adding informational text that clarifies it would be good,
and can / should happen in this PR / revision.
A definition could be ”ordered by publication [time]”, except if we mix
in updates, which aren't really defined but the fact of overwriting an
item is mentioned in multiple places:
§ 7.1.2 https://xmpp.org/extensions/xep-0060.html#publisher-publish-success
> Note: If the publisher previously published an item with the same
> ItemID, successfully processing the request means that the service
> MUST overwrite the old item with the new item and then proceed as
> follows.
§ 7.1.3 https://xmpp.org/extensions/xep-0060.html#publisher-publish-error
> Note: If a publisher publishes an item with an Item ID and the ItemID
> matches that of an existing item, the pubsub service MUST NOT fail the
> publication but instead MUST overwrite the existing item and generate
> a new event notification (i.e., re-publication is equivalent to
> modification).
§ 12.8 https://xmpp.org/extensions/xep-0060.html#impl-uniqueness
> If a publisher publishes an item and the ItemID matches that of an
> existing item, the pubsub service MUST overwrite the existing item and
> generate a new event notification.
The term “overwrite” isn't defined anywhere. Should:
1. The original item be removed and the new item published in its stead
same publication time as the original one. Or the original item be
updated with contents of the new one. Technically the same.
2. The original item be removed and the new one be published as a new
item.
(Any more?)
I think the text can be read to fit both.
Discussion on the xsf@ channel seems to suggest 2. is preferred:
https://logs.xmpp.org/xsf/2023-03-17?p=h
https://logs.xmpp.org/xsf/2023-03-18?p=h
We certainly do need to settle on one of these, as it allows us to agree
on the order in which to retract/discard items for the original issue
here.
signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))
On 2024/03/10, Daniel Gultsch wrote: > This message constitutes notice of a Last Call for comments on > XEP-0360. > > Title: Nonzas (are not Stanzas) > Abstract: > This specification defines the term "Nonza", describing every top > level stream element that is not a Stanza. > > URL: https://xmpp.org/extensions/xep-0360.html > > This Last Call begins today and shall end at the close of business on > 2024-03-25. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes. The abstract and introduction seem to cover this well. > 2. Does the specification solve the problem stated in the introduction > and requirements? From RFC 6120 § 8: > Three kinds of XML stanza are defined for the 'jabber:client' and > 'jabber:server' namespaces: , , and . Which seems somewhat restrictive. It also doesn't take into account 0114 (Component) which I guess was written later? and 0114 itself does little effort at including itself in this definition (it uses the word as if it was already defined in this context). I guess I would expect 0360 to (re?)define stanza, so it can define what nonza isn't. > § 2 > Nonza: A Nonza is every XML element found at the XMPP stream's top level > which is not a Stanza. The top level of an XMPP stream is the child XML level > beneath the last opening tag as defined in RFC 6120 § 4.2. "Opening > a Stream", i.e. at depth=1 of the stream. > Informal definition: A XMPP stream element is a Nonza, if its element name is > not 'message', 'iq' or 'presence'. This seems to be missing a namespace definition. Since Nonza here is defined by what it isn't, we might as well define Stanza properly. Maybe https://www.rfc-editor.org/rfc/rfc6120#section-4.8.2 "Content Namespace" can be worth adding somewhere in there? > 3. Do you plan to implement this specification in your code? If not, > why not? N/A > 4. Do you have any security concerns related to this specification? Nothing to add to the other thread started by peter. > 5. Is the specification accurate and clearly written? I am not sure why we're talking about resource binding, but I haven't really concerned myself with stream-level features much.. Maybe some explanation here would help. RFC 6120 § 7. mentioned in 0360 § 4. confusingly talks about stanza in this case too. signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
I'm catching up on this thread and I'm replying to two of your mails at the same time. On Mon, 03 Jun 2024 12:37:21 +0200, Marvin W wrote: > I tried to circumvent this by writing XEP-0447 [..] yet there already have > been implementations from the community in released software. > This underlines my point that Experimental is considered "ready for use in > production software" by some. No, this only says that this is a much needed feature, whether or not the protocol is considered "ready for use in production software" (whatever that means[0]) is irrelevant IMO. > As explained, we have de-facto reached the state where something that's > considered useful to developers is in Experimental for more than a few > months, we will see it in production and therefor will have to consider > interoperability and compatibility with this specific Experimental version > for at least some time. And that is where the feeling for the need of a > higher bar to Experimental comes from. So to reduce the bar for > Experimental, we have to move to Stable faster or the ecosystem will move > faster than we manage the XEPs. Experimental isn't the issue. The thing is that people want features / improvements and will implement them, and that's great. There's no preventing it. By doing so they should also ready to also do the work to update their software whenever the spec gets updated. > because Experimental shouldn't have had implementations. How does one even experiment without implementation? > 3. We should more actively discourage release of functionality based on > ProtoXEP and Experimental XEPs in production (except hidden behind feature > flags or options clearly marked as experimental). And that's how you end up with Pidgin not having MAM or the like for years. Because they indeed refuse to implement Experimental specs. Life happens, and people working on specs also get hit by buses / have other things to take care of. The burden can't be put on just one person alone to do the work. It happens but it's rare that council does something about it. In other words. You can discourage all you want, that won't stop anybody from implementing what they need. And I'd rather have people take a half-baked spec in Experimental and try to improve on it and report back. They may release it however they want. On Mon, 03 Jun 2024 14:58:23 +0200, Marvin W wrote: > On Mon, 2024-06-03 at 14:10 +0200, Goffi wrote: > > The "experimental" state is clear: it may change and break. > That seems to not be clear to anyone, to be honest, especially not end- > users and also not in how we market our products. Yes it is clear. It's you that don't want to accept that people may choose to implement a protocol that will likely break. Your following example with 0384 is only good in that it would have made it much more easy to find if there was another XEP number assigned for > 0.3.0, as flow and goffi have said (or will say?) in this thread. [0]: https://bouah.net/2022/09/versioning/ signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
