IETF Logo Mail Archive

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

Infinity Linden <infinity@lindenlab.com> Thu, 13 August 2009 14:42 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD133A6AAF for <ogpx@core3.amsl.com>; Thu, 13 Aug 2009 07:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.877
X-Spam-Level:
X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONKvXpCVIzeW for <ogpx@core3.amsl.com>; Thu, 13 Aug 2009 07:42:04 -0700 (PDT)
Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 558B63A68B8 for <ogpx@ietf.org>; Thu, 13 Aug 2009 07:42:04 -0700 (PDT)
Received: by fxm26 with SMTP id 26so622304fxm.42 for <ogpx@ietf.org>; Thu, 13 Aug 2009 07:41:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.145.3 with SMTP id b3mr360179fav.67.1250174492372; Thu, 13 Aug 2009 07:41:32 -0700 (PDT)
In-Reply-To: <4A841FD5.7020602@gmail.com>
References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> <4A841FD5.7020602@gmail.com>
Date: Thu, 13 Aug 2009 07:41:32 -0700
Message-ID: <3a880e2c0908130741lface1fck49bc7b2ec9214bf7@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: Mojito Sorbet <mojitotech@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ogpx@ietf.org
Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2009 14:42:05 -0000

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<mojitotech@gmail.com> wrote:
> Infinity Linden wrote:
>>
>> 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?)
>
> 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.
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>

v2.8.7 | Report a Bug | By Email