Mark Lentczner <markl@lindenlab.com> · 03/01/2010 01:46 PM

_______________________________________________

ogpx mailing list

ogpx@ietf.org

https://www.ietf.org/mailman/listinfo/ogpx

_______________________________________________

ogpx mailing list

ogpx@ietf.org

https://www.ietf.org/mailman/listinfo/ogpx

ogpx-bounces@ietf.org 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:
> 

> ogpx-bounces@ietf.org
> 

> On Mon, Mar 1, 2010 at 11:04 AM, David W Levine <dwl@us.ibm.com>
wrote:
> 

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

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

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

> ogpx mailing list

> ogpx@ietf.org

> 
https://www.ietf.org/mailman/listinfo/ogpx

> ... and the (independent?) =
axis of "does
this need to be 

> standardized at the VWRAP level at all?"
> =C2=A0
The answer to the later, is yes if you ask m=
e. 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 h=
ave
insanely painful hand-off
between clients, or an informal, non specified set
of rules everyone has to
follow. 
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

Thanks, folks. I did some agenda bashing after talki=
ng
with several of

the topic owners, here's the latest:

2=1B=1Bmin - Mixed Reality Status Check  - Joshua Bell

10=1Bmin - Welcome, Introductions, Agenda Review/Bashing, News - Barry

Leiba, Joshua Bell (chairs)

25min - Open Issues in "Foundation"  -  Mark Lentc=
zner

=1B* Including transport (EventQueue, HyBi, WebSockets, ...), road map

25min - Open Issues in "Abstract Type System" - Mark Lentczner

* Including implementation experiences (Mark Lentczner, John Hurliman)

10min - Open Issues in "Introduction and Goals"  - Meadhbh
Hamrick

5min - Client-Side Capabilities - David W Levine

5min - Status/Issues in "User Authentication"  - Meadhbh
Hamrick

* Including OAuth

15min - Cable Beach and VWRAP  - John Hurliman

5min - Status/Issues in"Client Application Launch Message" 
- Meadhbh Hamrick

5min - Status/Issues in "Deployment and Trust Patterns" - David
W Levine

15min - What's NOT in VWRAP (a dissection of the Linden "Legacy"<=
br>
Protocol)  - Joshua Bell

15min - Virtual World Accessibility - Katherine Mancuso

* NOTE: I don't have confirmation that Katherine will be attending;

pinging via email

* Including "making metadata accessible"

10min - Next Steps - Barry Leiba, Joshua Bell (chairs)

Reminders:

* Internet Draft final submission cut-off due 3/8 (i.e. stop revising

drafts prior to IETF77 at this point)

* Draft WG session agenda is due by 3/10 (i.e. Barry and I will submit

the above)

* Final WG session agenda is due by 3/15 (although we will bash at the

start of the session)

(See 
http://www.ietf.org/meeting/cutoff-dates-2010.html<=
/font>

for the

down-to-the-minute-in-what-time-zone cut-offs.)

As always, feedback appreciated - we can still adjust the schedule to

squeeze in additional topics. Where possible, I'd like to discuss

things within the scope of the drafts (thus letting the draft editors

lead the discussion), but identifying specific sub-topics that we

should budget time for is a good thing (IMHO).

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

ogpx mailing list (VWRAP working group)

ogpx@ietf.org

https://www.ietf.org/mailman/listinfo/ogpx

Thanks, folks. I did some agenda bashing after tal=
king
with several of

the topic owners, here's the latest:

2  min - Mixed Reality Status Check=C2=A0 - Joshua Bell

10 min - Welcome, Introductions, Agenda Review/Bashing, News - Barry

Leiba, Joshua Bell (chairs)

25min - Open Issues in "Foundation"=C2=A0 -=C2=A0=C2=A0Mark Lentc=
zner

 * Including transport (EventQueue, HyBi, WebSockets, ...), road map

25min - Open Issues in "Abstract Type System" - Mark Lentczner
* Including implementation experiences (Mark Lentczner, John Hurliman)

10min - Open Issues in "Introduction and Goals"=C2=A0 - Meadhbh
Hamrick

5min - Client-Side Capabilities - David W Levine

5min - Status/Issues in "User Authentication"=C2=A0 - Meadhbh
Hamrick

* Including OAuth

15min - Cable Beach and VWRAP=C2=A0 - John Hurliman

5min - Status/Issues in"Client Application Launch Message"=C2=A0
- Meadhbh Hamrick

5min - Status/Issues in "Deployment and Trust Patterns" - David
W Levine

15min - What's NOT in VWRAP (a dissection of the Linden "Legacy&qu=
ot;

Protocol)=C2=A0 - Joshua Bell

15min - Virtual World Accessibility - Katherine Mancuso

* NOTE: I don't have confirmation that Katherine will be attending;

pinging via email

* Including "making metadata accessible"

10min - Next Steps - Barry Leiba, Joshua Bell (chairs)

Reminders:

* Internet Draft final submission cut-off due 3/8 (i.e. stop revising

drafts prior to IETF77 at this point)

* Draft WG session agenda is due by 3/10 (i.e. Barry and I will submit

the above)

* Final WG session agenda is due by 3/15 (although we will bash at the

start of the session)

(See 
http://www.ietf.org/meeting/cut=
off-dates-2010.html

for the

down-to-the-minute-in-what-time-zone cut-offs.)

As always, feedback appreciated - we can still adjust the schedule to

squeeze in additional topics. Where possible, I'd like to discuss

things within the scope of the drafts (thus letting the draft editors

lead the discussion), but identifying specific sub-topics that we

should budget time for is a good thing (IMHO).

_______________________________________________

ogpx mailing list (VWRAP working group)

ogpx@ietf.org

https://ww=
w.ietf.org/mailman/listinfo/ogpx

ogpx-bounces@ietf.org wrote on 03/29/2010 02:05:48
PM:

> [image removed] 
> 

> Re: [ogpx] type-system : binary elements in JSON serializations
> 

> Hurliman, John 
> 

> to:
> 

> Meadhbh Hamrick, ogpx
> 

> 03/29/2010 02:06 PM
> 

> Sent by:
> 

> ogpx-bounces@ietf.org
> 

> I think supporting conversion to and from string and binary at the

> LLSD level is a good idea, and I don't see any downsides to this approach.

> 

> John

> 

+1
ogpx-bounces@ietf.org wrote on 03/29/2010 01:16:18
PM:

> [image removed] 
> 

> [ogpx] verbiage : domain, agent domain, region domain, trust domain,

> service, etc.
> 

> Meadhbh Hamrick 
> 

> to:
> 

> ogpx
> 

> 03/29/2010 01:17 PM
> 

> Sent by:
> 

> ogpx-bounces@ietf.org
> 

> so... there's been some grumbling about the use of terminology on
the

> list and in drafts. at the f2f we reiterated the need to agree on
some

> basic terms. as i'm sure we all have one or two things to say about

> this subject, let's get the ball rolling...

> 

> as many people on this list know, the terms "agent domain"
and "region

> domain" come from the previous OGP work. the term "domain"
was

> originally thought to mean "a collection of machines administered
by

> the same authority." an "agent domain" was a domain
that managed

> user-oriented data: profile info, avatar presence, IM services,

> inventory, etc. a "region domain" was a domain that managed

> place-oriented data and processes: object presence, simulation, etc.

> 

> as the model was developed and we gained more deployment expertise,
a

> couple things became clear:

> 

> 1. there's a high quality implementation of an asset service out there

> (cable beach) which _could_ be deployed independently of an OpenSim
or

> LL instance. does this mean we should have an "asset domain"?

> 

> 2. linden deployment patterns (which formed the basis of early drafts)

> may not be used by all participants. specifically, an agent domain
may

> "contract out" fulfillment of certain services to a third
party. think

> of the way that linden currently deploys maptiles by way of amazon
S3.

> for the purposes of managing maptiles, is S3 considered part of the

> linden agent domain? functionally it is, but even though it is trusted

> by linden,machines that serve the maptile requests will always be

