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

-----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 < [email protected] >
Cisco Systems, Inc.

> 
> On Jul 3, 2014, at 9:39 AM, <[email protected]> <[email protected]>
> 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)
> <[email protected]> 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 
> <[email protected]> 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 
> [email protected] 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-----