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

[David W Levine <[e-mail]>]

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


[e-mail] wrote on 08/18/2009 07:51:12 AM:

> thomas kirk <[e-mail]> 
> Sent by: [e-mail]
> 
> 08/18/2009 07:51 AM
> 
> Please respond to
> [e-mail]
> 
> To
> 
> Meadhbh Siobhan <[e-mail]>
> 
> cc
> 
> [e-mail]
> 
> Subject
> 
> Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer 
messages
> 
> 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 
fromthem.  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 toits 
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
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx