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

Matt Miller <mamille2@cisco.com> Fri, 04 July 2014 18:02 UTC

Return-Path: <mamille2@cisco.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 E53141B2B47 for <xmpp@ietfa.amsl.com>; Fri, 4 Jul 2014 11:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 VpKrThxwFgdp for <xmpp@ietfa.amsl.com>; Fri, 4 Jul 2014 11:02:38 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D514C1B2B35 for <xmpp@ietf.org>; Fri, 4 Jul 2014 11:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5408; q=dns/txt; s=iport; t=1404496958; x=1405706558; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=tY6gOWstEUQ+cwq0Dy7ep150OW5iy15NFx8vpHpfVYg=; b=dc4tOnEWZyDoLOLAuKfgJ0HJI3PUu9TNUVfKj7PxT0KiK/H5wsQu/p6D wzkWlkPDwytD43M29HYSyVYJe2J8d+cw/6DUygPh7e1lRgw9wg0Zj+iDX MVS7ItVfKnmqmoRz3vve+IOEREkTn72t4g5Wc3fxmuHyJe728USdSYXb6 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcMAPvqtlOtJV2P/2dsb2JhbABagw5SWqtJAQEBAQEBBQFuAZIohzUKAYELFnWEAwEBAQMBAQEBawoRCxAICRYPCQMCAQIBDwYwBgEMBgIBAYgqAwkIDcNxDYZSF4VwhwqBdTqEQwWKFzqMC4IaggCHD4ZphhSDYoIR
X-IronPort-AV: E=Sophos;i="5.01,602,1400025600"; d="scan'208";a="337831064"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jul 2014 18:02:37 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s64I2at0019688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 18:02:36 GMT
Received: from [10.89.9.202] (10.89.9.202) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Jul 2014 13:02:36 -0500
Message-ID: <53B6EC3C.2090806@cisco.com>
Date: Fri, 4 Jul 2014 12:02:36 -0600
From: Matt Miller <mamille2@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Lance Stout <lance@andyet.net>, XMPP Working Group <xmpp@ietf.org>
References: <46B2A4E0-236E-4B1C-8060-C8641E0CA012@andyet.net> <BB6B8882-538F-46BE-9C73-912563C0EB20@andyet.net>
In-Reply-To: <BB6B8882-538F-46BE-9C73-912563C0EB20@andyet.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.89.9.202]
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/uq59w670XyQQikRzjK4fVI28RkY
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:02:47 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 7/3/14, 9:59 PM, Lance Stout wrote:
> Closing in on the end of IETF LC for draft-ietf-xmpp-websocket-07,
> so replying to the feedback generated so far. We'll publish a -08
> draft addressing these issues, which have all been minor or
> editorial points.
> 
> 
> For the XMPP WG: Two proposed changes in normative requirements:
> 
> 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.

> 
> 2. If the server responds to the WebSocket handshake without
> including 'xmpp' in its Sec-WebSocket-Protocol header, then the
> client MUST close the connection.
> 
> Handling of this situation was previously undefined, but this feels
> to be what we all expected was already the proper client action.
> 

This makes sense to me.


- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

> 
> On Jul 3, 2014, at 9:39 AM, <magnusn@gmail.com> <magnusn@gmail.com>
> wrote:
> 
>> Should ?when TLS is used, it MUST be enabled the WebSocket layer
>> ? have read ?when TLS is used, it MUST be enabled at the
>> WebSocket layer ? ?
> 
> 
> Yes, that is the intended wording.
> 
> 
> 
> 
> On Jul 2, 2014, at 6:00 AM, Romascanu, Dan (Dan)
> <dromasca@avaya.com> wrote:
> 
>> 1. In order to accommodate the Websocket binding this document
>> describes several deviations from RFC6120. For example, in
>> Section 3.3 it says: The WebSocket XMPP sub-protocol deviates
>> from the standard method of constructing and using XML streams as
>> defined in [RFC6120] by adopting the message framing provided by 
>> WebSocket to delineate the stream open and close headers,
>> stanzas, and other top-level stream elements. I am wondering
>> whether it would not be appropriate to reflect this in the
>> document header by adding Updates RFC6120
> 
> 
> This is a separate binding from the TCP binding defined in RFC6120,
> so I don't think saying Updates RFC6120 would be accurate. Nothing
> in RFC6120 is modified by this document.
> 
> 
>> 2. In Section 3.6.1:
>> 
>> If the server wishes at any point to instruct the client to move
>> to a different WebSocket endpoint (e.g. for load balancing
>> purposes), the server MAY send a <close/> element and set the
>> "see-other-uri" attribute to the URI of the new connection
>> endpoint (which MAY be for a different transport method, such as
>> BOSH (see [XEP-0124] and [XEP-0206]).
>> 
>> I do not understand the usage of MAY in this paragraph. Is there
>> another method to move to a different Web socket endpoint that is
>> described here or some other place? In not, why is not the first
>> MAY at least a SHOULD? The second usage seems to describe a state
>> of facts, so it needs not be capitalized at all.
> 
> That is the only method, so I agree that can be a SHOULD, and also
> agree on the second point.
> 
> 
>> In Section 3.1 I believe that the example should be preceded by
>> some text that indicates that this is an example, such as: ?An
>> example of a successful handshake and start of session follows:?
> 
> +1, will add that.
> 
> 
> 
> 
> 
> On Jun 25, 2014, at 11:55 PM, Juergen Schoenwaelder 
> <j.schoenwaelder@jacobs-university.de> wrote:
> 
>> - Sec 1: The term 'raw socket' can be potentially mis-understood,
>> perhaps simply remove 'over row sockets' completely (I think the
>> message of the sentence remains intact without these words).
> 
> +1 will change
> 
>> - Sec 3.1: The text says that both client and server MUST have
>> |xmpp| in the list of protocols for the |Sec-WebSocket-Protocol|
>> header. The text does not detail what happens if this is not the
>> case. Is there be a defined behavior if this protocol negotiation
>> fails?
> 
> Good catch, RFC6455 doesn't describe what to do in that case, so
> we'll need to address it.
> 
> If the server does not reply with 'xmpp' in the
> Sec-WebSocket-Protocol handshake reply, then the client MUST close
> the connection.
> 
> 
>> - Sec 3.6.1: There is a closing parenthesis missing at the end of
>> the first paragraph.
> 
> Noted, will fix.
> 
> 
> 
> 
> - Lance
> 
> 
> 
> 
> 
> _______________________________________________ xmpp mailing list 
> xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTtuw8AAoJEDWi+S0W7cO10WoH/jHlU66Y5B5AVfJzza/ey8jb
LFcYqb4hDYQm5civ+yZ3MGwRoaHDl1QreQYpF1eh4xEbo0T2heAxXReUKbIh2xvs
Wl7vXedVz0YLPS/s1i45XoMStFBU7LZ00Y9Vm5+FUHMppvjWVYrdimUNa9KKGXCo
wTRDY/it1uxlkVWgtecMh6bMSR722UTQWu71pcdvhsWIk40gU6vNdh56FU/ew2FM
WmRtrTHJYHqPoFvE86GAgSKNF8S42Dz/5DbPAsrZUp9iUbo0ocgLrsqA9VIqLqkm
/MOQy19Cce5Y0Q2G5tC8+DhAXORM6Fi1+NgXWSvgMHyOadNGLbRywT7GN49X6xo=
=p4NY
-----END PGP SIGNATURE-----