> identified as belonging to amazon. (more info at

> 
http://aws.amazon.com/solutions/case-studies/linden-lab/

)

> 

> in response to point 1, several of us started to think that we

> probably would want to think about what makes a domain a region or

> agent domain, and if it's possible to have an "asset domain."
this led

> to some verbiage in an earlier intro and goals draft that described

> "agent domains" as domains that contain an authentication
service and

> "region domains" as domains that expose an object presence
service.

> other groups of systems administered by the same entity were simply

> "domains"

> 

> fortunately, no one noticed we didn't define the term "service"

> especially rigorously. but i think there was general consensus that
a

> "service" was a collection of "protocol endpoints"
that performed a

> function on behalf of a client. an "endpoint" was an entity
with an

> address that represented a RESTful resource that could be accessed
to

> change or query the state of a service. for the most part, we talked

> of endpoints as being HTTP(S) urls, as most of us had experience with

> doing "OGP over HTTP."

> 

> while some of us debated the merits of various terms, others of us

> were wrestling with issue 2 above: what constitutes a domain? are
all

> machines in a domain trusted by each other? what about when you add

> services from multiple domains, does that make a new domain? should
we

> call it something else to highlight the fact that some of the machines

> in the domain may not trust other machines in the domain explicitly?

> if so, then why the heck do we have the term domain?

> 

> one suggestion was to redefine the term "domain" to mean
"a collection

> of machines." then the term "trust domain" is used
to define a

> collection of machines that share a trust relationship. a "composite

> domain" may be used to describe machines from two distinct trust

> domains that cooperate to deliver a service. "services,"
in turn are

> contained entirely in a domain. (so if a service is delivered by

> machines in two different trust domains, i.e. it's a composite domain,

> then that service is said to be contained by the composite domain,
not

> the two trust domains that cooperate to deliver the service.)

> 

> so. ugh. what do we say about this:

> 

> domain - a collection of machines

> 

> trust domain - a domain whose members share trust characteristics.

> 

> trust characteristic - an abstract description of which entities are

> allowed to access which services on which members of a domain.

> 

> composite domain - a domain whose members are composed of two or more

> distinct trust domains. note that a composite domain may form a new

> trust domain.

> 

> service - a collection of protocol endpoints that implement a function

> (like authentication, inventory, IM, search, etc.)

> 

> (protocol) endpoint - the address of a RESTful resource a client may

> use to query or change the state of a service.

> 

> agent domain - a domain that exposes an authentication service.

> 

> region domain - a domain that exposes an object presence services.

> 

> comments? questions? death threats?

> 

> --

> meadhbh hamrick * it's pronounced "maeve"

> @OhMeadhbh * 
http://meadhbh.org/

* OhMeadhbh@gmail.com

First, +1 (if not more) on getting the terminology
coherent. The time has come to speak of things... We need names for the
things, and we need those names in the base drafts, with nice crisp definitions.

Names only help when they add real value. If we can't
crisply say "This is a Blongezorf, and this isn't." we're merely
muddying the waters. For domain, this is especially tricky as there are
several very good and normal uses of Domain, both in Distributed Computing,
and to and extent the casual discussion centering around the specs today.

From my perspective, there's a nice progression of
things which we can define.
We have a set of "messages" which are defined
in LLIDL, which laminate together into interaction patterns
(Post message X, Get response set Y1-Y7, post message
Q) Mark that as a "service" , marked off by one or more capabilities.
 Those services combine into a a cluster of services which form a
capital "s" Service, such as a "Asset Server" or an
"Inventory Service" 
I tend to think about the core "capital S"
services as what we're busy defining. I'm not at all sure that, given the
diversity of deployment patterns, defining "Domains" which tie
to these into clusters beyond what people deploy actually adds any depth
to the explanatory framework. I can see that there may well be some clusters
of "Big S" services which often cluster, which may be worth looking
at, if there is useful power in naming those clusters. Unless those clusters
form of necessity, not habitual deployment, I'm thinking they would be
a non-normative term used elucidate rather than define. 
- David
~ Zha 

First, +1 (if not more) on getting the=
 terminology
