Subject: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages

From: Infinity Linden <[email-masked]>
Date: Wed, 12 Aug 2009 17:53:04 -0700

Hey people!

So... looping back around to some of the comments from the f2f BoF meeting...

Original work with OGP used HTTP(S) to carry application messages.
There's been enough talk about alternate transports that it feels very
bad to dismiss them without discussion. However, I'm wondering if
there's anyone out there planning on implementing OGP over XMPP?

The reason I ask is that a number of us who worked on the early
pre-IETF interop trials are heavily invested in HTTP(S). Though i
can't speak for everyone involved, i would anticipate resistance to
mandating a new transport. HTTP(S) has it's weaknesses as a transport,
to be sure, but it's a well deployed and well understood protocol with
a mature tool chain. This makes it attractive to many people.

On the other hand, if someone else thinks they want to produce an OGP
implementation over XMPP, that seems really cool. But if no one's
going to implement it, an argument could be made that putting the
effort into specifying it would be a waste of time. On yet another
hand, going through the exercise of figuring out what aspects of HTTP
are required to transport OGP messages might reveal subtle
dependencies between components. Back on the other hand again, can we
do this without re-writing BCP56?

So I was thinking of this as a proposal:

If there is strong interest in implementing OGP over XMPP, let's
mention that it's an "officially supported" transport in the charter.
(for some definition of the words "officially supported.")

If there's not strong interest in implementing OGP over XMPP, let's
not put it in the charter.

In either case, I think there's sufficient justification for
describing the set of requirements OGP makes on it's transport. For
instance, does it REQUIRE request/response semantics? (i.e. - if i'm
writing a compliant server layering OGP over XMPP, and i receive an
OGP "request" in an XML stanza, am i REQUIRED to send a response?)
Or... does it REQUIRE specific content negotiation semantics? (i.e. -
do we need to explicitly describe or reference a technique for
identifying the content type of a response in XMPP?) Or... does the
protocol explicitly depend on caching behavior of some HTTP proxies?
if so, how? etc. etc.

-sincerely
-meadhbh

---

From: Mojito Sorbet <[email-masked]>
Date: Thu, 13 Aug 2009 10:14:45 -0400

Infinity Linden wrote:
> For

Well, if you are "requesting" something, that should "require" a 
response.  For example, the <iq/> stanza in XMPP does this. for both 
"get" and "set" operations.  The need for a response does not block the 
channel from carrying other stanzas in the meantime, which I think is an 
advantage over HTTP.

But if you are just reporting an event, as in a <presense/> or 
<message/> stanza, I do not see the need for any reply at all.   The 
whole reason for using something over TCP is so that we do not have to 
worry "did it get there?"

I am not suggesting that <presence/>, <iq/>, or <message/> stanzas as-is 
are appropriate for OGP.  I only mention them as examples of how an XMPP 
stream can carry both types.

XMPP today does some form of negotiation at session startup, mostly for 
determining login credentials and encryption level, so there is some 
precedent for that.

---

From: Infinity Linden <[email-masked]>
Date: Thu, 13 Aug 2009 07:41:32 -0700

right. i think this is the kind of stuff we need to explicitly call
out to provide guidance for implementers. i.e. - that clients can't
require the next message from an XMPP peer to be the response to the
previous  request.

for content negotiation, i was thinking more for the external
references and responses where the type is something other than an XML
stanza or an XML stanza that encapsulates something other than XML.
(like maybe you were sending LSL over the wire. in HTTP, you could tag
it with a Content-Type:. in XMPP, you could define a message format
that included the content type as an XML element.)

-cheers
-meadhbh

On Thu, Aug 13, 2009 at 7:14 AM, Mojito Sorbet<[email-masked]> wrote:
> Well, if you are "requesting" something, that should "require" a response.
>  For example, the <iq/> stanza in XMPP does this. for both "get" and "set"
> operations.  The need for a response does not block the channel from
> carrying other stanzas in the meantime, which I think is an advantage over
> HTTP.
>
> But if you are just reporting an event, as in a <presense/> or <message/>
> stanza, I do not see the need for any reply at all.   The whole reason for
> using something over TCP is so that we do not have to worry "did it get
> there?"
>
> I am not suggesting that <presence/>, <iq/>, or <message/> stanzas as-is are
> appropriate for OGP.  I only mention them as examples of how an XMPP stream
> can carry both types.
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Morgaine <[email-masked]>
Date: Thu, 13 Aug 2009 17:54:42 +0100

> there's anyone out there planning on implementing OGP over XMPP?

