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

Ben Campbell <ben@nostrum.com> Tue, 22 April 2014 20:58 UTC

Return-Path: <ben@nostrum.com>
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 7DA261A0289 for <xmpp@ietfa.amsl.com>; Tue, 22 Apr 2014 13:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 ezvidpUqtRTL for <xmpp@ietfa.amsl.com>; Tue, 22 Apr 2014 13:58:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6A1A026B for <xmpp@ietf.org>; Tue, 22 Apr 2014 13:57:44 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3MKvZiF019834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Apr 2014 15:57:36 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <2A544C87-700F-416A-A81E-99D386741310@andyet.net>
Date: Tue, 22 Apr 2014 15:57:35 -0500
X-Mao-Original-Outgoing-Id: 419893055.212313-5f0c326ce785ff07b2b56332226a6b60
Content-Transfer-Encoding: quoted-printable
Message-Id: <9CDE7F63-ABA2-41C6-89A3-F399F2CE9D3D@nostrum.com>
References: <2C46C537-4E3F-4C29-BD2C-AFA1A5D52717@nostrum.com> <60E5F9D6-0ED8-4801-838D-B669BEDA1DAE@andyet.net> <2A544C87-700F-416A-A81E-99D386741310@andyet.net>
To: Lance Stout <lance@andyet.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/hfTBwnOeULsGt3IGlIjNlEJXalQ
Cc: XMPP Working Group <xmpp@ietf.org>
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: Tue, 22 Apr 2014 20:58:08 -0000

On Apr 21, 2014, at 5:29 PM, Lance Stout <lance@andyet.net> wrote:

> 
> 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?

That gets down into esoterica about whether you would expect an update to that section of 6120 to impact this draft. But in general I'm okay with either approach as long as it is clear, and we don't end up with dueling 2119 language between here and 6120.

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

Okay, so the use of XEP-0198 does not absolve you from closing the stream. That seems to be the way the text currently rendered, but some notes to that effect might make it easier to understand. OTOH, do I infer correctly that failure to close the stream does no harm under any circumstances? If true, do we really need that SHOULD, rather than just something to the effect of your "... ought to do the polite thing..." comment?

> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp