[Standards] OBSOLETE: XEP-0190 (Best Practice for Closing Idle Streams)
XMPP Extensions Editor
Abstract: This document specifies a best practice for closing an XML stream that is perceived to be idle.
Changelog: Changed status to Obsolete because it is superseded by RFC 6120. (psa)
Diff: http://xmpp.org/extensions/diff/api/xep/0190/diff/1.0/vs/1.1
Carlo v. Loesch
I wouldn't really say it's obsolete, because if you want to build
a solid server experience, it's safer to follow XEP-0190 than RFC-6120.
I also wouldn't call it superseded, it may just be perceived as superseded
by some.
Yes, I originally co-wrote that paragraph on closing idle streams in
RFC-6120 but you managed to water it down later, so now it can be either
implemented right or wrong depending on your preferences or patience.
From what I read in the RFC, packets er stanzas can still get lost on
idle streams if bad luck er bad timing happens. It happens.
Oh, and thanks for asking.
By the way, last year we made some benchmarks.. The PSYC protocol syntax
is on average some dozen times more efficient than XMPP in both processing
speed and bandwidth. Maybe we should look into that idea of doing XMPP-S2S
over PSYC again... Details: http://lib.psyc.eu/bench/
--
_// Carlo v. Loesch
_// https://symlynX.com/CvL
Dave Cridland
> I wouldn't really say it's obsolete, because if you want to build
> a solid server experience, it's safer to follow XEP-0190 than
> RFC-6120.
> I also wouldn't call it superseded, it may just be perceived as
> superseded
> by some.
>
> Yes, I originally co-wrote that paragraph on closing idle streams in
> RFC-6120 but you managed to water it down later, so now it can be
> either
> implemented right or wrong depending on your preferences or
> patience.
> From what I read in the RFC, packets er stanzas can still get lost
> on
> idle streams if bad luck er bad timing happens. It happens.
I was also concerned that XEP-0190 might be a more detailed write-up
on the nature of closing streams, and this triggered me into
re-reading RFC 6120 on the subject.
There's two sections of note, here:
Section 4.4 covers everything in XEP-0190 �2 in significantly higher
detail. My only concern is that there's some fairly confusing detail
about multiple streams and multiple TCP connections that I didn't
quite follow, to be honest.
Section 4.6.3 dicusses idle peers in more detail, and in particular
discusses TCP checking, and other items really not covered in
XEP-0190.
But basically, yes, this XEP is superceded entirely, much to my
surprise, and I think the subject is given a better treatment, with
that one possible exception mentioned above.
Could you elaborate on where you think the RFC is lacking?
> Oh, and thanks for asking.
I agree it'd be better to have gven you a heads-up on this.
I also think that technically, this XEP should be "deprecated" rather
than "obsoleted" - it is out of date, rather than wrong.
An argument of keeping it Active, whilst adding a note to the
relevant sections of RFC 6120, would also seem reasonable.
Dave.
--
Dave Cridland - mailto:da...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Peter Saint-Andre
> I also think that technically, this XEP should be "deprecated" rather
> than "obsoleted" - it is out of date, rather than wrong.
Changing the status of a XEP to Obsolete does mean the protocol is
wrong, it means that you shouldn't implement the spec. In the case of
XEPs 237, 192, 193, and 190 (all changed to Obsolete recently), we're
saying you shouldn't implement the spec because the proper documentation
is now in the RFCs (these XEPs were used only for the purpose of
discussing changes we'd make to the RFCs; with publication of the RFCs,
those XEPs are now Obsolete).
Peter
--
Peter Saint-Andre
https://stpeter.im/
Kevin Smith
> On 3/6/12 2:53 PM, Dave Cridland wrote:
>
>> I also think that technically, this XEP should be "deprecated" rather
>> than "obsoleted" - it is out of date, rather than wrong.
>
> Changing the status of a XEP to Obsolete does mean the protocol is
> wrong, it means that you shouldn't implement the spec.
There's a "not" missing here.
I had the same concern about "deprecated" vs "obsoleted", so I checked
XEP-0001 and decided obsoleted was fine (although I grant we skipped
the deprecated step that we should have taken if we were being
precise).
/K
Peter Saint-Andre
> On Tue, Mar 6, 2012 at 10:01 PM, Peter Saint-Andre <stp...@stpeter.im> wrote:
>> On 3/6/12 2:53 PM, Dave Cridland wrote:
>>
>>> I also think that technically, this XEP should be "deprecated" rather
>>> than "obsoleted" - it is out of date, rather than wrong.
>>
>> Changing the status of a XEP to Obsolete does mean the protocol is
>> wrong, it means that you shouldn't implement the spec.
>
> There's a "not" missing here.
There is, thanks for the correction.
> I had the same concern about "deprecated" vs "obsoleted", so I checked
> XEP-0001 and decided obsoleted was fine (although I grant we skipped
> the deprecated step that we should have taken if we were being
> precise).
Ideally, we would have deprecated them the moment the RFCs were published.
Philipp Hancke
> Section 4.4 covers everything in XEP-0190 �2 in significantly higher
> detail.
From what I recall discussing this about a year ago:
The only stream error that 0190 is concerned with is connection-timeout
(in the 3920 sense, 6120 redefines this in 4.9.3.4).
Section 4.4 in 6120 is applying this to any stream error.
I am looking forward to your explanation of how and why to parse the
reply to... bad-format. Additionally, when sending a stream error, why
MUST the sender wait for the peer to acknowledge this?
It's not like the sender of the stream error is going to process any
more stanzas anyway...
Dave Cridland
Hmmm...
"""
9.9 Deprecated
A XEP of any type is in the Deprecated state if the XMPP Council has
determined that the protocol defined therein is out of date and that
new implementations are no longer encouraged (e.g., because it has
been superseded by a more modern protocol).
9.10 Obsolete
A XEP of any type is changed from Deprecated to Obsolete if the XMPP
Council has determined that the protocol defined therein should no
longer be implemented or deployed.
"""
I think perhaps those descriptions need updating, then - they
specifically refer to "the protocol defined therein", rather than the
specification per-se.
They're Obsolete in the IETF sense, for sure; but I'm not quite sure
that's the same sense as we've defined in XEP-0001.
Peter Saint-Andre
> I think perhaps those descriptions need updating, then - they
> specifically refer to "the protocol defined therein", rather than the
> specification per-se.
>
> They're Obsolete in the IETF sense, for sure; but I'm not quite sure
> that's the same sense as we've defined in XEP-0001.
Patches welcome.
Carlo v. Loesch
> > I also think that technically, this XEP should be "deprecated" rather
> > than "obsoleted" - it is out of date, rather than wrong.
>
> Changing the status of a XEP to Obsolete does mean the protocol is
> wrong, it means that you shouldn't implement the spec. In the case of
> XEPs 237, 192, 193, and 190 (all changed to Obsolete recently), we're
> saying you shouldn't implement the spec because the proper documentation
> is now in the RFCs (these XEPs were used only for the purpose of
which is inaccurate.. 0190 isn't wrong, so you shouldn't obsolete it.
you just confirmed dave's point.
Carlo v. Loesch
> There's two sections of note, here:
>
> about multiple streams and multiple TCP connections that I didn't quite
> follow, to be honest.
4.4 looks okay, apparently mostly what I submitted years ago. The thing
about multiple TCP is XMPP-specific, you need to point out to implementers
that each TCP link needs to be treated separately, no matter what it was
used for - this is in immediate contrast with the next point about
unidirectionality so it could use some more clarification. If you close
a socket and the other side replies by closing the wrong one - oops!
The Security Warning is new. I like it, it confirms the reasons why it is
important to close sockets properly - not just packet loss - even
security is affected.
> Section 4.6.3 dicusses idle peers in more detail, and in particular
> discusses TCP checking, and other items really not covered in XEP-0190.
First of all the implementation note in 4.6 can be misleading, as it
says exactly the opposite of what I just explained.
The mistake in RFC 6120 comes at 4.6.3 (assuming implementors will not
misunderstand 4.6.2 or 4.6.1 for that). It doesn't enforce closing the
stream but allows to error out instead. This legalizes all the broken
server behaviors we had when I wrote that XEP and maybe we still have
them to date: If you're too lazy to wait for the other side to close
the socket, you can just kick it. The RFC lets you do it.
Implementations that take that option introduce a chance for message loss.
The way XEP-0190 does not allow detours and ONLY allows you to
close the stream is the correct way from the perspective of design of
unix's socket API, so XEP-0190 isn't just simpler and easier to read
than the RFC, it's also more accurate.