Re: [ogpx] Next Steps for OGPX WG Charter

[Infinity Linden <[e-mail]>]

On Sat, Aug 1, 2009 at 6:54 PM, Dave CROCKER<[e-mail]> wrote:

[stuff removed]

>
>>   For example: "The protocol produced by this working group should provide
>> a mechanism for authenticating a client to a server, cause a user's avatar
>> to be placed in the virtual world, move the user's avatar, receive a list of
>> objects in the user's avatar, etc."
>
> I don't think Larry or I formulated the above sentence, and in spite of
> that, I
> quite like it...  I think it's clear, direct, and contains the salient
> information.
>

fair enough. i think it was more my synthesis of a sequence of
sentences... not trying to say it was a direct quote really. but since
we all seem to like it, it's probably okay.

>
>> 3. The text of the charter should have a clear list of working group
>> deliverables.
>
> The current draft does not specify what existing documents it is drawing
> from,
> what it will/might/must do with them, nor what the limits on modification to
> those documents are -- if any.

hmm... i had thought i had some advice from someone to remove the list
of drafts we're basing the current definition of "the protocol
formerly known as OGP." but for the record... we have two sets of
documents: first, the internet drafts that have been circulating over
the last 6 months or so. the list of these drafts is on the mailing
list and at http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Meetings
. second, are the previous wiki pages from last summer's interop work.
the IETF drafts were distillations of what we learned from the work
last summer. they're supposed to reflect the state of the protocol
that was actually deployed last summer.

also... are we really going to have the "what are the limits on IETF
modification?" discussion again? rather than try to address that
question, which i feel i'm interpreting differently than what you're
trying to say, let me answer this question...

"given that we all know that the IETF has change control on these
documents and can make whatever changes it wishes with them, how much
change can be introduced to their current form before they represent a
protocol that is wholly incompatible with the installed OGP base and
difficult to use by existing implementers?"

in other words... i think we all understand that if the IETF (as
represented by the majority of participants with working code) wanted
to, it could change these docs to a form that would be different
enough that significant engineering would be required by existing
implementers to come into accords with the standard. this would be a
"good thing" (tm) if the changes led to a system that was more stable,
more scalable, and otherwise better. it would be a "bad thing" (tm) if
it was done for no reason and without evidence that such changes would
make solutions based on it better. those of us from the "second
life-like" virtual worlds community that have come to the IETF to
continue our work here understand this.

i guess what i'm trying to say is, this is a very difficult question
to answer. the drafts are not gospel, but they do reflect previous
engineering work. changing them will lead to some software engineer
somewhere having to at least typing "make" a few times on the command
line. but if the change is "good" then it'll be worth it. that's why
we're here, to bring the work we've done to a larger community for
review and to get recommendations for making it better.

so... if someone suggested changing the protocol to better support OGP
over avian carriers, i don't know how much support that change request
would garner (though i might have a slightly different answer on April
1st.) though if someone suggested "make it a little more obvious how
you're mapping application layer protocol on top of an HTTP(S)
transport in a way that you could also map the app layer protocol
messages on top of XMPP." that's a very serious request, and one i've
been thinking about a lot lately, even though i'm personally convinced
my organization is a long way off from using that transport.

>
>> The "what is needed" slide from the OGPX Draft Charter Issues presentation
>> ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was mentioned as a
>> possible source for this list for both (2) and (3), but needs massaging:
>>
>> (a) a security model describing trust relationships between hosts,
>> (b) guidelines for the use of existing authentication & confidentiality
>> mechanisms,
>> (c) mechanisms for:
>>  (i) establishing the user's presence in the virtual world
>>  (ii) moving a user's presence from one authoritative host to another,
>>  (iii) for identifying agents, and requesting information about them.
>> (d) format descriptions for objects and avatars in a virtual world,
>
> For c.ii should it really be 'host' or is it actually 'region'?  Also, the
> use of 'authoritative' implies there can non-authoritative hosts.  Is that
> correct?

yup. i think we're hitting the "mixing the abstract virtual worldy
layer with the concrete implementationish layer" confusion again. and
yes, after i type this, i'm going to go off and work on some more
definitions to make things a bit more clear. "region" is a logical
concept; it's a space inside a virtual world which contains objects
(avatars and assets) whose services are bound to a single server
instance. server instances are logical concepts in that you can have
multiple regions on the same host, and the protocol shouldn't make
assumptions about the service split. ergo... yes... i think you're
right, we are talking about regions.

