Subject: [hybi] BWTP progress

From: Greg Wilkins <[email-masked]>
Date: Wed, 15 Jul 2009 13:27:17 +1000

All,

The BWTP proposal continues to be worked on and is getting
some more content that would be good to be reviewed:

The Connection: closing   header to allow an intermediary
to initiate an orderly close of a BWTP connection.

Origin and Access-Control-Allow-Origin headers to control
who can see messages.

Content-Encoding and Transfer-Encoding. Do we need both?
They make sense in a request situation where the transfer-encoding
is not the encoding of the requested resource???

Content Range/Language/Location definitions

More examples in Appendix

review/ideas/critique welcome!

cheers

---

From: Joshua Bell <[email-masked]>
Date: Wed, 15 Jul 2009 17:48:07 -0700

One thing that I didn't see when I looked at (an earlier draft of) BWTP 
that I'd like included is a recommendation for how to layer 
request/response semantics over it. This would be achievable right now 
per the draft with custom headers (e.g. X-Method: GET, X-Request-Id: 
1234 .... X-Response-Id: 1234, X-Status: 200 OK) but it seems like a 
common enough case that codifying it might make sense.

One scenario we're looking at over in OGPX is where HTTP serves very 
well - both as a transport and REST semantics - for client access to 
server resources. We also have the reverse scenario where the "server" 
would make use of "client" resources, and again the HTTP semantics work 
well; this is currently achieved in practice (and drafted) as long poll 
connections over HTTP.

http://tools.ietf.org/html/draft-lentczner-rhttp-00 has been written, 
describing RHTTP which addresses this specific case in a straightforward 
manner. If BWTP were to formalize the semantics for bi-directional 
resource utilization with REST semantics over the protocol, that'd be 
swell, and it would be straightforward for OGPX protocols to operate 
over BWTP.

Greg Wilkins wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 20 Jul 2009 14:36:30 +1000

All,

In response to Joshua's suggestion I've updated the BWTP proposal with an
appendix that briefly describes how HTTP can be transported over BWTP.

As well as that, I have added a definition where URI fragments can be used
to identify virtual connections within a BWTP connection, so

  BWTP /foo#1 12

  Hello World

Represents a "Hello World" message sent to/from /foo on virtual connection
#1.   This allows very simple multiplexing of messages over a single
connection.

Note that combined with the HTTP over BWTP, this provides a powerful
extra capability, as requests/responses only need to be well ordered
within the same virtual connections.   So if HTTP requests are sent
over different virtual connections, then their responses can come
back in an arbitrary order.

I have also added a short appendix showing how the WebSocket API
can be mapped to BWTP connections.      If multiple WebSockets are
opened to the same host, then the virtual connection mechanism may be
used to transparently multiplex the websockets over a single TCP/IP
connection.

The specification for these is all very skeletal. I'd appreciate
feedback and/or questions to help me flesh out the full detail.

cheers

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Jul 2009 07:31:06 +0200

Greg Wilkins wrote:
> ...
> ...

That seems to be an abuse of fragment identifiers; see: 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5>:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications."

BR, Julian

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 21 Jul 2009 09:28:55 +1000

Julian,

I would argue that within the scope of a BTWP message stream, we are
not in the scope of a "retrieval action on the primary resource",
so there for the "unknown and are effectively unconstrained" part
would apply to fragments.

Note also that I picked the fragment because it is excluded from
the abs_path or absoluteURI elements that can be sent as the
message address.  ie even in HTTP fragments are not part of
the sent URI.

But then, the virtual concept does not need the ID to be a fragment.
We could equally define an optional forth field on the start line:

  BWTP /foo 12 1

  Hello World

or include the connection ID as a header.

  BWTP /foo 12
  Connection-Id: 1

  Hello World

As the websocket guys appear to be sensitive to byte count, I was
looking for a way to pass the connection ID with minimal extra bytes,
hence I avoided the header.

So if there still is concern about using fragments in this way,
I'll change to use an optional forth start-line field.

cheers