[Standards] Re: UPDATED: XEP-0333 (Displayed Markers (was: Chat Markers))

I entirely missed this, and have no understanding of the rationale, but: 1) I'm somewhat ambivalent about removing , but it's certainly well implemented by my anecdotological studies. 2) Removing seems OK, but I've considered various use-cases for which an explicit, user-driven, acknowledgement

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

izing the definition and nature of Stanzas would be very useful, I think, to newcomers and old hands alike. I think we all kind of know what we mean when we say "Stanza", but I think there's a lot of detail that would be useful to gather into one place. Dave. On Fri, 22 Mar 2024

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

On Fri, 22 Mar 2024 at 08:47, Florian Schmaus wrote: > > > In Section 5, business rule #2 states: > > > > "Nonzas SHOULD NOT have a 'from' or 'to' attribute." > > > > I have a few questions: > > > > - When is it sensible to make an exception to this SHOULD NOT? > > I can not think of one.

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

On Fri, 22 Mar 2024 at 08:47, Florian Schmaus wrote: > For example, assume a XMPP library written in an object-oriented > language. There is a superclass TopLevelStreamElement which has one > obvious subclass named Stanza. Now, how should we name the other > subclass?

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

On Mon, 18 Mar 2024, 17:32 Stephen Paul Weber, wrote: > >> However it does lack any way to support indicating to the server > >> which > >> credential will be used, other than perhaps by implication from the SASL > >> mechanism. > >> > >> > >That's not the purview of a SASL profile. If a SASL

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

On Mon, 18 Mar 2024 at 14:19, Stephen Paul Weber wrote: > >1. Is this specification needed to fill gaps in the XMPP protocol > >stack or to clarify an existing protocol? > > Yes, we currently have no way to use multiple SASL or otherwise to acheive > a > similar result. > > >2. Does the

[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)

On Mon, 18 Mar 2024 at 09:00, Daniel Gultsch wrote: > This message constitutes notice of a Last Call for comments on > XEP-0388. > > Title: Extensible SASL Profile > Abstract: > This document describes a replacement for the SASL profile documented > in RFC 6120 which allows for greater