coherent. The time has come to speak of things... We need names for the
things, and we need those names in the base drafts, with nice crisp definit=
ions.

Names only help when they add real value. If we ca=
n't
crisply say "This is a Blongezorf, and this isn't." we're=
 merely
muddying the waters. For domain, this is especially tricky as there are
several very good and normal uses of Domain, both in Distributed Computing,
and to and extent the casual discussion centering around the specs today.

From my perspective, there's a nice progressio=
n of
things which we can define.
We have a set of "messages" which are de=
fined
in LLIDL, which laminate together into interaction patterns
(Post message X, Get response set Y1-Y7, post mess=
age
Q) Mark that as a "service" , marked off by one or more capabilit=
ies.
=A0Those services combine into a a cluster of services which form a
capital "s" Service, such as a "Asset Server" or an
"Inventory Service" 
I tend to think about the core "capital S&quo=
t;
services as what we're busy defining. I'm not at all sure that, giv=
en the
diversity of deployment patterns, defining "Domains" which tie
to these into clusters beyond what people deploy actually adds any depth
to the explanatory framework. I can see that there may well be some cluster=
s
of "Big S" services which often cluster, which may be worth looki=
ng
at, if there is useful power in naming those clusters. Unless those cluster=
s
form of necessity, not habitual deployment, I'm thinking they would be
a non-normative term used elucidate rather than define. 
- David
~ Zha 
Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote
on 03/29/2010 04:54:31 PM:

> [image removed] 
> 

> Re: [ogpx] verbiage : domain, agent domain, region domain, trust  

> domain, service, etc.
> 

> Meadhbh Hamrick 
> 

> to:
> 

> David W Levine
> 

> 03/29/2010 04:55 PM
> 

> Cc:
> 

> ogpx, ogpx-bounces
> 

> so i said services contain "protocol endpoints" rather than

> "capabilities" as it's possible for services to have well
defined,

> public endpoints that are NOT capabilities.

> how 'bout...
Quite right, on "service endpoint" my bad.

> 

> the terms "asset domain" and "region domain" are
used to identify the

> domain of certain types of transactions in the protocol. their use

> underscores the potential separation of the roles each domain plays.

> 

In some deployments mayhap. Not in all. The roles
the domain plays in these
examples is a deployment choice, nothing more. There
may be some trust/admin
patterns which are common, but then we need to focus
on those rather than
thinking calling it an "agent domain" is
clarifying. 

> so the terms "agent domain" and "region domain"
are "positional" and

> describe the function in a protocol transaction, NOT a requirement

> that a group of machines implement a particular cluster of services.

> --

> meadhbh hamrick * it's pronounced "maeve"

> @OhMeadhbh * 
http://meadhbh.org/

* OhMeadhbh@gmail.com

> 

But, positional terms which describe specific patterns,
which are deployment choices rather
than functional requirements actually confuse not
clarify. 
> so we would say, "the agent domain initiates
the process of placing an

> agent in a region domain's simulator" rather than "the first
service

> initiates the process of placing an agent in a region."
It might. Or the authentication service might give
you NOTHING more than a sheaf of
seed caps each on a stand-alone service which is separately
deployed. (I think that's
not going to be the most common deployment pattern,
but its certainly one you could deploy,
and one we need to be able to describe. 
Unless we can say "This is a term which always
cuts things into separable parts", I think we're 
confusing deployment with architecture. To the degree
you can say why "Agent Domain" is more
explanatory than saying "This common cluster
of services" in which case I'm perfectly happy saying that. But
I'm thinking that beyond a very small cluster (Auth,
IM endopint, Presence broadcast, and even those could be delegated) I'm
not sure what HAS to be in an Agent Domain, rather than what many people
will CHOSE to put in one. 
Please note I think this is exactly the discussion
we *should* be having. We need to make it clear what the term
is actually buying us, and how we could benefit from
it. 
- David
~Zha
At the point where you are describing an "Authentication
and Login Domain" "Asset Domain" "Inventory Domain"
"IM Domain" you are effectively binding domain to type of service
offered. 
The whole reason I an pushing back so hard on "Agent
Domain" is because it conflates a specific deployment pattern with
something special, and uses an already overloaded term. I think a perfectly
rational and sane use of the term would be to follow common IT and Distributed
computing practices, such as "Trust Domain" and "Administrative
Domain" as well is "IP domain"  This would allow us
to write statements like:
"In this grid, the Login, IM, Presence, Inventory,
Group, Search and Teleport Services live within a single trust domain.
The Regions supported by this grid fall into separate administrative and
trust domains. This grid access a variety of asset and micro-payment services
all of which are outside both our trust and administrative domain."

