BWTP proposal talk

Destinations

I just added some example sessions as Appendix B, but the chat example made me think about the destinations. How does the destination given in the original HTTP GET request relate to the destinations used in BWTP messages once the session is upgraded. Are they totally independent namespaces? I assume the HTTP GET has to be able to live within the namespace of other non BWTP resources on the server, whereas the BWTP destinations do not.

- Martin

The URL of the original request is the default destination of inbound and default source of outbound messages.
If a message uses * for its URL, then the default is applied (this is to reduce the minimal byte count).
The default URL will also affect default origins and accepted origins etc.

-gregw

but it would be ok to change the url for the internal messaging? So the initial one is used as an entry point into the app, but then you can use the internal one as your messaging subjects if you had simple requirements? It seems like it would be down to implementations how they are used, but some conventions might be good

- Martin

Can you expand on this a little bit more? I'm not understanding???

-gregw

Sorry, not asking this very clearly. I'm just trying to understand exactly how the two urls are intended to be used. Maybe some more real world examples would help here.

- Martin

I don't see that there are two URLs. Every message has exactly 1 URL associated with it. It will either be the default URL for the connection (if * is used in the start line) or it will be the URL in the message start line. The difference between inbound and outbound is that the message association with the URL will be "to" or "from" the URL. Perhaps I say something like that in the document :)

The two I refer to are the original URL from the HTTP handshake, and then the BWTP URL on each message. The first is the default for the second as I understand it. The problem I have is that the first effectively shares its namespace with other non BWTP URLs the server is also handling, whereas the URL on the BWTP messages (after upgrade) are now somewhat detached from the overall URL namespace of the server and confined to the BWTP application. It sounds like something that could end up being implemented differently by different people.

Eg one session starting with URL of A then using URL B in a BWTP message, and another session starting with URL C, but also using URL B in a BWTP message. Are both URL B's referirng to the same thing? Or are they referring to A+B and C+B respectively. I think you are intending the first, ie everything is just messages to/from URLs and the handshake URL is just defining the default for the rest of that session, rather than an application entry point (which is how I saw it)

- Martin

Graceful Close

I'd like to enable a intermediary to trigger a graceful close of the connection. I don't think injecting a message with Connection:close is sufficient, as messages may have been sent by an endpoint before it receives the close.

Instead, I think the intermediary should inject a Connection: closing header, which will request all intermediaries to forward the same header and for the receiving endpoint to initiate an orderly close with a connection:close request.

Origins

This will be key. We need to discuss this