[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

; > -- Original Message -- > From "Dave Cridland" > To "XMPP Standards" > Date 12/03/2024 09:59:33 > Subject [Standards] Re: Remove requirement to send disco#info feature in > XEP-0030 > > >As others have said, it's a wart. Any protocol has

[Standards] Re: Remove requirement to send disco#info feature in XEP-0030

As others have said, it's a wart. Any protocol has lots of them; XMPP has always had its fair share. (You mention XEP-0045 briefly, and we're all familiar that it's essentially a collection of warts at this stage). This one is not, as far as I can see, harmful in any meaningful way. As Tedd Sterr

[Standards] Re: LAST CALL: XEP-0360 (Nonzas (are not Stanzas))

On Sun, 10 Mar 2024 at 15:19, 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. > >

[Standards] Re: Feedback requested: SVCB for XMPP

On Wed, 14 Feb 2024 at 15:14, Peter Saint-Andre wrote: > On 2/13/24 11:18 PM, Travis Burtrum wrote: > > > 5. > > Ultra-minor nit: is BOSH needed or useful with websockets and upcoming > > webtransport? legacy clients that don't support either of those won't > > support this either, and will look

[Standards] Re: Feedback requested: SVCB for XMPP

On Wed, 14 Feb 2024 at 06:18, Travis Burtrum wrote: > Hi Dave! > > I've only briefly reviewed this so far, so please forgive if I've missed > things, but I have some early comments: > > Major blocker I'm not sure can be addressed: > > 1. > This essentially re-introduces the major security flaw

[Standards] Feedback requested: SVCB for XMPP

Hi all, Attached is an *unsubmitted* Internet Draft covering SVCB usage for XMPP. Assuming attachments work on this list! Feedback welcome, I intend to submit this one shortly to the IETF. Dave. draft-cridland-dnsop-svcb-xmpp.pdf Description: Adobe PDF document

[Standards] Re: XEP-0440 and tls-server-end-point

On Tue, 30 Jan 2024 at 10:11, Florian Schmaus wrote: > If we are not positive about it, then why should be push implementations > into non-compliance by mandating it, when we simply could (strongly) > recommend it? Exactly this - interoperability should be a pragmatically achievable goal.

[Standards] Re: XEP-0440 and tls-server-end-point

On Thu, 11 Jan 2024 at 12:39, Holger Weiß wrote: > * Simon Josefsson [2024-01-11 13:10]: > >I believe tls-server-end-point is generally best left unimplemented to > >guide efforts towards supporting the stronger tls-exporter. > > One use case I see for tls-server-end-point is that it allows for

[Standards] Re: Proposed XMPP Extension: Host Meta 2 - One Method To Rule Them All

Hi all, (Updated Lance's email to the last-known-good public one). I dislike this XEP intensely. But... I think it's probably the most pragmatic solution that fits the existing standards space. Questions: - Should we require this to always be hosted at the exact domain? Pretty much everywhere

[Standards] Re: LAST CALL: XEP-0458 (Community Code of Conduct)

On Wed, 1 Nov 2023 at 16:59, Peter Saint-Andre wrote: > Hallo Guus, > > Thanks for sharing your thoughts. In my comments below, I haven't yet > provided suggested text, but I wanted to reply quickly and I will send > another note when I can make concrete proposals. > > On 10/31/23 3:18 PM, Guus

[Standards] Re: Chat Markers and Read Status

On Mon, 18 Sept 2023 at 05:19, Simon Lipp wrote: > The use case is easy ; if I’m in conversation with Alice, and Bob sends > me some message, my client usually puts some notification. But if I > close the client without reading the message, I have no reminder in the > next session that I don’t

[Standards] Re: NEW: XEP-0481 (Content Types in Messages)

On Tue, 6 Jun 2023 at 22:34, Travis Burtrum wrote: > > Jun 6, 2023 4:31:54 PM Dave Cridland : > > > > > On Thu, 4 May 2023 at 15:06, wrote: > >> Version 0.1.0 of XEP-0481 (Content Types in Messages) has been > >> released. > > > > This is weird

[Standards] Re: NEW: XEP-0481 (Content Types in Messages)

On Thu, 4 May 2023 at 15:06, wrote: > Version 0.1.0 of XEP-0481 (Content Types in Messages) has been > released. > This is weirdly horrible. * First and foremost, it falls into a general trap that's open to abuse by malicious actors, by having a message whose content will be interpreted

Re: [Standards] XEP-0359: Unique and Stable Stanza IDs, PR#1272 Add security consideration and

On Wed, 22 Feb 2023 at 13:33, Thilo Molitor wrote: > > There is a very obvious solution to this which everyone seems to be > > overlooking: we need a new element with a guaranteed unique, non-spoofed > > UUID; should a server feel the need to do bad things, it can set the > > 'spoofed' attribute

Re: [Standards] uppercase/lowercase of keywords

On Thu, 19 Jan 2023 at 09:17, Maxime Buquet wrote: > 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

Re: [Standards] XEP-0388

I can do on the list too - merge it, publish it, but add yourselves as authors too. On Fri, 13 Jan 2023 at 13:55, Thilo Molitor wrote: > > Dave approved the PR last week here: > > https://github.com/xsf/xeps/pull/1214#pullrequestreview-1236512706 > Great, I've not hallucinated! At least partly

Re: [Standards] standardization process

On Sat, 7 Jan 2023 at 20:46, Florian Schmaus wrote: > But let use assume that we remove the council approval requirement for > experimental XEPs. And further assume that we clearly state that > experimental XEPs may change protocol without namespace bumps. Forgetting everything else for a

Re: [Standards] NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

Not using PLAIN is insufficient - clients have to only use SCRAM, and in particular, variants of SCRAM that are considered secure. So yes, if someone is deploying SCRAM-SHA256, this would detect a downgrade to SCRAM-SHA1, but only while SCRAM-SHA1 is proof against compromise. And while SCRAM-SHA1

Re: [Standards] standardization process (was: Re: XEP-0353 propose id syntax)

On Thu, 5 Jan 2023 at 21:38, Florian Schmaus wrote: > On 05/01/2023 16.31, Peter Saint-Andre wrote: > > On 1/5/23 3:18 AM, Florian Schmaus wrote: > > > >> I become more and more convinced that we may be better with an IETF > >> I-D / RFC style standardization process. Where an I-D is a mutable,

Re: [Standards] XEP-0353 propose id syntax

On Thu, 5 Jan 2023 at 10:19, Florian Schmaus wrote: > > On 05/01/2023 10.51, Dave Cridland wrote: > > * The argument that this doesn't need a namespace bump is wrong because > > "experimental" has no effect here. The entire point of those 'versioned' > > name

Re: [Standards] XEP-0353 propose id syntax

On Thu, 5 Jan 2023 at 12:35, Marvin W wrote: > Which brings me to the conclusion: If we want to gauarantee a certain > amount of randomness in any id field, we should just state exactly > that, e.g. "the id SHOULD include at least 120 bits of randomness, for > example by using an UUIDv4" (and

[Standards] XEP-0353 propose id syntax

On a Github PR XEP-0353: Add requirement for UUID v4 for id attributes by tmolitor-stud-tu · Pull Request #1262 · xsf/xeps · GitHub , Thilo wrote: > I think explicit is better than implicit, hence this PR. > Since v0.4 of this XEP isn't implemented by any

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

On Sat, 31 Dec 2022 at 13:15, Florian Schmaus wrote: > On 31.12.22 13:19, Dave Cridland wrote: > > > > > > On Fri, 30 Dec 2022 at 19:40, Florian Schmaus > <mailto:f...@geekplace.eu>> wrote: > > > > On 30.12.22 11:05, Dave Cridland wrote: > >

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

On Fri, 30 Dec 2022 at 19:40, Florian Schmaus wrote: > On 30.12.22 11:05, Dave Cridland wrote: > > On Thu, 22 Dec 2022 at 09:23, Matthew Wild > <mailto:mwi...@gmail.com>> wrote: > > On Wed, 21 Dec 2022, 15:05 Florian Schmaus, > <mailto:f...@geekp

Re: [Standards] NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

On Tue, 13 Dec 2022 at 18:04, Jonas Schäfer wrote: > Version 0.1.0 of XEP-0474 (SASL SCRAM Downgrade Protection) has been > released. > I had a long discussion off-list with Thilo on this, and I broadly think it has very little utility - at best, you can tell if you've been downgraded *to* a

Re: [Standards] Proposed XMPP Extension: Stream Limits Advertisement

On Thu, 22 Dec 2022 at 09:23, Matthew Wild wrote: > On Wed, 21 Dec 2022, 15:05 Florian Schmaus, wrote: > >> >> Zash's proposal is, as far as I understand it, just an optimization >> allowing a sending entity to determine if a stanza will hit the limit or >> not, without trying to actually send

Re: [Standards] XEP-0388 SASL2: #2 Inline features

On Sat, 19 Nov 2022 at 18:50, Matthew Wild wrote: > On Sat, 19 Nov 2022 at 18:31, Dave Cridland wrote: > > On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch wrote: > >> > >> The stream feature wrapper is just a neat wrapper for all > >> stream features that

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

On Sat, 19 Nov 2022 at 18:34, Matthew Wild wrote: > On Sat, 19 Nov 2022 at 15:14, Dave Cridland wrote: > > > > I commented about this on the PR, but that seems to have been dismissed, > so again, for the list: > > > > * I'm not convinced this is required to b

Re: [Standards] XEP-0388 SASL2: #2 Inline features

On Sat, 19 Nov 2022 at 16:33, Daniel Gultsch wrote: > The stream feature wrapper is just a neat wrapper for all > stream features that can be inlined into SASL to announce themselves. > Yes ISR works without inline but that's not the point. > > Well, that wasn't in fact the point I was making

Re: [Standards] XEP-0388 SASL2: #2 Inline features

On Sat, 22 Oct 2022 at 22:29, Thilo Molitor wrote: > Again, MattJ already explained this well: > https://mail.jabber.org/pipermail/ > standards/2022-October/038998.html > > > SASL2 allows for inlining additional elements into

Re: [Standards] XEP-0388 SASL2: #1 client-identifier

I commented about this on the PR, but that seems to have been dismissed, so again, for the list: * I'm not convinced this is required to be a mandatory feature of SASL2, despite its obvious utility, but I'm not going to argue very strongly that it shouldn't be. * I *am* convinced that an id

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

On Wed, 19 Oct 2022 at 16:02, Thilo Molitor wrote: > Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland: > > Small point: GS2 doesn't ever allow clients to know if channel binding is > > proven, since the channel binding data is passed in the clear to the >

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

On Wed, 19 Oct 2022 at 14:59, Thilo Molitor wrote: > That's a wekness of SCRAM itself. Channel-binding problems will be > detected > after the client-final-message as well. > Small point: GS2 doesn't ever allow clients to know if channel binding is proven, since the channel binding data is

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote: > Title: SASL SCRAM Downgrade Protection > URL: https://xmpp.org/extensions/inbox/xep-downgrade-prevention.html Any attacker able to manipulate the data coming from the server such that the client sees a restricted set of TLS channel bindings

Re: [Standards] Proposed XMPP Extension: SASL SCRAM Downgrade Protection

404? On Wed, 12 Oct 2022 at 17:17, Jonas Schäfer wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: SASL SCRAM Downgrade Protection > Abstract: > This specification provides a way to secure the SASL and SASL2 > handshakes against method and channel-binding

Re: [Standards] Channel binding and token authentication

On Tue, 27 Sept 2022 at 12:59, Matthew Wild wrote: > On Tue, 27 Sept 2022 at 12:31, Dave Cridland wrote: > > On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: > >> On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > >> > - I seem to remember that HT-* derives

Re: [Standards] Channel binding and token authentication

On Tue, 27 Sept 2022 at 11:51, Matthew Wild wrote: > On Tue, 27 Sept 2022 at 11:36, Dave Cridland wrote: > > On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: > >> > >> On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > > I'd not considered web clients

Re: [Standards] Channel binding and token authentication

On Tue, 27 Sept 2022 at 09:59, Matthew Wild wrote: > On Tue, 27 Sep 2022, 09:46 Dave Cridland, wrote: > >> Before committing to this, some observations: >> >> - HT-*-NONE is needed for cases where there's no TLS at all. These are >> rare, but there's legitimate

Re: [Standards] Channel binding and token authentication

On Tue, 27 Sept 2022 at 08:39, Daniel Gultsch wrote: > But I agree that it should be optional; I already said this in the ISR > thread: There are plenty of scenarios where channel binding is not an > option. > Before committing to this, some observations: - HT-*-NONE is needed for cases where

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch wrote: > And yes we are currently implementing it. That's why I’m providing > feedback on the XEP. And yes we are using it with compression and yes > we do terminate TLS early and can’t use HT-* and yes we use PLAIN for > regular logins too and

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

On Wed, 24 Aug 2022 at 12:19, Matthew Wild wrote: > On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch wrote: > > > > > And yes we are currently implementing it. That's why I’m providing > > feedback on the XEP. And yes we are using it with compression and yes > > we do terminate TLS early and can’t

Re: [Standards] XEP Versioning

Hi, I like that we're documenting the versioning mechanism we use for XEPs, so - to be clear - I don't object to this change at all. I'm not so sure on the rationale given, though: @horazont The reason for specifying that topic was that @wurstsalat3000

Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)

On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch wrote: > I now realize that I get hung up on PLAIN at little bit in my previous > e-mail. But what I was really saying is that ISR should allow any SASL > mechanism with HT-* being just one possible (although good) choice. > Right. HT is great, it

Re: [Standards] XEP-0388: Extensible SASL Profile - implementations?

Hi Matthew, I did an implementation for Openfire some years ago, including TOTP and other bits, and updated the XEP based on what I discovered. In practical terms, I think it should work well in its current state. The code I wrote is open source, but was never in a state to merge to the

Re: [Standards] Moving server-side MAM search forwards

On Sun, 12 Jun 2022 at 18:02, Matthew Wild wrote: > Hi Dave, > > On Sun, 12 Jun 2022 at 13:19, Dave Cridland wrote: > > > > Hey Matthew, > > > > Many thanks for this, and also many thanks for raising these on the list > first instead of quietly via t

Re: [Standards] Moving server-side MAM search forwards

On Wed, 8 Jun 2022 at 12:20, Matthew Wild wrote: > On Mon, 6 Jun 2022, 08:56 Kevin Smith, wrote: > >> Hi Matt, >> >> -- Original Message -- >> From: "Matthew Wild" >> To: "XMPP Standards" >> Sent: 03/06/2022 10:50:03 >> Subject: [Standards] Moving server-side MAM search forwards >> >>

Re: [Standards] Moving server-side MAM search forwards

Hey Matthew, Many thanks for this, and also many thanks for raising these on the list first instead of quietly via the document author, and my apologies for a slow response. On Fri, 3 Jun 2022 at 10:51, Matthew Wild wrote: > Hi folks, > > Thanks to Guus's persistence, I finally took time to

Re: [Standards] Danish chains too short

On Thu, 10 Feb 2022 at 04:46, Travis Burtrum wrote: > On 1/30/22 11:38, Dave Cridland wrote: > > But the default choice to maximize interop should be to include the > > trust anchor. > > > > 1) Do people agree? > > No. Because... > > > 2) If so, wher

