Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision

[Joshua Bell <[e-mail]>]

I do think this is one of the places in the charter where using "virtual
world(s)" is justified; the crisper wording may not imply much about the
intent to folks outside the effort, and (to Morgaine's point) seems very
abstract even to those inside the effort. Much of the draft charter feedback
we've gotten is that "concrete is a good thing"!

How about a tweak:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these virtual world
services to interoperate, when permitted by policy and shared trust domains.

Or:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to
interoperate, when permitted by policy and shared trust domains, enabling
the creation of interoperating virtual worlds.

(This rather short paragraph repeats "interoperate", "trust domain" and
"policy" twice, alas.)

On Fri, Aug 21, 2009 at 9:01 AM, David W Levine <[e-mail]> wrote:

>
> Fair enough. So.. Let me try an even crisper wording.
>
> >>>
> Regions and Services implemented according to the specifications may be
> deployed by separate organization with varying policies and trust domains.
> The OGPX protocols will provide the mechanisms for these services to
> interoperate,
> when permitted by policy and shared trust domains.
> >>>
>
>
>
>
>  *Infinity Linden <[e-mail]>*
>
> 08/21/2009 10:33 AM
>   To
> David W Levine/Watson/IBM@IBMUS  cc
> Meadhbh Siobhan <[e-mail]>om>, [e-mail],
> [e-mail]  Subject
> Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision
>
>
>
>
> i would argue that we shouldn't be introducing a term into the charter
> that we can't define. the term "virtual world" is more appropriate for
> the MMOX effort. OGP has an intentionally loose definition of the term
> "virtual world," and it means (roughly) "the set of places you can
> teleport or walk to." this is NOT a feature that is defined by
> protocol, but by trust.
>
> there is absolutely nothing in the protocol that requires region
> operator 'A' to trust region operator 'B' or agent domain operator
> 'C'. we do, however, define message formats and techniques to carry
> artifacts of this trust. there is nothing in the PROTOCOL that defines
> who trusts who.
>
> this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
> S/MIME. the protocols MUST NOT define trust relationships for
> operators. they MUST be deferred to deployers. because we cannot
> define trust in the protocol, it is inappropriate to insert language
> in the charter based on that assumption.
>
> if you define the term "virtual world" as "the set of places you can
> teleport to" then this term CAN'T have meaning because it depends on
> local policy that is out of the control of the protocol specifiers.
> this is why the term is not used. this is why we define the protocol
> in terms of things we CAN make some assumptions about: the required
> parties in a protocol transaction. in the case of teleport, this
> includes the originating region, the target region and the agent
> domain.
>
> this is the moral equivalent to saying the following in the ssh
> specification "every ssh server must define a user called 'root', and
> that user must have full permissions over the server." as it happens,
> a great number of ssh servers have a superuser named root, but some
> don't. there's no reason to define it in the protocol because it's a
> matter of local policy.
>
> when we say "there are things called virtual worlds, and they're
> defined as the set of all places you can teleport to," what does that
> give us? from a protocol perspective, it gives us nothing, because we
> will never user it.
>
> as part of the introduction, we may want to say "this protocol can be
> used to construct a set of connected regions that MAY be rendered by a
> client application in a form that appears as a virtual world." but
> this gets us what?
>
> -cheers
> -meadhbh
>
> On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<[e-mail]> wrote:
> >
> > I am going to suggest inserting a very  concise paragraph after the
> second
> > paragraph.
> >
> >>>> Insert
> >
> > Regions and Services implemented according to the specifications may be
> > assembled into
> > multiple virtual worlds. These worlds may embody multiple domains of
> trust.
> > Deployed virtual
> > worlds may support different policies of use. Constrained by these
> policies,
> > the protocols will
> > permit interoperation across OGPX  virtual worlds with compatible
> policies
> > and trust models.
> >
> >>>> end insert
> >
> > I poersonally think this is implicit, but making it explicit doesn't
> hurt.
> >
> > I think this preserves the separation of concern we desire. Mechanisms
> are
> > defined at the
> > protocol level. Policy is defined separate from mechanism. It should be
> > possible to deploy
> > everything from highly constrained walled gardens to very open grids. The
> > degree of
> > avatar, agent, service and digital goods flow between specific virtual
> > worlds will vary according
> > to the policies, and trust boundaries established by deployers. Nothing
> in
> > the specifications
> > dictates specific policies
> >
> > This follows the existing  practices of the web and internet.The core
> > protocols
> > and formats of the internet permit interoperation, but deployers
> routinely
> > constrain
> > the accessibility and reach of services based on policy.
> >
> >
> > - David W. Levine
> > ~ Zha Ewry (ISL)
> >
> >
> >
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>