Subject: [ogpx] Draft work on Foundation and Type System

From: Mark Lentczner <[email-masked]>
Date: Mon, 1 Mar 2010 10:42:08 -0800

I'll be working on another revision to the Foundation and Type System drafts this week.

I see the following issues that I'll be taking on:

1) Type System: Missing comment syntax -- I'll add it

2) Type System: Binding to HTTP -- My approach will be to reword this so that LLSD could be serialized to other systems, and LLIDL described services could easily be bound to other transports. However, the abstract model that they from is very REST like, and REST as embodied by HTTP. So, for example, the existence of a small number of transport "verbs" is assumed, whereas the availability of headers is not. I do think, like Josh, that since the vast bulk of use is indeed over HTTP, that splitting into multiple documents doesn't serve at this point. Remember: Future drafts are perfectly capable of referencing only parts of other drafts.

3) Foundations: Continued word smithing.

	- Mark Lentczner

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: David W Levine <[email-masked]>
Date: Mon, 1 Mar 2010 14:04:57 -0500

On the type system, I'm glad to see the LLSD serializing to other 
transports getting some love. My sense is that there are, effectively four 
types of things which cover the space. The bulk, as you note is
RESTful http semantic operations.  There are two other common types of 
communication which flow today, and which need to be captured as we move 
forward. There are updates which, if we *could* 
expose a REST resource on the client, we would post directly to the 
client. But these do have the flavor of being fundamentally unsolicited. 
While one can model these as a series of "posts" against the
general client, its not clear to me that this fully captures what's 
happening, nor does it help one associate the updates with the source in a 
clean fashion. There is the question of whether *some*
of the current UDP traffic "Take two steps forward" "Rotate this prim 5 
degrees" again models exactly as posts on a REST resources or something 
different.  There is also a small set of operations which
probably fall close to the "certified http" model Which Linden was working 
on a while back, where there is a very strong need to ensure close to ACID 
behavior.

 I'd love to see as much of this space  cleanly modeled as LLIDL services 
as possible. I don't imagine it all being solved in one draft, one of the 
strengths of the IETF model is being able to issue
successive refinements to a draft as the community's  understanding grows. 

I firmly prefer the core LLSD/LLIDL stuff in one draft.  I think it *may* 
make some sense to have a "this is baked" draft and a "This is being 
worked out" informational draft which will feed into the baked
draft in the future. 

- David
~ Zha

From:
Mark Lentczner <[email-masked]>
To:
[email-masked]
Date:
03/01/2010 01:42 PM
Subject:
[ogpx] Draft work on Foundation and Type System
Sent by:
[email-masked]

I'll be working on another revision to the Foundation and Type System 
drafts this week.

2) Type System: Binding to HTTP -- My approach will be to reword this so 
that LLSD could be serialized to other systems, and LLIDL described 
services could easily be bound to other transports. However, the abstract 
model that they from is very REST like, and REST as embodied by HTTP. So, 
for example, the existence of a small number of transport "verbs" is 
assumed, whereas the availability of headers is not. I do think, like 
Josh, that since the vast bulk of use is indeed over HTTP, that splitting 
into multiple documents doesn't serve at this point. Remember: Future 
drafts are perfectly capable of referencing only parts of other drafts.

- Mark Lentczner

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden

_______________________________________________
ogpx mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ogpx

---

From: Joshua Bell <[email-masked]>
Date: Mon, 1 Mar 2010 11:47:14 -0800

On Mon, Mar 1, 2010 at 11:04 AM, David W Levine <[email-masked]> wrote:

>
> There is the question of whether *some*
> different.

FYI, while it's not going to be fully baked, in prep for the "What's not in
VWRAP" discussion I want to have in Anaheim I'm going through the Linden
"legacy protocol" to populate categories of messages:

   - Messages with request/response semantics
   - Messages with lossy streaming semantics
   - Messages with notification semantics

... and the (independent?) axis of "does this need to be standardized at the
VWRAP level at all?"

> There is also a small set of operations which probably fall close to the
> "certified http" model Which Linden was working on a while back, where there
> is a very strong need to ensure close to ACID behavior.

Excellent point! I should add that to the list of categories.

---

From: David W Levine <[email-masked]>
Date: Mon, 1 Mar 2010 14:56:31 -0500

[email-masked] wrote on 03/01/2010 02:47:14 PM:

> [image removed] 
> 
> Re: [ogpx] Draft work on Foundation and Type System
> 
> Joshua Bell 
> 
> to:
> 
> ogpx
> 
> 03/01/2010 02:47 PM
> 
> Sent by:
> 
> [email-masked]
> 
> of the current UDP traffic "Take two steps forward" "Rotate this 
> prim 5 degrees" again models exactly as posts on a REST resources or
> something different.  
> 
> FYI, while it's not going to be fully baked, in prep for the "What's
> not in VWRAP" discussion I want to have in Anaheim I'm going through
> the Linden "legacy protocol" to populate categories of messages:
> Messages with request/response semantics
> Messages with lossy streaming semantics
> Messages with notification semantics
> ... 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. 

> There is also a small set of operations which probably fall close to
> the "certified http" model Which Linden was working on a while back,
> where there is a very strong need to ensure close to ACID behavior. 
>