[Standards] Danish chains too short

Hi all, XMPP servers typically do not include the trust anchor in the X.509 chains they present to peers during TLS negotiation. This is broadly in line with advice given in https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2, where it notes that a certificate representing a trust anchor

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

On Sun, 9 Jan 2022 at 13:38, Marvin W wrote: > Given that (as you know) I originally proposed this for XEP-0428 and you > argued against, I'd say that updating XEP-0428 *was* my first choice, > but it is your right as author to refuse this. > XEP-0001: XMPP Extension Protocols

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

On Sun, 9 Jan 2022 at 13:38, Marvin W wrote: > On 09.01.22 13:24, Dave Cridland wrote: > > Still, as written, the ability send a message which is rendered in > > *radically* different ways in different clients just fills me with > > unease. Fallback bodies are nasty like

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

On Sun, 9 Jan 2022 at 10:58, Marvin W wrote: > Hi, > > On 08.01.22 23:34, Dave Cridland wrote: > > In this case, you've got a pre-existing fallback extension that you > > *could* - and indeed *have* - proposed extending in exactly this way > > without any problem,

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

On Sat, 8 Jan 2022 at 23:04, Maxime Buquet wrote: > 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 Names

Re: [Standards] Proposed XMPP Extension: Message Replies

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: Message Replies > Abstract: > This document defines a way to indicate that a message is a reply to a > previous message. > > URL:

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

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: Compatibility Fallbacks > Abstract: > This document defines a way to indicate that a specific part of the > body only serves as fallback and which specification the

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

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:

