Re: Extending XEP-0313 with trimming support

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:
>> On Tue, 2026-03-31 at 11:59 +0100, Kevin Smith wrote:
>>> I think Matthew’s change is doing this the right way for Stable -
>>> Stable allows changes to the XEP as long as they’re
>>> backwards/forwards compatible, which AFAICS Matthew’s proposal is.
>> 
>> 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”.

/K

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