Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
Hello, Thank you Jonas and sorry for being late. I have carefully read the feedback and sent a PR https://github.com/xsf/xeps/pull/1121 . I noted 3 suggestions which didn't have any objection. Add XEP-0455: Service Outage Status to Future Development - done Too many "core" - I took a slightly different approach than suggested by dropping the "Core" in "Core Client" and "Core Server". I found it made more sense but let me know if you'd rather have me revert and rename something to Foundation. Change the architecture of the compliance suite - I agree it could be better but it's a large topic for which I don't see myself in capacity to do this at the moment. Cheers -- Sonny Piers so...@fastmail.net On Tue, Sep 7, 2021, at 15:59, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0459. > > Title: XMPP Compliance Suites 2022 > 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. > > URL: https://xmpp.org/extensions/xep-0459.html > > This Last Call begins today and shall end at the close of business on > 2021-09-21. > > 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? > > 2. Does the specification solve the problem stated in the introduction > and requirements? > > 3. Do you plan to implement this specification in your code? If not, > why not? > > 4. Do you have any security concerns related to this specification? > > 5. Is the specification accurate and clearly written? > > Your feedback is appreciated! > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
On 29 Sep 2021, at 17:32, Georg Lukas wrote: > > Sorry this is so late, and thanks to Sonny for taking up the hard task > of fighting this through the Council. > > * Jonas Schäfer [2021-09-07 16:04]: >> This message constitutes notice of a Last Call for comments on >> XEP-0459 [...] XMPP Compliance Suites 2022 > > 1. As part of the work on XEP-0313, two XEPs got split out: > > - XEP-0441: Message Archive Management Preferences I think preferences just aren’t generally useful enough to be needed in the suite. > - XEP-0442: Pubsub Message Archive Management I think we’re probably the only people doing pubsub MAM, and I wouldn’t argue that it’s going to be useful in the compliance suites - we had some quite specific requirements, otherwise we’d probably not have bothered. > I think that at least XEP-0441 belongs into Advanced IM to keep the > same functionality as before. I don’t think there’s a particular reason to keep the same functionality as before - they were split out of 313 precisely because they’re not as widely needed as the rest of it. > 2. As editor of earlier Compliance Suites, I used to review the > https://xmpp.org/extensions/xep-0459.html#future section to see which > XEPs have matured over the previous year and could be added into one of > the Suites. > > I might be slightly biased, but I would like to propose the following > three for Advanced IM Client and Server: > > - XEP-0379: Pre-Authenticated Roster Subscription > - XEP-0401: Easy User Onboarding > - XEP-0445: Pre-Authenticated In-Band Registration > > In parallel, I'd like to ask The Editor about issuing Last Calls for > 0379 and 0445, and Marc to step in and ask for LCing 0401. If the suites were framed as current advice on what to implement, then advising these if you want to do registration would seem reasonable to me, but as long as it’s “compliance” suites, I don’t think mandating registration approaches is helpful - it means any systems that don’t need registration can’t be compliant, and that reduces the value in the specs. > 3. It is also good to check https://xmpp.org/extensions/ for new > additions. From there, I suggest adding the following new XEPs to the > "Future Development" section: > > - XEP-0453: DOAP usage in XMPP Not arguing it’s not useful, but ISTM how projects advertise themselves shouldn’t be a part of (future) compliance. > - XEP-0455: Service Outage Status > - for E2EE: XEP-0450: Automatic Trust Management (ATM) Are we sure 450’s in a state where it’s sensible to call it out? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
* Georg Lukas [2021-09-29 18:32]: 1. As part of the work on XEP-0313, two XEPs got split out: - XEP-0441: Message Archive Management Preferences - XEP-0442: Pubsub Message Archive Management I think that at least XEP-0441 belongs into Advanced IM to keep the same functionality as before. Removing functionality from a Compliance Suite is problematic in itself? How so? And regarding XEP-0441 specifically, wasn't the functionality optional back when it was in XEP-0313? Anyway, in my experience, exposing the option to disable MAM can yield undesired results. End users might see no need for a server-side archive if they're not aware of how it helps with reliable message delivery and multi-device support. XEP-0441 itself says: After observing XEP-0313 usage in the wild, it became apparent that preferences were not often used, and can interfere with clients that use the archive for synchronization of messages received by the user while disconnected. Therefore it is not actively encouraged for an implementation/deployment to offer this functionality. [ https://xmpp.org/extensions/xep-0441.html#intro ] It seems weird to add this to a Compliance Suite while at the same time "not actively encouraging" implementations to offer this feature. Holger ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
On Wed, Sep 29, 2021 at 4:33 PM Georg Lukas wrote: > 1. As part of the work on XEP-0313, two XEPs got split out: > > - XEP-0441: Message Archive Management Preferences > - XEP-0442: Pubsub Message Archive Management > > I think that at least XEP-0441 belongs into Advanced IM to keep the > same functionality as before. Agreed. > 2. As editor of earlier Compliance Suites, I used to review the > https://xmpp.org/extensions/xep-0459.html#future section to see which > XEPs have matured over the previous year and could be added into one of > the Suites. > > I might be slightly biased, but I would like to propose the following > three for Advanced IM Client and Server: > > - XEP-0379: Pre-Authenticated Roster Subscription I think we should try to move away from roster subscription as any form of prerequisite to start chatting. (And we already have in parts for example by making OMEMO nodes world readable) > - XEP-0401: Easy User Onboarding > - XEP-0445: Pre-Authenticated In-Band Registration Those XEPs are too opinionated on how on boarding should work and would prevent any client that for example targets corporate users and their LDAP user backends or client certificate logins from being a compliant XMPP client. Something phone number based like Quicksy.im would also be excluded. Looking at the server side a provider with a custom XMPP server that only offers paid accounts (where any invite based system doesn’t make sense) should be able to gain 'Advanced IM' status. > 3. It is also good to check https://xmpp.org/extensions/ for new > additions. From there, I suggest adding the following new XEPs to the > "Future Development" section: > > - XEP-0453: DOAP usage in XMPP > - XEP-0455: Service Outage Status +1 to include in future section. > - for E2EE: XEP-0450: Automatic Trust Management (ATM) I don’t think we have enough experience with this XEP to tell whether or not this is even a good idea. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
Sorry this is so late, and thanks to Sonny for taking up the hard task of fighting this through the Council. * Jonas Schäfer [2021-09-07 16:04]: > This message constitutes notice of a Last Call for comments on > XEP-0459 [...] XMPP Compliance Suites 2022 1. As part of the work on XEP-0313, two XEPs got split out: - XEP-0441: Message Archive Management Preferences - XEP-0442: Pubsub Message Archive Management I think that at least XEP-0441 belongs into Advanced IM to keep the same functionality as before. 2. As editor of earlier Compliance Suites, I used to review the https://xmpp.org/extensions/xep-0459.html#future section to see which XEPs have matured over the previous year and could be added into one of the Suites. I might be slightly biased, but I would like to propose the following three for Advanced IM Client and Server: - XEP-0379: Pre-Authenticated Roster Subscription - XEP-0401: Easy User Onboarding - XEP-0445: Pre-Authenticated In-Band Registration In parallel, I'd like to ask The Editor about issuing Last Calls for 0379 and 0445, and Marc to step in and ask for LCing 0401. 3. It is also good to check https://xmpp.org/extensions/ for new additions. From there, I suggest adding the following new XEPs to the "Future Development" section: - XEP-0453: DOAP usage in XMPP - XEP-0455: Service Outage Status - for E2EE: XEP-0450: Automatic Trust Management (ATM) Kind regards, Georg ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
On Mon, 27 Sept 2021 at 11:04, Kim Alvefur wrote: > On Mon, Sep 27, 2021 at 10:37:37AM +0100, Dave Cridland wrote: > >On Tue, 21 Sept 2021 at 16:46, Matthew Wild wrote: > > > >> On Tue, 21 Sept 2021 at 15:24, Tedd Sterr > wrote: > >> > >>> 4. The original version (XEP-0242/0243) had two simple categories, Core > >>> and Advanced, and that was all; later versions just continued with > that. > >>> The IM Suite, especially, is becoming quite top-heavy, so adding a > middle > >>> level would be good - but what to call it? Instead of names, how about > >>> simply Level 1, Level 2, and Level 3 - right now that would map Core to > >>> Level 1 and Advanced to Level 3, then a subset of Level 3 could make up > >>> Level 2. Note that not all Suites require 3 levels (or even 2 in the > case > >>> of Web). [This also fits nicely with a compliance badge design idea I > have.] > >>> > >> > >> I agree with everything you said, but I'm especially in favour of fixing > >> this one. Part of the goal of these things is to help summarize XMPP > >> compliance of a piece of software to people who aren't intimate with > XMPP. > >> There is no planet on which describing a piece of software as "Core > Core" > >> makes sense. > >> > >> I'd be in favour of either switching to "Basic"/"Advanced" (I think > >> "Basic" was frowned upon originally, which is why it wasn't used), or to > >> numbered levels as you propose. > >> > > > >We originally went for "Core" and "Advanced" with the intent that while > >"Advanced" clearly sounds pretty damn cool, people would be happy to put a > >marketing sticker type thing on their product with "Core" on it. > > > >This was explicitly up against "Basic", which we didn't think was the kind > >of thing people would want to brag about. > > > >If we were to change things, I think I'd avoid "Basic" still, for the same > >reasons. > > Perhaps "Foundation" is a cool enough word to replace the "Core" > category, solving the "Core Core" thing by having "Core Foundation", > "Advanced Foundation", "Core IM", "Advanced IM" etc? > > That seems a simple fix, yes. > > -- > Kim "Zash" Alvefur > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
On Mon, Sep 27, 2021 at 10:37:37AM +0100, Dave Cridland wrote: On Tue, 21 Sept 2021 at 16:46, Matthew Wild wrote: On Tue, 21 Sept 2021 at 15:24, Tedd Sterr wrote: 4. The original version (XEP-0242/0243) had two simple categories, Core and Advanced, and that was all; later versions just continued with that. The IM Suite, especially, is becoming quite top-heavy, so adding a middle level would be good - but what to call it? Instead of names, how about simply Level 1, Level 2, and Level 3 - right now that would map Core to Level 1 and Advanced to Level 3, then a subset of Level 3 could make up Level 2. Note that not all Suites require 3 levels (or even 2 in the case of Web). [This also fits nicely with a compliance badge design idea I have.] I agree with everything you said, but I'm especially in favour of fixing this one. Part of the goal of these things is to help summarize XMPP compliance of a piece of software to people who aren't intimate with XMPP. There is no planet on which describing a piece of software as "Core Core" makes sense. I'd be in favour of either switching to "Basic"/"Advanced" (I think "Basic" was frowned upon originally, which is why it wasn't used), or to numbered levels as you propose. We originally went for "Core" and "Advanced" with the intent that while "Advanced" clearly sounds pretty damn cool, people would be happy to put a marketing sticker type thing on their product with "Core" on it. This was explicitly up against "Basic", which we didn't think was the kind of thing people would want to brag about. If we were to change things, I think I'd avoid "Basic" still, for the same reasons. Perhaps "Foundation" is a cool enough word to replace the "Core" category, solving the "Core Core" thing by having "Core Foundation", "Advanced Foundation", "Core IM", "Advanced IM" etc? -- Kim "Zash" Alvefur 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-0459 (XMPP Compliance Suites 2022)
On Tue, 21 Sept 2021 at 16:46, Matthew Wild wrote: > On Tue, 21 Sept 2021 at 15:24, Tedd Sterr wrote: > >> 4. The original version (XEP-0242/0243) had two simple categories, Core >> and Advanced, and that was all; later versions just continued with that. >> The IM Suite, especially, is becoming quite top-heavy, so adding a middle >> level would be good - but what to call it? Instead of names, how about >> simply Level 1, Level 2, and Level 3 - right now that would map Core to >> Level 1 and Advanced to Level 3, then a subset of Level 3 could make up >> Level 2. Note that not all Suites require 3 levels (or even 2 in the case >> of Web). [This also fits nicely with a compliance badge design idea I have.] >> > > I agree with everything you said, but I'm especially in favour of fixing > this one. Part of the goal of these things is to help summarize XMPP > compliance of a piece of software to people who aren't intimate with XMPP. > There is no planet on which describing a piece of software as "Core Core" > makes sense. > > I'd be in favour of either switching to "Basic"/"Advanced" (I think > "Basic" was frowned upon originally, which is why it wasn't used), or to > numbered levels as you propose. > We originally went for "Core" and "Advanced" with the intent that while "Advanced" clearly sounds pretty damn cool, people would be happy to put a marketing sticker type thing on their product with "Core" on it. This was explicitly up against "Basic", which we didn't think was the kind of thing people would want to brag about. If we were to change things, I think I'd avoid "Basic" still, for the same reasons. Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
On Tue, 21 Sept 2021 at 15:24, Tedd Sterr wrote: > 4. The original version (XEP-0242/0243) had two simple categories, Core > and Advanced, and that was all; later versions just continued with that. > The IM Suite, especially, is becoming quite top-heavy, so adding a middle > level would be good - but what to call it? Instead of names, how about > simply Level 1, Level 2, and Level 3 - right now that would map Core to > Level 1 and Advanced to Level 3, then a subset of Level 3 could make up > Level 2. Note that not all Suites require 3 levels (or even 2 in the case > of Web). [This also fits nicely with a compliance badge design idea I have.] > I agree with everything you said, but I'm especially in favour of fixing this one. Part of the goal of these things is to help summarize XMPP compliance of a piece of software to people who aren't intimate with XMPP. There is no planet on which describing a piece of software as "Core Core" makes sense. I'd be in favour of either switching to "Basic"/"Advanced" (I think "Basic" was frowned upon originally, which is why it wasn't used), or to numbered levels as you propose. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
Sorry this is last minute, but here are some thoughts: 1. The Last Call questions aren't really appropriate because usual-argument-about-compliance-suites-not-really-belonging-in-standards-track. 2. I know the idea is to get it out of the way before change of Council, but it still feels too early. 3. Core Suite, Core Client, Core Server, Core features, core core core core core! I think we need another word, if only to make talking about things clearer. Given that all of the other suites require and build upon the Core Suite as a base, it makes sense to rename it to "Base Compliance Suite" (or similar.) 4. The original version (XEP-0242/0243) had two simple categories, Core and Advanced, and that was all; later versions just continued with that. The IM Suite, especially, is becoming quite top-heavy, so adding a middle level would be good - but what to call it? Instead of names, how about simply Level 1, Level 2, and Level 3 - right now that would map Core to Level 1 and Advanced to Level 3, then a subset of Level 3 could make up Level 2. Note that not all Suites require 3 levels (or even 2 in the case of Web). [This also fits nicely with a compliance badge design idea I have.] 5. The tables could also be simplified from several columns (particularly if organised into levels): as everything in Core (Level 1) is a requirement for Advanced (Level 2 or 3), sectioning the tables (thick lines to separate) would allow one column for Client and another for Server, with levels increasing for each successive section (where additional levels are needed), avoiding the need for repetition between Core and Advanced, without making the tables noticeably longer (feature rows with two Xs could be omitted.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] LAST CALL: XEP-0459 (XMPP Compliance Suites 2022)
This message constitutes notice of a Last Call for comments on XEP-0459. Title: XMPP Compliance Suites 2022 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. URL: https://xmpp.org/extensions/xep-0459.html This Last Call begins today and shall end at the close of business on 2021-09-21. 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? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
