On Tue, Mar 06, 2012 at 09:53:37PM +0000, Dave Cridland wrote: > 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.
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. -- _// Carlo v. Loesch
