Re: [xmpp] Comments on draft-ietf-xmpp-websocket-05

Lance Stout <lance@andyet.net> Mon, 21 April 2014 22:29 UTC

Return-Path: <lance@andyet.net>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F9E1A02FB for <xmpp@ietfa.amsl.com>; Mon, 21 Apr 2014 15:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duK5AqFTMef9 for <xmpp@ietfa.amsl.com>; Mon, 21 Apr 2014 15:29:49 -0700 (PDT)
Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7AC1A02F7 for <xmpp@ietf.org>; Mon, 21 Apr 2014 15:29:49 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id um1so4209367pbc.30 for <xmpp@ietf.org>; Mon, 21 Apr 2014 15:29:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=phahUhaQL5a64ZUhLyUuh286LnqQtXYfklJ0pvctKng=; b=baAIEMtW7Uhj6qZULxFuq51bUi34w/8g95JBlDFOYvRUPJCDmKKKOo8cWEsXkBtnLv 6DuPO9KGq4Zxs/dmytITde1Bn0mivbG1yufrAKyuw6gY2MBy6pwjwPgW/tqG0BVZthLk GMjlfIpOMfZK1jviQpkkip5/xqV3nw+vJRGREtiL0PD4JdVDZPbFvRg3Wn6GHxf5Kioo cvMjYszzGH+fbvB2iGuI4Fnv2Zl8G9y1ub4GUSWNmz+Vj3ADmNuvvqz3x/OAJNTe9A4y BsGQ2eM1D2gyeAvI262dirWAY2+xJX0wXj4XIC1LTlIV1wqYhcZHEGz3gbCACT8njVmZ p1jQ==
X-Gm-Message-State: ALoCoQmtNZcswzEmMgqD5JVHQGR9gss3X988GrcRa/N1HuCj6ALyFkumxUrVKCRSQ1yPs08ywBzv
X-Received: by 10.68.164.4 with SMTP id ym4mr41172859pbb.53.1398119384237; Mon, 21 Apr 2014 15:29:44 -0700 (PDT)
Received: from [10.0.1.172] (96-41-205-84.dhcp.elbg.wa.charter.com. [96.41.205.84]) by mx.google.com with ESMTPSA id gj9sm80395735pbc.7.2014.04.21.15.29.42 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 15:29:43 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_6D0C837A-3AFC-46F6-B25D-DFD0EACD90C4"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Lance Stout <lance@andyet.net>
In-Reply-To: <60E5F9D6-0ED8-4801-838D-B669BEDA1DAE@andyet.net>
Date: Mon, 21 Apr 2014 15:29:40 -0700
Message-Id: <2A544C87-700F-416A-A81E-99D386741310@andyet.net>
References: <2C46C537-4E3F-4C29-BD2C-AFA1A5D52717@nostrum.com> <60E5F9D6-0ED8-4801-838D-B669BEDA1DAE@andyet.net>
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/HQ85TUcr6Y8W5T-KeogbljUdA74
Cc: Ben Campbell <ben@nostrum.com>
Subject: Re: [xmpp] Comments on draft-ietf-xmpp-websocket-05
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 22:29:51 -0000

I seem to have missed a section.


> -- 3.6:
> 
> Do we have to worry about half-closes situations where the peer does not respond in a timely manner? How about glare?

We're following the same procedure as in RFC 6120 Section 4.4 (with the substitution of <close /> instead of </stream:stream>)

Would referencing that section be sufficient to address this, or do I need to include that language in this document?


> How does the XEP-0198 guidance after the figure interact with the guidance saying the closing party SHOULD close the stream? That would seem to imply one SHOULD NOT keep the stream alive, since that would involve not closing the stream.

The closing party ought to do the polite thing and first end the XMPP stream and then the WebSocket connection. In which case, the stream is closed when the other party replies with a close, and the server considers the session ended. The use of XEP-0198 is irrelevant in this case, as the XMPP session is ended regardless.

However, if the WebSocket connection happens to close before the XMPP stream is closed (network loss, etc), then:

    XEP-0198 not enabled: consider the XMPP stream implicitly closed, and end the XMPP session.
    XEP-0198 enabled: keep the XMPP session alive for a configured period of time to allow resumption, as described in XEP-0198