but... when we come around again to start talking about trust, we may
want to make access control decisions based on host aspects: IP
address, client certificate to name a couple. and yes, we could put
that info into the PDUs being transferred, but we were hoping to
support a use model that allows us to make basic access control
decisions before parsing the message content.

the details of that discussion can probably be hammered out later...
but yeah, we have to come up with some verbiage that accurately
describes what we're trying to do so it can be inserted into the
charter.

as for the "authoritative" vs. "non-authoritative" split between
hosts. i'm using this term to differentiate our protocol from others
(DIS and HLA come to mind) and other virtual worlds implementations
(WoW and Diablo II come to mind) that make extensive use of
co-simulation. the second life-like worlds all use centralized
simulation. so i guess you could say there is probably at most one
machine that is "authoritative" for each region. so rather than saying
the host itself is authoritative, we could say that it's calculations
are authoritative in that while other hosts are free to co-simulate,
the "authoritative" host won't participate in a co-simulation protocol
with those hosts and will instead just send object updates to
interested clients. so we could probably use the terms "client" and
"server" and drop the term "authoritative" all together. but at some
point we have to make it clear we're not supporting co-simulation.

> As for what might be missing, I'm not seeing any semantics cited for any
> actions other than defining and moving users.  Nothing about simulation
> activity.

if you're talking about "simulating a virtual world" i would argue
that defining and moving user's avatars DOES simulate certain aspects
of consensus reality: specifically those aspects dealing with object
presence. if you're talking about "physics simulation" then yes, it's
not in the spec, and might not need to be. again, we're not doing
co-simulation, so there's no need for clients to know physics
simulation parameters. they just need to accept updates about how
objects are translating, rotating, scaling and deforming. whether
these modifications are the result of physics simulation or script
action should not be the concern of the non-co-simulating client.

>
>> 9. Ensure that while the charter scopes down the Virtual World problem
>> space, it does it in an inclusive way rather than focusing on what is out of
>> scope and thus indecipherable to non-subject matter experts. It is expected
>> that output of the WG may be useful in scenarios beyond those specifically
>> under consideration, much as RFC 2068 is not simply used for hypertext.
>
> This type of goal is often present, but I'm pretty sure I've never seen any
> chartering text about it that had any meaning or any impact.  For example,
> what objective criteria could the IESG apply during document approval, to
> tell whether the goal has been satisfied?

hmm. are you implying that the IESG will get upset if our work product
is used for something other than virtual world simulation? i don't
think you are. i fear that turning the charter into a feature list of
virtual worlds isn't the answer either (though it would make it easier
to verify.)

>
>
>> 10. Remove references to "wire" in "wire protocol"; this is implicit in
>> the scope of work for IETF. The phrase "application-layer protocol" (as
>> distinct from a novel transport-layer protocol) is accurate and sufficient.
>
> Yes, but I'll also vote for removing "application-layer".  I now understand
> that it's meant to imply that it's above transport, but there's already
> specific language about using transports.

but again, we're not trying to create a new transport. and we're
applying the argument that "the group's work product must be clear to
technical non-specialists." it seems that if we want a charter that
clearly identifies the groups scope, adding the words "application
layer" to the charter make it very clear that this is not the group
that will be developing LESS.

>
> No, this isn't a big deal, but in spite of primarily being as apps guy, I
> think removing the phrase makes the text cleaner, with no loss of meaning.
>
>
>> 11. Add text specifying: The WG will define interfaces for a set of
>> HTTP-based services ("web services") but not provide language specific
>> bindings ("API") onto those services.
>
> Huh?  What's this about?  Sounds like the working group is going to do web
> enhancements, rather than virtual world simulation.

no. this is not about adding enhancements to HTTP(S). it is about
layering the application layer protocol onto HTTP(S) as it exists now
and is expected to exist in the near future.

>> 12. Clarify the charter that we're explicitly targetting HTTP as the
>> default transport.
>>
>> A concern was raised that reusing HTTP will lead to unnecessary and tight
>> coupling with that protocol's capabilities and semantics; a suggestion was
>> made that if we wish to state that the protocols will be transport-neutral,
>> the WG will investigate at least one other transport. Should we just target
>> HTTP, or make the effort?
>
> If transport-independence is claimed, the claim won't really be meaningful
> unless at least two different transport mappings are provided.
>

hmm... maybe it's time to advertise in the XMPP community.