Asking the question in this form creates a bit of a false dichotomy.
HTTP(S) and XMPP cover different areas of the solution space, so they are
not simple alternatives.  It's better to first disentangle the requirements,
and then see what is applicable to each part.

OGP networking requirements (as far as we know them) comprise at least three
different types of functionality, although the 3rd is a matter of some
debate:

   1. HTTP(S) client-server request/response calls to OGP services.
   2. Server-client streaming object updates, over an unspecified reliable
   transport.
   3. HTTP(S) server-client request/response calls to client-side services.

Type 1 is wonderfully served by HTTP(S), while XMPP leaves a lot to be
desired in this role, for which it was not designed.

Type 2 is not served naturally by HTTP(S) at all, but because this
requirement is so common in many types of applications, the "web everywhere"
fraternity has tried to shoehorn this type into HTTP as well, using a
variety of proposed strategies ranging from COMET's Long Poll and Streamed
Response through to the latest WebSockets, with debateable success.  XMPP
was designed to serve this type of networking functionality, although its
targetted application area is somewhat different to that of VWs.  Whether it
would be able to carry object updates with sufficient efficiency would
require analysis and testing.

Type 3 is poorly specified at present, and it may turn out to be a
non-existent requirement stemming only from a misguided attempt to poll
clients instead of receiving streamed asynchronous updates from them.  On
the other hand it may turn out to be an essential networking facility for
providing symmetry between clients and servers, for instance when decoupled
OGP services run on the client --- this will need much more discussion.
Assuming for now that there is indeed such a requirement, HTTP may serve it
adequately when run over Reverse HTTP, whereas XMPP would leave a lot to be
desired in this role for which it was not designed.

The above is confusing and fragmented enough, but it gets worse.

There is yet another networking type common to VWs which has not even been
mentioned in our two years of AWG and the 6 months of MMOX deliberations,
yet is an essential type with its own properties:   streaming of input
events and objects from client to server.  This is (roughly) lumped in with
Type 2 in current SL and Opensim  implementations, and it appears to be
destined to be lumped in with Type 1 in OGP, where it fits poorly for
reasons of latency on realtime inputs.  Neither HTTP(S) nor XMPP seem ideal
for this, although XMPP has a much closer semantic fit owing to its Jabber
heritage.

So where does this leave us?  Well the first thing that should be clear is
that we are not facing a simple question of  "Should we do it all over HTTP
alone, or also allow for implementation over XMPP?".  The design
requirements aren't like that at all.  In particular, HTTP(S) just doesn't
fit the Type 2 semantic requirement, and XMPP may not either.

Given that our current task is only to define the charter and not to
constrain the solutions, I think that any form of wording that suggests that
HTTP(S) alone is sufficient should be avoided, because it is not sufficient
for Type 2 based on our existing experience in virtual worlds.  To put it
bluntly, it's too slow, and the polling model has inadequate latency
properties.

I suggest therefore that this question of "HTTP(S) and/or XMPP" not be
addressed in the charter, because the requirements have not yet been
examined in sufficient detail to be able to make that call.  Indeed, Type 2
may require a different protocol altogether.

Morgaine.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 17 Aug 2009 09:44:38 -0700

> and then see what is applicable to each part.

mmm.. i hate to say it morgaine, but i disagree. both HTTP(S) and XMPP
can be used to carry application state changes.

but i do agree we need to be clear about the messaging requirements.

> HTTP(S) client-server request/response calls to OGP services.
> Server-client streaming object updates, over an unspecified reliable
> transport.
> HTTP(S) server-client request/response calls to client-side services.

this list presupposes HTTP(S). i would list them as being a little more general:

1. the client makes a non-real-time request of the server.
2. the server makes a non-real-time request of another server.
3. the client makes a real-time request of the server.
4. the server sends a real-time update to the client.
5. the server makes a non-real-time request of the client.

* all messages SHOULD have the ability to carry meta-data important to
the carrying protocol.
* all messages SHOULD have clear semantics for describing endpoints of messages

an example of 1 would be fetching a texture from an asset server.
there is a proud history of using HTTP to fetch images, which is why i
think there's consensus behind using it for this purpose.

an example of 2 would be an agent host making a request of a
simulator. like the first example, this is a request-response pattern.

an example of 3 would be the user presses the 'up' arrow on the
keyboard and expects a change in the avatar's shared state (like it
moves forward.) i would call this a "weak" request response, meaning,
it would be nice if after you pressed the up arrow and the client sent
the "hey, my user just pressed the up arrow" message to the server, if
you would get a response. but... if you wind up not getting a response
for each request, it's not the end of the world. maybe responses could
be acknowledged in a batch response, or the response could be
eliminated all together if the semantics of the message do not REQUIRE
reliable delivery.

