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

[Morgaine <[e-mail]>]

On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <[e-mail]>wrote;wrote:

>
> 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?
>


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.







On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <[e-mail]>wrote;wrote:

> 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
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>