Subject: [xmpp] WebSocket: see-other-uri

From: Lance Stout <[email-masked]>
Date: Tue, 22 Oct 2013 20:43:55 -0700

Aside from the discussion on start/close signaling of the streams, the last big todo for XMPP over WebSocket is to define a way for a server to redirect a client to a different endpoint, similarly to the existing see-other-host error condition.

BOSH defines its own set of error conditions as part of its body wrapping element, which includes see-other-uri.

Possible solution 1:

Define a see-other-uri stream error condition, in the vein of existing stream error conditions.

Pro: integrates with existing patterns, could be used to bounce a session across different transport types.

Con: This might better belong in 6120bis. This could have issues with proxy connection managers making the source of the uri change ambiguous (ie, if it's the proxy that initiates the uri change versus the server proper.)

Possible solution 2:

If we adopt new start/end signals, we could add conditions to the ending signal in the vein of the BOSH terminate action.

Pro: Would allow the inclusion of several other condition types as used in BOSH, particularly for connection managers. Allows for disambiguating errors from a proxy connection manager and a server.

Con: Introduces new location for this type of information.

Interactions with XEP-0198 stream management: 198 includes a location slot for a host and port where a client should connect to resume a session. Reading the archives, I see that this was not defined to be a uri because at the time only BOSH would have used it and so was considered unneeded. Given the usefulness of 198 over WebSocket, it would be worth revisiting that point.

--Lance

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Oct 2013 11:06:15 -0600

On 10/22/13 9:43 PM, Lance Stout wrote:
> Aside from the discussion on start/close signaling of the streams,
> the last big todo for XMPP over WebSocket is to define a way for a
> server to redirect a client to a different endpoint, similarly to the
> existing see-other-host error condition.
> 
> BOSH defines its own set of error conditions as part of its body
> wrapping element, which includes see-other-uri.
> 
> Possible solution 1:
> 
> Pro: integrates with existing patterns, could be used to bounce a
> session across different transport types.
> 
> Con: This might better belong in 6120bis. This could have issues with
> proxy connection managers making the source of the uri change
> ambiguous (ie, if it's the proxy that initiates the uri change versus
> the server proper.)
> 
> Possible solution 2:
> 
> If we adopt new start/end signals, we could add conditions to the
> ending signal in the vein of the BOSH terminate action.
> 
> Pro: Would allow the inclusion of several other condition types as
> used in BOSH, particularly for connection managers. Allows for
> disambiguating errors from a proxy connection manager and a server.
> 

Possible solution 3:

Use <undefined-condition/> from RFC 6120 and include an application
specific error condition. We could even directly import the existing
BOSH errors:

   <stream:error>
     <undefined-condition
         xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
     <body condition='see-other-uri'
           xmlns='http://jabber.org/protocol/httpbind'/>
   </stream:error>

Pro: Enables us to re-use all of the BOSH conditions if needed.

Con: Using BOSH error conditions for WebSocket seems like a hack.

> Interactions with XEP-0198 stream management: 198 includes a location
> slot for a host and port where a client should connect to resume a
> session. Reading the archives, I see that this was not defined to be
> a uri because at the time only BOSH would have used it and so was
> considered unneeded. Given the usefulness of 198 over WebSocket, it
> would be worth revisiting that point.

That's a possible change to XEP-0198, right?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/