> 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, http://etherx.jabber.org/streams";> is replaced by . But importantly, each framed
stanza MUST include its own correct namespace, which is still jabber:client for
C2S stanzas. A very abbreviated example:
C:
…
C: …
So, for S2S we’re already good in terms of namespacing to send jabber:server
namespaced stanzas:
S1:
…
S1: …
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: …
In particular, noting that a dialback element would need the xmlns:db defined
on the element because there is no wrapping element to inherit it from.
It would also be acceptable to include a xmlns:db declaration on the
element to match what is done for , even though it does nothing on its
own.
S: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
