-
Flow
jonasw, do you intent to bump the http upload namespace after the latest merge?
-
jonasw
ah damn
-
jonasw
will do
-
Flow
I'm myself not entirely sure if it's required, but I think so
-
jonasw
thanks for the reminder
-
jonasw
although, I’ll double-check
-
jonasw
I think I’m confusing this change with something else
-
jonasw
yes I am
-
jonasw
the NS-bump-neednig-change was XEP-0401
-
Flow
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
-
jonasw
I also don’t think that it should be the editors job to judge this
-
Flow
I think it's the editors job to ensure that changes without a namespace bump are backwards compatbile
-
jonasw
Flow, a server could also just be misbehaving, so the behaviour would be the same. I’m not sure this warrants a bump.
-
Flow
jonasw, I don't follow that argumentation
-
jonasw
lemme retry
-
jonasw
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
-
jonasw
so the upload would fail due to a policy-violation or something
-
Flow
But then the client may already displayed the availability of http upload to the user
-
jonasw
sure
-
jonasw
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
-
Flow
you never know how many users are hidden somewhere and following (b) would mean that we never had to do namespace bumps
-
jonasw
where are the procedures for bumping namespaces written down?
-
jonasw
I can’t find it in XEP-0001
-
Flow
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
-
Flow
jonasw, there are none written down AFAIK, besides "if non backwards compatbile change, then bump"
-
jonasw
I’d like to have that written down, because I don’t want to get into arguments over this with either council or authors.
-
Flow
Not sure if more needs to be written down
-
Flow
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
-
jonasw
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.
-
jonasw
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.
-
jonasw
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
-
jonasw
(prosody only gained support for :0 recently-ish)
-
Flow
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
-
Flow
Also your argument would also hold for PR# 585, wouldn't it?
-
jonasw
(btw, I think we’re making breaking changes to MIX all the time currently)
-
jonasw
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 :0 was supported (suppose we bump to :up1 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.✎ -
jonasw
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. ✏
-
jonasw
(if it wanted to follow the upload:0, it could simply do so.)
-
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.
-
jonasw
yeah, that argument, too
-
Link Mauve
Namespace bumps could be done only in drafts, if we didn’t care enough about that.
-
Flow
Link Mauve, IIRC or IMHO? ;)
-
Link Mauve
IIRC, I was looking for a source but I can’t find it.
-
Flow
I don't find that written down anywhere
-
Flow
And I would also hope that we require namespace bumps also for experimental XEPs
-
Flow
(MIX also had a namespace bump)
-
jonasw
maybe we should ask Council to write a set of rules for this?
-
jonasw
> 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).
-
jonasw
(XEP-0001)
-
jonasw
I guess we could technically be saying "f*** you for using experimental".
-
Flow
only issue with that is that many important XEPs are experimental
-
jonasw
indeed
-
jonasw
but that’s a separate issue
-
Flow
that's why i'm arguing for another stage "incubating" before experimental, where namespace bumps are not required
-
Flow
and where xeps have a well known location but not a number
-
jonasw
I’d rather argue for getting our act together and advance things ;-).
-
Flow
sure, but unrealistic
-
Kev
> 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.
-
Kev
But we can certainly be more liberal in our definitions of 'breaking changes' than once it's Draft.
-
Link Mauve
Typically yes, but I couldn’t find any document saying we should do it one way or the other one.