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
jcbrandhas left
jcbrandhas joined
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?
Guushas left
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
jcbrandhas left
Kevhas left
jcbrandhas joined
jcbrandhas left
jcbrandhas joined
Flowhas left
Guushas left
Guushas left
Guushas left
jcbrandhas left
Guushas joined
jcbrandhas left
Guushas left
Guushas joined
Guushas left
jcbrandhas left
jcbrandhas joined
jcbrandhas left
jcbrandhas left
jcbrandhas joined
Guushas joined
jcbrandhas left
Guushas left
Guushas joined
jcbrandhas joined
Tobihas left
jcbrandhas left
jcbrandhas joined
Tobihas left
Tobihas joined
jcbrandhas left
jcbrandhas joined
jcbrandhas left
jcbrandhas joined
flowhas joined
Tobihas joined
Tobihas joined
Tobihas left
Tobihas joined
Guushas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas left
Guushas joined
Guushas left
Guushas left
jcbrandhas left
jcbrandhas left
Guushas left
Guushas left
jcbrandhas left
jcbrandhas left
soulhas left
jcbrandhas left
jcbrandhas left
jcbrandhas joined
Guushas left
jcbrandhas left
Guushas left
jcbrandhas left
Guushas left
Guushas left
SamWhitedhas left
jcbrandhas left
jcbrandhas left
jcbrandhas joined
jcbrandhas left
jcbrandhas left
jcbrandhas joined
jcbrandhas left
jcbrandhas joined
SamWhitedhas left
SamWhitedhas left
Guushas left
jcbrandhas left
Guushas left
Guushas left
Guushas left
jcbrandhas left
Guushas left
SamWhitedhas left
Kevhas joined
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.