XSF Editor Team - 2018-02-17


  1. Flow

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

  2. jonasw

    ah damn

  3. jonasw

    will do

  4. Flow

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

  5. jonasw

    thanks for the reminder

  6. jonasw

    although, I’ll double-check

  7. jonasw

    I think I’m confusing this change with something else

  8. jonasw

    yes I am

  9. jonasw

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

  10. 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

  11. jonasw

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

  12. Flow

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

  13. jonasw

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

  14. Flow

    jonasw, I don't follow that argumentation

  15. jonasw

    lemme retry

  16. 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

  17. jonasw

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

  18. Flow

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

  19. jonasw

    sure

  20. 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

  21. Flow

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

  22. jonasw

    where are the procedures for bumping namespaces written down?

  23. jonasw

    I can’t find it in XEP-0001

  24. 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

  25. Flow

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

  26. 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.

  27. Flow

    Not sure if more needs to be written down

  28. 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

  29. 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.

  30. 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.

  31. 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

  32. jonasw

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

  33. 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

  34. Flow

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

  35. jonasw

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

  36. 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.

  37. 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.

  38. jonasw

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

  39. 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.

  40. jonasw

    yeah, that argument, too

  41. Link Mauve

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

  42. Flow

    Link Mauve, IIRC or IMHO? ;)

  43. Link Mauve

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

  44. Flow

    I don't find that written down anywhere

  45. Flow

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

  46. Flow

    (MIX also had a namespace bump)

  47. jonasw

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

  48. 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).

  49. jonasw

    (XEP-0001)

  50. jonasw

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

  51. Flow

    only issue with that is that many important XEPs are experimental

  52. jonasw

    indeed

  53. jonasw

    but that’s a separate issue

  54. Flow

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

  55. Flow

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

  56. jonasw

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

  57. Flow

    sure, but unrealistic

  58. 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.

  59. Kev

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

  60. Link Mauve

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