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

[Infinity Linden <[e-mail]>]

works for me.

On Fri, Aug 21, 2009 at 9:10 AM, Joshua Bell<[e-mail]> wrote:
> 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
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>