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

[thomas kirk <[e-mail]>]

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.


 > On Thu, Aug 13, 2009 at 9:54 AM, Morgaine<[e-mail]> wrote:
 > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <[e-mail]>
 > > 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.
 > 
 > 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.
 > 
 > 
 > >
 > > 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:
 > >
 > > 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.
 > 
 > >
 > > 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.
 > 
 > so i respectfully disagree with your assertion that identifying a
 > standard transport for messages is not useful.
 > 
 > >
 > >
 > > Morgaine.
 > >
 > >
 > >
 > >
 > >
 > >
 > >
 > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <[e-mail]>
 > > 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
 > >
 > >
 > > _______________________________________________
 > > ogpx mailing list
 > > [e-mail]
 > > https://www.ietf.org/mailman/listinfo/ogpx
 > >
 > >
 > _______________________________________________
 > ogpx mailing list
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/ogpx