One of the pain points introduced by binding ANY grouping
of services into the term "domain" at the architectural level
is that is implies that this specific deployment pattern is privileged
within the specifications. The closest that I come to thinking that really
exists in VWRAP is the cluster of services required to support a region.
Even here, tho, the pattern, as a web pattern, is mostly that of a facade,
and the underlying deployment of services which actually comprise any specific
region may well be separated across trust and administrative domains. A
rather obvious example being the voice services in the second life grid
which are delegated to Vivox, crossing several "domain" boundaries.

If we believe there are privileged groupings of services
which must be clustered and cannot be facaded or separately deployed from
other services lets enumerate them and understand why they are clustered.

- David
~ Zha
At the point where you are describing an "Aut=
hentication
and Login Domain" "Asset Domain" "Inventory Domain"=
;
"IM Domain" you are effectively binding domain to type of service
offered. 
The whole reason I an pushing back so hard on &quo=
t;Agent
Domain" is because it conflates a specific deployment pattern with
something special, and uses an already overloaded term. I think a perfectly
rational and sane use of the term would be to follow common IT and Distribu=
ted
computing practices, such as "Trust Domain" and "Administrat=
ive
Domain" as well is "IP domain" =A0This would allow us
to write statements like:
"In this grid, the Login, IM, Presence, Inven=
tory,
Group, Search and Teleport Services live within a single trust domain.
The Regions supported by this grid fall into separate administrative and
trust domains. This grid access a variety of asset and micro-payment servic=
es
all of which are outside both our trust and administrative domain."

One of the pain points introduced by binding ANY g=
rouping
of services into the term "domain" at the architectural level
is that is implies that this specific deployment pattern is privileged
within the specifications. The closest that I come to thinking that really
exists in VWRAP is the cluster of services required to support a region.
Even here, tho, the pattern, as a web pattern, is mostly that of a facade,
and the underlying deployment of services which actually comprise any speci=
fic
region may well be separated across trust and administrative domains. A
rather obvious example being the voice services in the second life grid
which are delegated to Vivox, crossing several "domain" boundarie=
s.

If we believe there are privileged groupings of se=
rvices
which must be clustered and cannot be facaded or separately deployed from
other services lets enumerate them and understand why they are clustered.

- David
~ Zha

From:	Mark Lentczner <markl@lindenlab.com>
To:	ogpx <ogpx@ietf.org>
Date:	03/01/2010 01:46 PM
Subject:	Re: [ogpx] Draft Agenda for VWRAP WG Session at IETF77
Sent by:	ogpx-bounces@ietf.org

From:	Joshua Bell <josh@lindenlab.com&g= t;
To:	ogpx <ogpx@ietf.org>
Date:	03/04/2010 02:16 PM
Subject:	Re: [ogpx] Draft Agenda for VWRAP WG Session at IETF77
Sent by:	ogpx-bounces@ietf.org

From:	Joshua Bell= <josh@lindenlab= .com>
To:	ogpx <ogpx@ietf.org>
Date:	03/04/2010 02:16 PM
Subject:	Re: [ogpx] = Draft Agenda for VWRAP WG Session at IETF77
Sent by:	ogpx-bounces@ietf.org

From:	Mark Lentczner <markl@lindenlab.com>
To:	ogpx@ietf.org
Date:	03/01/2010 01:42 PM
Subject:	[ogpx] Draft work on Foundation and Type System
Sent by:	ogpx-bounces@ietf.org