Hi Dan,
As the document shepherd for this spec and the author of RFC 6120, I
have one comment below.
On 7/8/14, 3:06 AM, Romascanu, Dan (Dan) wrote:
Hi Jari,
The authors actually responded - see
http://www.ietf.org/mail-archive/web/gen-art/current/msg10306.html.
They pushed back on my #1 - I am still not convinced by their argument (as the
protocol does change by adding a different mapping) but I would not block the
document for this purpose.
The proposed changes for the rest are fine.
Even at the time of RFC 3920 (precursor to RFC 6120), we had one other
binding, namely the HTTP binding long-polling binding ("BOSH") defined
at http://xmpp.org/extensions/xep-0124.html - this is why in RFC 3920 we
explicitly stated that the spec defined only the TCP binding:
###
4.2. Binding to TCP
Although there is no necessary coupling of an XML stream to a [TCP]
connection (e.g., two entities could connect to each other via
another mechanism such as polling over [HTTP]), this specification
defines a binding of XMPP to TCP only. In the context of
client-to-server communications, a server MUST allow a client to
share a single TCP connection for XML stanzas sent from client to
server and from server to client. In the context of server-to-server
communications, a server MUST use one TCP connection for XML stanzas
sent from the server to the peer and another TCP connection
(initiated by the peer) for stanzas from the peer to the server, for
a total of two TCP connections.
###
We repeated this qualification in RFC 6120:
###
3. TCP Binding
3.1. Scope
As XMPP is defined in this specification, an initiating entity
(client or server) MUST open a Transmission Control Protocol [TCP]
connection to the receiving entity (server) before it negotiates XML
streams with the receiving entity. The parties then maintain that
TCP connection for as long as the XML streams are in use. The rules
specified in the following sections apply to the TCP binding.
Informational Note: There is no necessary coupling of XML streams
to TCP, and other transports are possible. For example, two
entities could connect to each other by means of [HTTP] as
specified in [XEP-0124] and [XEP-0206]. However, this
specification defines only a binding of XMPP to TCP.
###
The WebSocket binding specified in this I-D is intended to eventually
replace BOSH for reasons explained in RFC 6202.
In my opinion, the point of layering via bindings is to not modify or
update one binding by defining another binding. Thus I continue to be of
the opinion that the WebSocket binding does not update RFC 6120.
Peter
Regards,
Dan
-----Original Message-----
From: Jari Arkko [mailto:[email protected]]
Sent: Tuesday, July 08, 2014 7:58 AM
To: Romascanu, Dan (Dan)
Cc: [email protected]; [email protected];
[email protected]
Subject: Re: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
Thanks for the review, Dan.
I would like to see some thoughts from the editors regarding the two points
that you raised.
Jari
On 02 Jul 2014, at 09:00, Romascanu, Dan (Dan) <[email protected]>
wrote:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-
ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/
Reviewer: Dan Romascanu
Review Date: 7/2/2014
IETF LC End Date: 7/4/2014
IESG Telechat date: 7/10/2014
Summary: ready with minor issues
Major issues:
None
Minor issues:
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
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.
Nits/editorial comments:
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:'
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
