XSF Editor Team - 2018-02-17

jonasw, do you intent to bump the http upload namespace after the latest merge?

ah damn

will do

I'm myself not entirely sure if it's required, but I think so

thanks for the reminder

although, I’ll double-check

I think I’m confusing this change with something else

yes I am

the NS-bump-neednig-change was XEP-0401

jonasw, I think http upload also needs a bump, otherwise a client may show http upload as available with an http upload service that also requires disallowed headers

I also don’t think that it should be the editors job to judge this

I think it's the editors job to ensure that changes without a namespace bump are backwards compatbile

Flow, a server could also just be misbehaving, so the behaviour would be the same. I’m not sure this warrants a bump.

jonasw, I don't follow that argumentation

lemme retry

the effect of the lack of namespace bump is that a client may try a request only to learn that it won’t be able to upload because of disallowed headers

so the upload would fail due to a policy-violation or something

But then the client may already displayed the availability of http upload to the user

sure

I’m not entirely sure if this is a problem, because (a) I don’t think we’ve got anything in the wild which does this and (b) a server could also be misconfigured to have the same situation

you never know how many users are hidden somewhere and following (b) would mean that we never had to do namespace bumps

where are the procedures for bumping namespaces written down?

I can’t find it in XEP-0001

I'd probably always bump as soon as the rules change so that old implementations would violate them, as it was the case here, simply because I don't think that we can build an interoperable and federated system without doing so. The lazy way will be more painful in the long run

jonasw, there are none written down AFAIK, besides "if non backwards compatbile change, then bump"

I’d like to have that written down, because I don’t want to get into arguments over this with either council or authors.

Not sure if more needs to be written down

This is some sort of special case, because as you said a client will find out if the upload compononent follows the new rules or not

I tend to agree in general, but in this specific case, I think it is very unlikely that this is a problem. none of the big object storage services we surveyed the last week did use any header other than the three listed.

so unless somebody did a home-brew solution before e.g. prosody even did have support for that version of the XEP which used some arcane headers/protocol not used by any major block storage *and* which is based on HTTP headers, I don’t think there’ll be an issue.

I know that this is not a super-great or solid argument, but given the limited resources in the developer community, I think that bumping the namespace again just after conversations dropped support for the first namespace would bind more resources than worth it

(prosody only gained support for :0 recently-ish)

I know that implementors don't like bumping namespace, I'm also affected, because of that and the particular case I'm not going to pursue this further. But I think that the editors here should be the counterweight when it comes to namespace bumps

Also your argument would also hold for PR# 585, wouldn't it?

(btw, I think we’re making breaking changes to MIX all the time currently)

Flow, no, I think the difference between the two cases is that with HTTP upload, it is deemed unsafe to follow the old protocol. so even *if* the client could discover that upload:0 was supported (suppose we bump to upload:1 now), it wouldn’t want to follow that. In this case, if the client can discover that invite:0 is supported, it might choose that. ✏

(if it wanted to follow the upload:0, it could simply do so.)

IIRC, while a XEP is still experimental, the author can do any breaking change they want and don’t have to care about backwards compatibility.

yeah, that argument, too

Namespace bumps could be done only in drafts, if we didn’t care enough about that.

Link Mauve, IIRC or IMHO? ;)

IIRC, I was looking for a source but I can’t find it.

I don't find that written down anywhere

And I would also hope that we require namespace bumps also for experimental XEPs

(MIX also had a namespace bump)

maybe we should ask Council to write a set of rules for this?

> Note: An Experimental specification is a work in progress and may undergo significant modification before advancing to a status of Draft. While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product (as opposed to an experimental branch).

(XEP-0001)

I guess we could technically be saying "f*** you for using experimental".

only issue with that is that many important XEPs are experimental

indeed

but that’s a separate issue

that's why i'm arguing for another stage "incubating" before experimental, where namespace bumps are not required

and where xeps have a well known location but not a number

I’d rather argue for getting our act together and advance things ;-).

sure, but unrealistic

> Link Mauve > IIRC, while a XEP is still experimental, the author can do any breaking change they want and don’t have to care about backwards compatibility. Not really. Breaking changes still typically get bumps in Experimental.

But we can certainly be more liberal in our definitions of 'breaking changes' than once it's Draft.

Typically yes, but I couldn’t find any document saying we should do it one way or the other one.