Re: [Standards] Proposed XEP-0060 Changes

On Wed, 15 Dec 2021 at 16:14, Florian Schmaus wrote: > On 15/12/2021 15.41, Dave Cridland wrote: > > For the benefit of others wanting context, this is XEP-0060 section > > 8.2.4. The existing SHOULD in this section is probably wrong, in as much > > as it's either mean

Re: [Standards] Proposed XEP-0060 Changes

On Wed, 15 Dec 2021 at 14:51, Kevin Smith wrote: > On 15 Dec 2021, at 14:41, Dave Cridland wrote: > > So, summary: I'd replace the opening text to 8.2.4 with: > > > > "If the owner wishes to change the configuration, they submit a > completed configuration form. The

Re: [Standards] Proposed XEP-0060 Changes

For the benefit of others wanting context, this is XEP-0060 section 8.2.4. The existing SHOULD in this section is probably wrong, in as much as it's either meaningless (to configure a node, obviously you send the form) or else egregious (if you pull the form and the node seems to be set right, why

[Standards] Process Wonkery

All, Kev Smith noted that we have been a bit weird about handling updates to XEPs from authors during the Proposal phase (that is, Proposed state, from Last Call through to completion of a vote to Stable). 1) When can authors update XEPs? XEP-0001 is fairly unspecific about when updates to a

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

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

