Return-Path: 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 4ADBF28C10D; Mon, 1 Mar 2010 12:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 0BIiANTSDEVc; Mon, 1 Mar 2010 12:41:51 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id BADDB3A896D; Mon, 1 Mar 2010 12:41:45 -0800 (PST) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o21Kbft3011256; Mon, 1 Mar 2010 15:37:41 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o21Kfi8F1986786; Mon, 1 Mar 2010 15:41:44 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o21KfikU009749; Mon, 1 Mar 2010 17:41:44 -0300 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o21KfiSB009743; Mon, 1 Mar 2010 17:41:44 -0300 In-Reply-To: References: To: Joshua Bell MIME-Version: 1.0 X-KeepSent: 11F0A127:BB9F4EC4-852576D9:0070D289; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Mon, 1 Mar 2010 15:41:38 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 03/01/2010 15:41:43, Serialize complete at 03/01/2010 15:41:43 Content-Type: multipart/alternative; boundary="=_alternative 0071ACE9852576D9_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Draft work on Foundation and Type System X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 20:41:52 -0000 This is a multipart message in MIME format. --=_alternative 0071ACE9852576D9_= Content-Type: text/plain; charset="US-ASCII" ogpx-bounces@ietf.org wrote on 03/01/2010 03:10:25 PM: > [image removed] > > Re: [ogpx] Draft work on Foundation and Type System > > Joshua Bell > > to: > > ogpx > > 03/01/2010 03:10 PM > > Sent by: > > ogpx-bounces@ietf.org > > On Mon, Mar 1, 2010 at 11:56 AM, David W Levine wrote: > > > ... and the (independent?) axis of "does this need to be > > standardized at the VWRAP level at all?" > > > The answer to the later, is yes if you ask me. If we can't describe > how the regions speak to the rest of the world, we're not actually > going to have interop, we're either going to have insanely painful hand-off > between clients, or an informal, non specified set of rules everyone has to > follow. > > Oops - what I wrote was unclear. > > To avoid confusion, let me clarify: by "does this need to be > standardized?", I meant the following three closely linked ideas: > Does this individual message/set of related messages even make sense > in an interop standard? For example, the current protocol has a > content transfer system layered over UDP. I would speculate that > VWRAP would use plain old HTTP rather than (say) attempting to > recreate the current system as LLSD-over-EventQueue-over-HTTP! > As above, but there may be parts of the protocol where might agree > to replace detailed, special-case messaging with generic > functionality - for example, as Linden has done recently, replacing > a whole sub-protocol surrounding search queries and results with > "here's the URL of a Web page". In which case, the standard may > include that such a URL is expected to exist, but nothing beyond that. > And to be clear, by "be standardized" I did not mean "rubber stamp > what's in a legacy protocol", but the overall process to design and > document forward-looking, inter-operable versions. > Discussing this face-to-face might prove beneficial. :) > > Joshua Right. So.. To be equally clear. 1) I certainly don't expect we'll codify what's on the wire today. 2) I do expect that that we need to end up with a formal shared approach to several types of non REST get/post messaging. In particular: a) genuinely idempotent, discardable ones b) Certified HTTP like ones c) Possibly, and less clearly, streams of "events" -- I think there is a funny question of how one manages "continuing event subscription" And yes, a face-to-face may help. Umm. How about the end of this month? - David ~ Zha --=_alternative 0071ACE9852576D9_= Content-Type: text/html; charset="US-ASCII"

ogpx-bounces@ietf.org wrote on 03/01/2010 03:10:25 PM:

> [image removed]
>
> Re: [ogpx] Draft work on Foundation and Type System
>
> Joshua Bell
>
> to:
>
> ogpx
>
> 03/01/2010 03:10 PM
>
> Sent by:
>
> ogpx-bounces@ietf.org
>
> On Mon, Mar 1, 2010 at 11:56 AM, David W Levine <dwl@us.ibm.com> wrote:
>
> > ... and the (independent?) axis of "does this need to be
> > standardized at the VWRAP level at all?"
> >  
> The answer to the later, is yes if you ask me. If we can't describe
> how the regions speak to the rest of the world, we're not actually
> going to have interop, we're either going to have insanely painful hand-off
> between clients, or an informal, non specified set of rules everyone has to
> follow.
>
> Oops - what I wrote was unclear. 
>
> To avoid confusion, let me clarify: by "does this need to be
> standardized?", I meant the following three closely linked ideas:
> Does this individual message/set of related messages even make sense
> in an interop standard? For example, the current protocol has a
> content transfer system layered over UDP. I would speculate that
> VWRAP would use plain old HTTP rather than (say) attempting to
> recreate the current system as LLSD-over-EventQueue-over-HTTP!
> As above, but there may be parts of the protocol where might agree
> to replace detailed, special-case messaging with generic
> functionality - for example, as Linden has done recently, replacing
> a whole sub-protocol surrounding search queries and results with
> "here's the URL of a Web page". In which case, the standard may
> include that such a URL is expected to exist, but nothing beyond that.
> And to be clear, by "be standardized" I did not mean "rubber stamp
> what's in a legacy protocol", but the overall process to design and
> document forward-looking, inter-operable versions.
> Discussing this face-to-face might prove beneficial. :)
>
> Joshua

Right. So.. To be equally clear.

1) I certainly don't expect we'll codify what's on the wire today.
2) I do expect that that we need to end up with a formal shared approach to several types
   of non REST get/post messaging.

   In particular:

    a) genuinely idempotent, discardable ones
    b) Certified HTTP like ones
    c) Possibly, and less clearly, streams of "events" -- I think there is a funny question of how one manages "continuing event subscription"

And yes, a face-to-face may help. Umm. How about the end of this month?

- David
~ Zha


--=_alternative 0071ACE9852576D9_=--