an example of 4 would be the simulator sending object update messages
to the client. these messages MAY have real-time semantics, meaning if
a message is late, it's useless (think VoIP.) so imagine a world,
where the simulator sends each client messages like "object <foo> is
now at location <bar>" or ".. is now rotated <thusly>." if we applied
real-time semantics to these messages, the client would likely be
constructed to update the position (or other physical characteristics)
of an object at a low frame rate, and the experience would be that
those objects would potentially look jerky. if we didn't apply
real-time semantics, the client could have some messages delayed, then
applied rapidly; like maybe five seconds worth of avatar movement is
compressed into two seconds. these are two extremes, and there are
probably a great number of tricks the client could pull to make the
experience look a little nicer.

i think this is where RTP and XMPP would shine. RTP if we want
real-time semantics, XMPP if we don't. ultimately, however, given the
event queue and long poll techniques, non-real-time messaging from the
server to the client COULD be implemented with HTTP.

an example of 5 is a server needs to access a sensitive resource
maintained by the client. (reference previous discussions about client
side capabilities.) this is another place where XMPP would likely be
more efficient than HTTP(S), but again, we have an event queue, long
poll and someday might have a standard for bi-directional HTTP.

ultimately, i think the thinking here is that it's easier to think of
OGP as an application protocol that CAN go over multiple protocols,
then define how it goes over each protocol, then allow the deployer to
choose which protocol it wants to layer OGP messages over modulo some
fixed number of well defined interoperability profiles.

i think that REQUIRING some messages to go over HTTP (and only over
HTTP) while REQUIRING other messages to go over RTP (and only over
RTP) and yet a third class of messages to go over XMPP (and only over
XMPP) is a recipe for disaster in a protocol. such a beast would be
extremely difficult to implement as it would require implementers and
deployers to integrate multiple transports. in practice, this might
mean integrating apache with ejabberd and with a custom RTP
application. it's not impossible to do, but it would DEFINITELY be
more difficult.

> may require a different protocol altogether.

so i respectfully disagree with your assertion that identifying a
standard transport for messages is not useful.

---

From: thomas kirk <[email-masked]>
Date: Tue, 18 Aug 2009 07:51:12 -0400

in favor of leaving open the possibility of alternative transports, so
even if HTTP(S) is the preferred mapping, it would be worthwhile to 
define a core OGP protocol that's independent of a concrete transport, 
and specify the HTTP(S) mapping separately, in the manner that 
BEEP (for example) makes this distinction (rfc3080, 3081).

The core protocol can express requirements and assumptions about 
the transport abstractly; separating its specification leaves 
open the possibility of future mappings, and makes explicit 
(and probably simplifies) the ways that OGP depends on underlying 
service. Given the historical bias, seems reasonable to propose 
at least an HTTP mapping, but without precluding others.

---

From: David W Levine <[email-masked]>
Date: Tue, 18 Aug 2009 10:05:31 -0400

That matches my thinking. We want to be saying  "Here is a formatted 
request./response sequence" "Here is how you move it on http(s)" and 
expect that, down the road someone may say "Here is how you move it on 
xmpp" We need a parallel 
construct to map "update stream" like messages. We don't want to tie 
permanently to a single transport,  but, we need to show it on specific 
ones, and http(s) gets first dibs on that. 

- David
~ Zha

[email-masked] wrote on 08/18/2009 07:51:12 AM:

> thomas kirk <[email-masked]> 
> Sent by: [email-masked]
> 
> 08/18/2009 07:51 AM
> 
> Please respond to
> [email-masked]
> 
> To
> 
> Meadhbh Siobhan <[email-masked]>
> 
> cc
> 
> [email-masked]
> 
> Subject
> 
> Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer 
messages
>  > On Thu, Aug 13, 2009 at 9:54 AM, 
> Morgaine<[email-masked]> wrote:
>  > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden 
<[email-masked]>
>  > > wrote:
>  > > clients instead of receiving streamed asynchronous updates 
fromthem.  On
>  > > for this, although XMPP has a much closer semantic fit owing toits 
Jabber
>  > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden 
<[email-masked]>
>  > > wrote:

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Aug 2009 17:52:29 +0100

>BEEP (for example) makes this distinction (rfc3080, 3081).
As well as EPP and several others.

>at least an HTTP mapping, but without precluding others.
I agree that this is a good idea.