---

From: Joshua Bell <[email-masked]>
Date: Mon, 1 Mar 2010 12:10:25 -0800

On Mon, Mar 1, 2010 at 11:56 AM, David W Levine <[email-masked]> wrote:

> 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

---

From: David W Levine <[email-masked]>
Date: Mon, 1 Mar 2010 15:41:38 -0500

[email-masked] wrote on 03/01/2010 03:10:25 PM:

> 03/01/2010 03:10 PM
hand-off 
to 
> 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.

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

---

From: David W Levine <[email-masked]>
Date: Mon, 1 Mar 2010 17:48:25 -0500

I've updated the client side caps draft modestly to get it into the 
discussion queue for the Anaheim IETF f2f. (Further updates fully 
expected)
Feedback and comments, welcome, as always, on list.

http://www.ietf.org/id/draft-levine-vwrap-clientcap-00.txt 

- David
~ Zha

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 1 Mar 2010 19:55:40 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David W Levine
> Sent: Monday, March 01, 2010 11:57 AM
> To: Joshua Bell
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ogpx] Draft work on Foundation and Type System
> 
> 
> > There is the question of whether *some* of the current UDP traffic
> > "Take two steps forward" "Rotate this prim 5 degrees" again models
> > exactly as posts on a REST resources or
> > something different.
> >
> > Messages with request/response semantics Messages with lossy
> streaming
> > semantics Messages with notification semantics ... 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.
> 

I would say no, at least not in VWRAP. Virtual World Region Agent Protocol bundles all of the cross-domain trust issues, protocol negotiation, and service establishment into a neat package that hands the viewer a blob of protocol-specific information on how to start communicating with a region. We have multiple groups involved that have looked at a fairly diverse set of use cases and are moving toward rough consensus and working code. In contrast, I can't see the standardization of a client<->server virtual world scene graph protocol becoming anything other than a rubber stamp of the current Linden Lab implementation ported to HTTP or a wandering discussion that is a few years ahead of its time.

John

---

From: Morgaine <[email-masked]>
Date: Wed, 3 Mar 2010 05:17:35 +0000

+1 John.

We've barely begun to touch the use cases, and we know almost nothing yet
about how the messaging may look for anything beyond initial service
establishment, and even that's at an initial stage of discussion.  We're
certainly not ready yet to define the general vocabulary of communications
between clients and services when we don't yet know WHAT they'll be talking
about.

It's premature to define the protocol primitives.  I like Joshua's 3rd point
a lot though:

   - *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.*

That was very well said.  We've discussed very little about interoperability
so far, and we seem to be assuming that everything is compatible with
everything else, whereas clearly that is almost never going to be true
except coincidentally at given points in time.  Interoperable versions of
the legacy protocol require thinking about *extensibility* in an environment
where everything is always evolving, and we haven't done that yet.

One thing that we need to examine very carefully arose in today's AW
Groupies meeting with realXtend:  that if a region cannot handle unknown
content types, then there cannot be cross-world tourism through that region
even when all agents present have everything they need to make sense of the
multi-world mashup.  Clearly interop is thwarted in this situation, which
underlines the point that we need to examine how we intend to handle data
and be certain that we can handle it flexibly enough to allow broad
interop.  We haven't done anything like this yet.

Morgaine.

=============================

On Tue, Mar 2, 2010 at 2:55 AM, Hurliman, John <[email-masked]>wrote:

> I would say no, at least not in VWRAP. Virtual World Region Agent Protocol
> bundles all of the cross-domain trust issues, protocol negotiation, and
> service establishment into a neat package that hands the viewer a blob of
> protocol-specific information on how to start communicating with a region.
> We have multiple groups involved that have looked at a fairly diverse set of
> use cases and are moving toward rough consensus and working code. In
> contrast, I can't see the standardization of a client<->server virtual world
> scene graph protocol becoming anything other than a rubber stamp of the
> current Linden Lab implementation ported to HTTP or a wandering discussion
> that is a few years ahead of its time.
>
> John

---

From: Morgaine <[email-masked]>
Date: Wed, 3 Mar 2010 14:04:22 +0000

An early response referring to nothing more than section 2.4/Overview ...

I strongly urge quick removal (prior to Anaheim) of the "Joe's Pirate Bay"
reference and the general tone of deprecation for what a large portion of
the online world views as freedom, especially among the younger generation.
One might just as easily refer to "Evil Corporate World Provider", but
neither of these side swipes really advances the clarity of technical
discussions.

I think that a simple reference to "Untrusted region" expresses the point
clearly enough.

Morgaine.

==========================================

On Mon, Mar 1, 2010 at 10:48 PM, David W Levine <[email-masked]> wrote:

> discussion queue for the Anaheim IETF f2f. (Further updates fully expected)
> *http://www.ietf.org/id/draft-levine-vwrap-clientcap-00.txt*<http://www.ietf.org/id/draft-levine-vwrap-clientcap-00.txt>
>
>
> - David
> ~ Zha
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Mar 2010 17:38:10 -0500

> I think that a simple reference to "Untrusted region" expresses the point

I agree.

Barry, as participant