Re: [xmpp] Fwd: Reviews of draft-ietf-xmpp-websocket-07

Dave Cridland <dave@cridland.net> Fri, 04 July 2014 18:51 UTC

Return-Path: <dave@cridland.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 C53481B2DC0 for <xmpp@ietfa.amsl.com>; Fri, 4 Jul 2014 11:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 TtRydPVf3NcX for <xmpp@ietfa.amsl.com>; Fri, 4 Jul 2014 11:51:36 -0700 (PDT)
Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C77D1B2D5E for <xmpp@ietf.org>; Fri, 4 Jul 2014 11:51:36 -0700 (PDT)
Received: by mail-oa0-f49.google.com with SMTP id i7so2105745oag.22 for <xmpp@ietf.org>; Fri, 04 Jul 2014 11:51:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uzY6Y6H56LxGIAlCLCGHUEXrx0FtT8mD/oI0W/aYJxw=; b=clTxC8E5EeFb4VTIvuFvZ+lN2RNhnuWXrk5J3LcLlVFKVlaCYo6kUWTCpJPo+L7/Bm HsRnxlkbkugCD8iDFD4VY8mvskE12PFVMgpRpKFObb+ahLekE0onGNRGOQOq9NAIYnzA wh0sQeRmy/9JHY606VHjBiz8v+/mgZSq27dEw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uzY6Y6H56LxGIAlCLCGHUEXrx0FtT8mD/oI0W/aYJxw=; b=ZW2t+TDHPuj24NsfJKGOSBAEgme4chbU09Vpw5g1YS/8ulVPqvFTM6+2AakQo6l9Z/ lUeusOim63/rA6bzCRmmXQgiWcwAKZfE1kipEFiDETWNt6DgBVNQWpsxT1EMDAJS0v0+ kbrk25CX/pXkVdtXBqh/92TTnTOXq2yTgyBtfDyFrOH3Vr7uTcwCSZ3ZRTSELkdae3JT HbNCdMvtV/uvPkawemUk2dXv+H7AcstKIl3Wv7WSnx+lPATfPlq205A5r2TFs3OaOxJI CCTWpnYcKkkt35uBL5EufUWrcY7i3kW+l6EHgzsat3Ub1jY4JGp6J6nrj+NnQ2NKFkQ5 gY5A==
X-Gm-Message-State: ALoCoQlzJDaAB+4kGGy9bPT3IileGuLJh9jiE5jk2ttPVEXyDQqDp39tJrAJKSPogBaUAE6vXRMX
MIME-Version: 1.0
X-Received: by 10.60.59.4 with SMTP id v4mr14194721oeq.63.1404499895495; Fri, 04 Jul 2014 11:51:35 -0700 (PDT)
Received: by 10.60.134.145 with HTTP; Fri, 4 Jul 2014 11:51:35 -0700 (PDT)
In-Reply-To: <53B6EC3C.2090806@cisco.com>
References: <46B2A4E0-236E-4B1C-8060-C8641E0CA012@andyet.net> <BB6B8882-538F-46BE-9C73-912563C0EB20@andyet.net> <53B6EC3C.2090806@cisco.com>
Date: Fri, 04 Jul 2014 19:51:35 +0100
Message-ID: <CAKHUCzypv7pBm_-Qv5aShb6YDU7_aJsUK1cizU0=z1bwPAatwQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Matt Miller <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary="089e0129458c5bc90904fd629d6f"
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/axz-quDqKWVmIvEM4nKis7e3B0o
Cc: XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] Fwd: Reviews of draft-ietf-xmpp-websocket-07
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: Fri, 04 Jul 2014 18:51:38 -0000

On 4 July 2014 19:02, Matt Miller <mamille2@cisco.com> wrote:

> On 7/3/14, 9:59 PM, Lance Stout wrote:
> > 1. A server SHOULD use <close see-other-uri="..." /> when ending a
> > session & pointing the client to a new endpoint. Was previously a
> > MAY, but IETF LC feedback pointed out that we don't have any other
> > defined way to do this.
> >
> > I don't feel too strongly on this point, so feedback welcome on if
> > this change is really needed.
> >
>
> I agree with this change.  Making the 'see-other-uri' behavior a
> SHOULD I think will lead to more interoperable software; people will
> be much more inclined to implement it.
>
>
I'm not entirely sure that 2119 language makes sense here for the server.

If a server wishes to tell a client to switch websocket endpoint, then this
is the way to do it. If it doesn't do it this way, then it can't tell the
client. There's no "SHOULD" or "MAY" or "MUST" about this, because there's
no alternative.

The interesting question is what clients are expected to do here - clients
MUST reconnnect to the other URI? clients MAY? clients SHOULD? There's no
description of the clients' behaviour here at all.

The other question that lurks around my head is the interaction with
XEP-0198 resumption here.

Dave.