Re: [Standards] Stable is the new Draft

On Tue, 7 Sept 2021 at 16:44, Peter Saint-Andre wrote: > On 8/31/21 9:41 AM, Jonas Schäfer wrote: > > > The term "Draft" for our non-Final but also non-Experimental standards > has > > been adopted from our "mother" organization, the Internet Engineering > Task > > Force. The IETF has since

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

On Tue, 7 Sept 2021 at 16:23, Georg Lukas wrote: > Hello everyone, > > given that XEP-0313 is up for recall in tomorrow's Council meeting, I'd > like to sort my long list of issues into blocking and non-blocking. > Fixing the blocking ones is a requirement for me to change my vote to > something

Re: [Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS

Old Thread Alert!! On Thu, 13 Feb 2020 at 04:33, Travis Burtrum wrote: > In practice, it doesn't matter, the server administrator can't actually > count on anyone accessing any of the SRV records in any specific order > because any network could have any types of blocks/constraints on it. >

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

On Wed, 11 Aug 2021 at 22:49, Peter Saint-Andre wrote: > On 8/11/21 3:35 PM, Kim Alvefur wrote: > > On Wed, Aug 11, 2021 at 02:25:56PM -0600, Peter Saint-Andre wrote: > >> Too bad we didn't stick to our guns in 2003 and insist on two ports > >> instead of one, but STARTTLS was the recommended

Re: [Standards] [Council] XMPP Council Agenda 2021-07-21

Hi all, I'm (almost certainly) unable to attend this meeting due to travel, but I have reviewed the Pubsub Caching Hint XEP and have no objection to publishing. I'm never sure if I can vote in advance or not, but +1 if I can. Dave. On Tue, 20 Jul 2021 at 16:00, Jonas Schäfer wrote: > Hi

Re: [Standards] UPDATED: XEP-0458 (Community Code of Conduct)

Hi all, There was an interesting discussion, alongside a reference to a free book I'd not come across, in the XSF Chatroom starting here by "pep.": XSF Discussion - 2021-06-28 (xmpp.org) Of particular note here is how we

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

Updates: On Fri, 11 Jun 2021 at 15:18, Dave Cridland wrote: > > > On Fri, 11 Jun 2021 at 13:19, Sam Whited wrote: > >> > Note also that this is not intended to mean that any XMPP developer's >> > behaviour will be scrutinised constantly - using, for example,

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

Updates: On Fri, 11 Jun 2021 at 21:12, Dave Cridland wrote: > > > On Fri, 11 Jun 2021 at 17:10, Kevin Smith wrote: > >> I’m just picking at replies here - as I said in the chatroom I think this >> is a generally positive direction and want to thank the people invo

Re: [Standards] [Council] XMPP Council Agenda 2021-06-23

Ahead of the meeting, in case my previous meeting overruns again: On Tue, 22 Jun 2021, 16:14 Jonas Schäfer, wrote: > Hi everyone, > > The next XMPP Council Meeting will take place on 2021-06-23 at 15:00Z in > xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to > the >

Re: [Standards] UPDATED: XEP-0377 (Spam Reporting)

On Tue, 22 Jun 2021, 16:40 Sam Whited, wrote: > Thinking about this more I wonder if client authors would have a use for > a disco#info node that returns the list of supported reporting reasons? > > Similarly, if we're going to do that, maybe clients don't need to know > anything about reporting

Re: [Standards] Un-deferring XEP-0377: Spam Reporting

On Sat, 19 Jun 2021 at 12:35, Sam Whited wrote: > Can we undefer XEP-0377: Spam Reporting? I don't have any changes that > need to be made to it, but it's also in use and not abandoned. It has > one or two implementations but I don't know of any services actually > using it so I don't think it's

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

On Fri, 11 Jun 2021 at 22:02, Kevin Smith wrote: > I think there’s an implied statement that actions are somehow more > significant than non-actions, but I think that’s probably not true. Actions > are a statement that the behaviour was unacceptable, non-actions are a > statement that the

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

asier, either. It may be as simple as noting that XSF Members, while held to a higher standard as regards the Code of Conduct, have certain immunities with regards to potential sanctions, and so members may have to take that into account when voting them in. > On 11 Jun 2021, at 15:18, Dave C

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

On Fri, 11 Jun 2021 at 13:19, Sam Whited wrote: > > Note also that this is not intended to mean that any XMPP developer's > > behaviour will be scrutinised constantly - using, for example, racist > > language in a talk about your XMPP project would be problematic here, > > but using sexualised

Re: [Standards] NEW: XEP-0458 (Community Code of Conduct)

On Fri, 11 Jun 2021 at 09:41, Andrew Nenakhov < andrew.nenak...@redsolution.com> wrote: > Yet another irrelevant document masquerading as a protocol extension. I > suggest stop using XEPs as an unsorted pile of various texts, or else > you'll soon have cookie recipes there. > If you want some

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

On Sat, 29 May 2021 at 16:10, Florian Schmaus wrote: > On 29/05/2021 13.08, Sam Whited wrote: > > I'll change the name if using "Working Group" is what's concerning you, > > fair enough, I can see how that makes this seem "official" somehow, > > I could imagine that using 'XSF' in the title is

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

his thing went ahead, as I said, and do so with the backing of the XSF both as a community and as an organisation. You appear to be keen that it is not a sanctioned activity. I'd like to understand why. > > —Sam > > On Sat, May 29, 2021, at 05:47, Dave Cridland wrote: > > > > > &g

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

—Sam > > On Fri, May 28, 2021, at 14:54, Dave Cridland wrote: > > Hey Sam, > > > > I'm a little worried about this, and how it squares with our IPR > > policies. > > > > What do you feel can't be done within the XSF here? > > > > Dave. > &

Re: [Standards] XSF (unofficial) Modernization Working Group looking for XEPs to discuss

Hey Sam, I'm a little worried about this, and how it squares with our IPR policies. What do you feel can't be done within the XSF here? Dave. On Fri, 28 May 2021 at 15:31, Sam Whited wrote: > Hi all, > > I'm doing another experiment with the office hours. Sometime in the > near future

Re: [Standards] Incorrect example in XEP-0198?

On Tue, 18 May 2021 at 20:38, Peter Saint-Andre wrote: > +1. Example 6 looks like a copy-paste error. Who wrote these specs?!? > > Thankfully, for years we either couldn't, or at least normally didn't, commit directly to the XEP repository ourselves, and left it to the Editor to actually commit

Re: [Standards] Incorrect example in XEP-0198?

On Fri, 7 May 2021 at 14:34, Edwin Mons wrote: > On 07/05/2021 14:33, Kevin Smith wrote: > > The text in question mentions wanting the connection terminated, which > suggests stream error is right (which also seems logically sound to me). > > > > "If a server receives a second element it SHOULD

Re: [Standards] XEP rendering template for CVEs

On Wed, 28 Apr 2021 at 18:46, Georg Lukas wrote: > Therefore, and after some discussions on the xsf@ MUC, I have prepared a > new XEP element `` that allows the XEP author to add a visually > distinctive reference to previous failures of implementing that XEP > properly. The goals of this new

Re: [Standards] NEW: XEP-0457 (Message Fancying)

Certainly meets all the use cases. On Thu, 1 Apr 2021 at 06:20, Jonas Schäfer wrote: > Version 1.0.0 of XEP-0457 (Message Fancying) has been released. > > Abstract: > This specification defines a Unicode-formatted fancy text syntax for > use in instant messages. > > Changelog: > Initial

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

On Wed, 24 Mar 2021 at 16:02, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0280. > > Title: Message Carbons > Abstract: > In order to keep all IM clients for a user engaged in a conversation, > outbound messages are carbon-copied to all interested

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

On Tue, 16 Mar 2021 at 20:21, Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0313. > > Title: Message Archive Management > Abstract: > This document defines a protocol to query and control an archive of > messages stored on a server. > > URL:

Re: [Standards] XEP Wishlist: Encrypted Information Storage

Hiya, On Sat, 13 Mar 2021 at 13:00, Paul Schaub wrote: > Hey everyone! > > It would be nice to have a way for clients to store end-to-end encrypted > information on the server (imagine Private XML Storage or private PubSub > nodes, but encrypted). > > As I heard that there are efforts of

Re: [Standards] Proposed XMPP Extension: Content Rating Labels

On Tue, 9 Mar 2021 at 21:18, Jonas Schäfer wrote: > On Dienstag, 9. März 2021 21:54:37 CET Florian Schmaus wrote: > > On 3/9/21 9:11 PM, Jonas Schäfer (XSF Editor) wrote: > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > > > Title: Content Rating Labels > > >

Re: [Standards] Syncing multi-device on XEP-0384: OMEMO

On Wed, 24 Feb 2021 at 22:34, Paul Schaub wrote: > I wouldn't be too concerned about periods where the root chain is not > advanced. The crypto should still be strong enough to protect the message > contents against offline attacks. > > With MLS and Signal, my understanding is that advancing the

Re: [Standards] XML Element Ordering

On Mon, 22 Feb 2021 at 19:02, Florian Schmaus wrote: > On 2/18/21 12:16 AM, Dave Cridland wrote: > > On Wed, 17 Feb 2021 at 19:22, Kevin Smith > <mailto:kevin.sm...@isode.com>> wrote: > > > > On 17 Feb 2021, at 18:42, Florian Schmaus >

Re: [Standards] Council Minutes 2021-02-03

not in any way I care about. > I feel like there’s something in the spec I am missing here. > XMPP doesn't say anything at all about reordering as far as I'm aware, meaning we fall back to XML itself, which treats ordering of child elements as significant. > > > On Feb 17, 2021,

Re: [Standards] XML Element Ordering

I think, broadly, that stanza contents can be re-serialized in any way that would not alter the canonicalized form, and not otherwise. So if you want to reorder attributes, go for it. Reorder elements, not so much. There are some obvious exceptions: Servers can insert new elements just fine and

  1   2   3   4   5   6   7   8   9   10   >