> Everything mentioned in RFC 7395 [1] should be followed with the following > changes:
Chiming in as an author of RFC 7395 :) > For c2s, RFC 7395 [1] requires replacing the 'jabber:client' namespace with > 'urn:ietf:params:xml:ns:xmpp-framing', for s2s, the 'jabber:server' namespace > should be replaced with 'urn:ietf:params:xml:ns:xmpp-framing-server’. First, I need to point out that is not quite what 7395 requires. The framing mechanism defined in 7395 was intended to be generically reusable and not directly tied to C2S, or even WebSocket (WebRTC data channels were particularly in mind). Yes, in a C2S stream, <stream:stream xmlns=“jabber:client” xmlns:stream=“http://etherx.jabber.org/streams";> is replaced by <open xmlns=“urn:ietf:params:xml:ns:xmpp-framing” />. But importantly, each framed stanza MUST include its own correct namespace, which is still jabber:client for C2S stanzas. A very abbreviated example: C: <open xmlns=“urn:ietf:params:xml:ns:xmpp-framing” /> … C: <message xmlns=“jabber:client”>…</message> So, for S2S we’re already good in terms of namespacing to send jabber:server namespaced stanzas: S1: <open xmlns=“urn:ietf:params:xml:ns:xmpp-framing” /> … S1: <message xmlns=“jabber:server”>…</message> However, we still would want to distinguish between opening up a C2S or S2S WebSocket connection to know how to respond. The fact that a 7395 WebSocket connection is interpreted as a C2S connection is entirely because it sets the WebSocket Subprotocol header to “xmpp”. I suggest that we define a Subprotocol of “xmpp-server” to signal S2S connections instead of creating a new, otherwise duplicate, namespace. Defining a new WebSocket Subprotocol entry with IANA probably would be best done in an Internet-Draft/RFC, but we’ve migrated things from XEPs to RFCs before. > Connection details are discovered by using Discovering Alternative XMPP > Connection Methods (XEP-0156) [2] This is what 7395 says to follow already. Although, XEP-0156 might be where we _would_ want to define a server namespace (urn:xmpp:server-alt-connections:* maybe?) for S2S vs C2S discovery. There are two other matters to consider for S2S: connection directionality and dialback. For connection directionality, traditional S2S connections are one-way, requiring a pair or more of connections for back-and-forth communication. As someone that’s worked with XMPP for a while, _I_ would not be surprised if server developers used existing logic and sent data one-way on a WebSocket connection, unless the bidi stream feature from XEP-0288: Bidirectional Server-to-Server Connections was negotiated. But that might need to be called out explicitly in this XEP/I-D because people will otherwise probably consider a WebSocket connection to always be bidirectional as a matter of course. For XEP-0220 Dialback, nothing particularly special needs to be done to accommodate it, but it would be helpful to include an example of what it would look like due to the framed stream namespacing rules. Something like: S: <db:verify xmlns:db=“jabber:server:dialback”>…</db:verify> In particular, noting that a dialback element would need the xmlns:db defined on the element because there is no wrapping <stream> element to inherit it from. It would also be acceptable to include a xmlns:db declaration on the <open /> element to match what is done for <stream>, even though it does nothing on its own. S: <open xmlns=“urn:ietf:params:xml:ns:xmpp-framing” xmlns:db="jabber:server:dialback” /> I would hope that a server using WebSocket S2S would be able to use <stream:feature /> detection for dialback, but the fallback is available. :) RFC 7395 3.4 mandates that clients MUST NOT multiplex streams over the same WebSocket, which at first sounds in conflict with dialback allowing multiplexing. But that prohibits sending multiple <open /> elements, whereas multiplexed dialback would still only use the one <open />, so would be ok. Looking forward to see how this turns out, and happy to help with making an RFC to supersede 7395 :) /Lance _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
