Re: Extending XEP-0313 with trimming support

On Tue, 31 Mar 2026 at 12:28, Kevin Smith <[email protected]> wrote:
>
> On 31 Mar 2026, at 12:20, Matthew Wild <[email protected]> wrote:
> >
> > On Tue, 31 Mar 2026 at 12:09, Marvin W. via Standards
> > <[email protected]> wrote:
> >> I don't disagree that it is formally correct and allowed to have this
> >> change in a Stable XEP, but I believe the feature in of itself is more
> >> of Experimental quality, meaning we might want to do changes to it that
> >> are not backwards-compatible. If we introduce it into a Stable XEP, we
> >> can't do that. I also fail to see the benefit of adding it to the
> >> existing XEP over creating a new one.
> >>
> >> After all, we intentionally have multiple XEPs and not one single
> >> specification with a lot of optional parts. Denoting the status of
> >> features within our specification set is one of the benefits we earn
> >> from doing so. Let's make good use of it.
> >
> > I'm fine with this, if it's the consensus of the community/Council.
> >
> > I agree we are far from "everything in one specification", but I think
> > there is a balance to strike between having every little feature in
> > individual XEPs, and having everything related to, say, archive
> > management, in one place. MUC is suffering from the effects of the
> > "small bolted on XEPs" approach right now, and it makes it a pain for
> > implementers to figure out what's what.
>
> I think this is also all fair.
>
> A think we used to do, rarely, once upon a time, was having new specs as new documents, and as they got (lowercase) stable rolled them into existing documents. I suppose that would be an option here that would both address Marvin’s “we might need to change this after publishing” and Matthew’s “Let’s not duplicate the MUC fragmentation”.

That does seem like a sensible compromise. Publish as a new XEP, but
with the option of rolling it into XEP-0313 before Final if we decide
(based on adoption, implementation/deployment experience) that it
passes the bar for that.

Regards,
Matthew
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]