moparisthebest: SamWhited might know the right people there...
neshtaxmpphas left
lskdjfhas left
wurstsalathas left
neshtaxmpphas joined
Nekithas joined
Yagizahas left
Yagizahas joined
larmahas joined
Yagizahas left
Yagizahas joined
lskdjfhas joined
Yagizahas left
Yagizahas joined
Yagizahas left
Yagizahas joined
Yagizahas left
Yagizahas joined
karoshihas joined
larmahas left
lskdjfhas left
larmahas joined
alacerhas left
lskdjfhas joined
lorddavidiiihas joined
lnjhas joined
larmahas left
lskdjfhas left
rtq3has left
goffihas joined
Seve
jonas’, what kind of changes can move a XEP to Deferred state?
Ge0rG
Seve: no changes for a year
wurstsalathas joined
Seve
Ge0rG, yes, but can changes in the document move it to Deferred? Just trying to understand the following sentence: "Only substantial, non-editorial changes count as activity (or updates) for the purpose of considering moving a XEP from or to Deferred state." What kind of changes can move a XEP to Deferred?
Ge0rG
Seve: none
Ge0rG
Seve: that sounds like an unfortunate wording
ThibGhas left
kokonoehas left
kokonoehas joined
Seve
Ge0rG, thank you, I just wanted to check just in case https://github.com/xsf/xeps/pull/780/files
neshtaxmpphas left
Ge0rG
Seve: ah, it actually does have a meaning: editorial changes don't count when checking whether to move *to* Deferred
alacerhas joined
neshtaxmpphas joined
lnjhas left
alacerhas left
alacerhas joined
Seve
Ge0rG: may be too early for me then! I'll check it out later, on my bike. Thank you :)
Ge0rG
Don't read and drive!
olihas joined
mikaelahas joined
APachhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
olihas left
olihas joined
olihas left
olihas joined
andyhas joined
mikaela
> No DoX servers on there yet though :)
What is DoX? I thought the X was to denote T/H without typing longly?
Oh, DNS over XMPP?
jonas’
Seve, the point is, editorial changes do *not* count when considering whether to move a XEP to deferred. I.e. if it has received editorial changes (but no substantial, non-editorial changes) over 12 months, it still moves to deferred.
ThibGhas joined
blablahas joined
nycohas left
lskdjfhas joined
larmahas joined
blablahas left
neshtaxmpphas left
lskdjfhas left
nycohas joined
mtavareshas joined
olihas left
olihas joined
kokonoehas left
blablahas joined
kokonoehas joined
rtq3has joined
404.cityhas joined
404.city Supporthas joined
neshtaxmpphas joined
rtq3has left
lskdjfhas joined
Seve
jonas’, that way is understandable, but I'm not sure if the problem here is my poor English or the wording. I will try to check it again on the evening today and see, because I'm still so-so with the "from or to", but my poor English has many chances to be the problem here :)
larmahas left
jonas’
heh
jonas’
I can fix the wording either way
jonas’
please leave a comment on the PR so that I don’t forget
Kev
For the little it's worth, the wording seems fine to me.
Kev
Because there are changes from and to deferred, and the type of updates done affects both.
blablahas left
flow
But isn't question if the wording is fine for people with less knowledge about how the process works. And obviously it already confused people. If it can be improved so that it is easier to understand, then we should
jonas’
(and I will)
jonas’
Kev, I’m still not convinced that the things XEP-0001 says about versioning are sufficient to simply refer to that from the text, because it doesn’t at all mention how editorial changes affect versioning, AFAICT
Kev
Indeed, isn't that the point? That editorial changes are out of scope of the process. They don't need approval, they don't need 'Updated Versions' (in XEP-0001 speak), they don't trigger moves from Deferred, etc.
blablahas joined
flow
Is it part of the process specification that they don't need approval and stuff?
G0s+has joined
Kev
It's part of xep 1 that immaterial changes to Draft don't need approval, yes.
Oh, here https://mail.jabber.org/pipermail/council/2007-March/002057.html
Zash
> Ralph -1 pending removal of service discovery section. Peter to remove and publish version 0.3.
Zash
So, ask if ralphm remembers what the reasoning was
ralphm
Let me think.
neshtaxmpphas left
alacerhas left
alacerhas joined
ralphm
I'd have to look at the diffs and discussion logs.
wurstsalathas left
Zash
Doesn't seem to be any logs from 2007 in the current archive tho
ralphm
Doesn't mean I don't have them.
Zash
I would guess that it makes sense to just always stamp on delay since the receiver should ignore what they don't understand
ralphm
Maybe also because it is a format that can also be at a different level than as the child of a stanza.
ralphm
I'll look into it later, when back home
neshtaxmpphas joined
alacerhas left
lskdjfhas left
ralphm
Still remote, but seems the log files at logs.jabber.org have 404'd since 2007, though there was always an index. Maybe intosi or Kev can comment on this.
typikolhas joined
flow
> Zash> I would guess that it makes sense to just always stamp on delay since the receiver should ignore what they don't understand
flow
then we should rename it to timestamps
wurstsalathas joined
Zash
When *delayed*, not always
flow
but then I need to check if my service would add <delayed/> by doing disco, no?
flow
background is https://medium.com/p/48806d283e6e/info
Zash
You know who did it by looking at the @from attribute
larmahas left
Zash
It seems sevral people seem to want to use delayed delivery for a generic timestamp thing. I think you need a new XEP with different semantics for that.
flow
I receive a message stanza, how do I know if it got delayed or not? If there is no <delay/> tag on it then it may also because the service does not add them at all
alameyohas left
alameyohas joined
typikolhas left
Zash
Well then you don't know.
neshtaxmpphas left
moparisthebest
service discovery doesn't change that does it?
APachhas left
flow
moparisthebest, if the service announces the feature and if it is specified that it will add <delay/> if it does so
flow
I always felt that it would have been better if we hand't done <delay/> but <timestamp/>
flow
akin to what you'll find in your mail headers
moparisthebest
so you are trying to distinguish between "server announces delay but not marked delayed so it definitly wasn't delayed" and "maybe it was delayed maybe it was not" ?
andyhas left
flow
moparisthebest, yep
Zash
Why haven't you submitted a XEP about it?
Zash
You mean like trace headers, ie Received?
moparisthebest
I wouldn't advise showing "maybe it was delayed maybe not" to users, that kind of thing would anger them
moparisthebest
"XMPP sucks, can't even tell if it was delayed or not"
Zash
INSTANT MESSAGING
flow
Zash, yes, like 'Received', I always expected that such a XEP does not has a chance of getting accepted
moparisthebest
I think it'd be better to always assume not delayed, then if a user complains, blame it on their network connection :D
flow
but I would possibly try anyway
Zash
flow: I want the part where it records the security status of the connection it received from
moparisthebest
so a "I promise it was encrypted but may be lying" element Zash ?
flow
Zash, good point, so we could sneak in timestamp by a generic "trace" extension xep
alameyohas left
flow
which also records more metadata about the connection the stanza was received
moparisthebest
isn't e2e vastly superior there, aka "I promise was encrypted via this cryptographic proof"
flow
moparisthebest, depends on your goal
flow
it is mostly interestant for statistic and debug use cases, but not for protection/security
flow
*interesting
Zash
moparisthebest: It would be for debugging primarily, which also means it probably doesn't need to go on every stanza
Zash
Could go on a modified ping of some sort
flow
meh, but I want my timestamps on every stanza
Zash
flow: Take 203, reword the semantics, submit, ???, PROFIT!
flow
but the ping thing is interesting, that way you could record the stream information of every involved stream in both directions
Zash
Also, I'd wanna be careful with stuff that's added on every stanza
flow
true, but there is a need for timestamps and xep203 commonly gets misunderstood by people https://medium.com/@les92raf/oh-i-get-that-right-xep-0203-can-serve-as-timestamp-xep-cb20020e8104
flow
but maybe re-adding disco to xep203 and explicitly pointing out the use-case as "timestamp XEP" is sufficient