Subject: Re: [ogpx] Next Steps for OGPX WG Charter

From: Dave CROCKER <[email-masked]>
Date: Sun, 02 Aug 2009 03:54:44 +0200

Joshua,

g'day.

This latest draft is indeed very much better!

Joshua Bell wrote:
> 1. Include a succinct but realistic summary of what the problem space 
> and protocol are. At the BOF, Chris Newman made the comment "The 
> impression I've got is this is a 3-D multi-vendor Facebook. I think 
> that's really cool." (thanks, Chris!). This really helped BOF 
> participants unfamiliar with VWs understand what the heck we were 
> talking about.
> 
> Can mailing list participants come up with something short, accurate, 
> educational, and catchy?

    "The working group will define a protocol to support a 3-D virtual world
simulation environment between users and independently operated simulation
regions, and amongst those regions."

This is neither as concise nor as sexy as Chris' summary, but it also lacks the
proprietary reference.  (Perhaps the social networking usage aspect, however, 
needs to be included? But then, I'm not clear how the protocol work mandates 
that usage.)  I think is also describes the core technical activity, as I 
understand the goal.  That presumes that I understand it correctly...

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

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

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

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.

> Are there any other suggestions, preferences, or vetos? Does the 
> proposed protocol name need to be reflected in a revised Working Group 
> name? 

They certainly don't have to be the same, but they do need to be useful, of course.

> 7. Explicitly list extant drafts which will be the starting point for 
> the WG effort:
> 
> * http://tools.ietf.org/html/draft-hamrick-ogp-intro
> * http://tools.ietf.org/html/draft-hamrick-llsd-00
> * http://tools.ietf.org/html/draft-hamrick-ogp-auth
> * http://tools.ietf.org/html/draft-hamrick-ogp-launch
> * http://tools.ietf.org/html/draft-lentczner-ogp-base
> * http://tools.ietf.org/html/draft-levine-ogp-clientcap
> * http://tools.ietf.org/html/draft-levine-ogp-layering
> 
> Is this list complete and accurate?

Since these document represent a substantial history, it really is important for 
the charter to cite them explicitly and specify how maleable their content is. 
"Starting point" could mean that the final result has no visible relationship to 
these documents and that they merely used for initial discussion. As I've noted 
earlier, I am pretty sure you folks want more constraints than that.  Whatever 
you choose, it's likely to be a point of negotiation with the IESG, but you 
should state what role these docs are expected/required to play.

> 8. The protocols are intended to provide a clear seperation of concerns 
> between mechanisms  used to access resources and policies controlling 
> use of those mechanisms. Many deployment choices will be defined by 
> policy, not protocol. This needs to be clear in the charter.

yup!

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

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

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.

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

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 02 Aug 2009 11:57:44 +0200

Dave CROCKER wrote:

> Carlo Wood wrote:
>
>> On Fri, Jul 31, 2009 at 02:31:26AM +0200, Carlo Wood wrote:
>>
>>> Someone once said: "Of course it's not working perfectly: this is
>>> the VERY first version of the Matrix".
>>
>> So, what about:  MAP ... Matrix Alpha Protocol
>
> A pronounceable acronym can be quite nice.
>
> My own suspicion is that one based on being humorous, ironic, or 
> otherwise clever, probably isn't, if the effort is to be taken 
> seriously.  The fun component resonates initially, but then grows 
> stale on constant repetition (over the years.)

Agreed.

I also think the name should be reasonably unique so that it comes up 
high in web searches.

---

From: Infinity Linden <[email-masked]>
Date: Mon, 3 Aug 2009 11:12:18 -0700

On Sat, Aug 1, 2009 at 6:54 PM, Dave CROCKER<[email-masked]> 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."
>

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.

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

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

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

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.

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

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

---

From: David W Levine <[email-masked]>
Date: Mon, 3 Aug 2009 15:55:44 -0400

[email-masked] wrote on 08/01/2009 12:44:14 AM:

> Morgaine <[email-masked]> 
> Sent by: [email-masked]
>
> One of the best ways of tackling this is to directly ask who it 
> actually applies to.  What kinds of worlds could interoperate through 
OGP?
> 
> This question is often answered in an informal way:  "OGP allows 
> interoperation between SL-like worlds."  That answer is fair enough 
> when given loosely and informally, but it is not good enough for an 
> IETF spec, for obvious reasons.  We may know what we mean, 
> informally, but we need a more objective way of expressing it, so 
> that people without any background in Second Life can still find it 
> precise and informative.
> 
> I would like to propose that a different informal answer is 
> appropriate here, an answer which, while equally simple, is 
> enormously more embracing while still being just as concise and 
> specific and inherently implementable:

> "OGP allows interoperation between any virtual worlds that implement
> the protocol."
> 
> This almost sounds recursive, but it is not:  it makes it clear that
> it doesn't matter how different and divergent the worlds may be, 
> they can still interoperate through OGP as long as they implement 
> that common protocol.  It no longer mentions Second Life.  It does 
> not refer to a totally fictitious unit of "the world".  It does not 
> require interoperating worlds to be clones, either implicitly or 
> explicitly.  It clearly states that the ONLY requirement for interop
> is implementing this one protocol, or suite.
> 
> In other words, it avoids being prescriptive about worlds, and it 
> lets adherence to the protocol define the universe of interop.
> 

> Morgaine.
Please note that the "constraint" language in the charter is about the 
the requirements the specifications address.  If you look at the 
constraint
language in the most recent draft, while it suffers from requiring 
understanding
a lot of terms in the space, it does permit a pretty  easy decision as to 
whether
a requirement is within the remit of the working group. The feedback from 
the 
BOF was not that the constraints are wrong, but that they are hard to 
understand. 

We're looking for edits and new language which can be more readily 
understood, but does not
change the basic nature of the constraints. 

- David Levine
~ Zha Ewry ISL

---

From: Rob Lanphier <[email-masked]>
Date: Tue, 04 Aug 2009 17:31:51 -0700

On 08/01/2009 06:54 PM, Dave CROCKER wrote:
>> 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.

For the claim to be watertight, two different transport mappings would
need to be provided. However, it's still possible to make a meaningful
claim of transport-independence mainly by making sure that:
1. The transport requirements (and non-requirements) are clearly specified
2. Everyone remains vigilant about ensuring that transport expectations
are specified in the requirements

Unless there's a great deal of interest from implementors to implement
some other transport, it seems silly to waste the effort specifying
another transport in the name of making a watertight claim of transport
independence.

Rob

---

From: Mojito Sorbet <[email-masked]>
Date: Tue, 04 Aug 2009 22:03:37 -0400

I observe that the Shoutcast audio streaming service uses HTTP.  They 
initiate the connection with the headers and them leave it open for a 
loooong time sending data packets.  Similarly XMPP sends an XML 
'document' that takes HOURS to send, very slowly, one stanza at a time;  
in fact both ways at once.

With those examples I see no problem in using HTTP(s) headers to 
describe the desired service endpoint (as Dave Crocker pointed out) and 
maybe encoding format, for a connection that stays open for a long 
time.  I do think an exchange of HTTP headers per operation would be 
huge overkill for all but bulk transfers:  textures, sounds, etc.

This meets the needs for both supra-transport addressing and wide 
network reach, without imposing unreasonable end-to-end round-trip 
delays blocking the channel.

Independent services, such as messaging, asset downloading, locality 
information, might even use separate connections, to different 
endpoints, depending how capabilities are managed within a given virtual 
world administrative domain.

-Mo

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

---

From: David W Levine <[email-masked]>
Date: Tue, 4 Aug 2009 23:32:27 -0400

Based on some discussion after the BOF, i want to offer up the following 
to provoke discussion:

Language to be included in the charter, in the properties of the protocol 
section:

* The protocol needs to support the efficient delivery of asynchronous 
update streams between services,
    including, specifically between regions and clients. 
 
* The protocol needs to support the processing of real time user inputs 
and low level state changes As part
   of its work, the working group will characterize the required 
performance, and validate the suitability of
   transports for these needs. 

- David Levine
~ Zha Ewry In Second Life

---

From: Meadhbh Siobhan <[email-masked]>
Date: Wed, 5 Aug 2009 05:00:31 -0700

experience tells us that real time formats and protocol are a
surprisingly small portion of the solution space. also, the term "real
time" is sometimes used to mean a number of different things. we also
don't have a demonstrated need for real time data, only a perceived
need for it.

i would recommend we say that the definition of "real time" behavior
is "in scope" and give ourselves the option of defining real-time
behavior if needed. an example solution might be the use and
definition of RTP payload formats for delivering object updates. but
let's keep it an option at this point.

having performance characteristics for various transactions is a good
idea, but i don't know that we can mandate performance characteristics
of any transport without introducing QoS. our assumptions up to this
point was that the protocol defined messages that signaled state
transitions and that these messages used REST-like request/response
semantics. that is, the client sent the message and was responsible
for receiving the response. if the response did not come in a
"reasonable" amount of time, the client could repeat it. This is why
REST resource accesses are supposed to be idempotent. We did not
attempt to define the definition of "reasonable" but rather gave that
intelligence to the client.

i think we should be very clear that there's a difference between the
desire that information be transmitted in a low-latency manner and the
requirement that a protocol transaction be "real time." RT(C)P is
designed to carry information that if it arrives too late, is useless.
VoIP is the classic example; if a voice packet arrives too late it is
discarded, you can't integrate it back into the voice stream. many
virtual worlds and MMORPGs do not operate in this fashion today.
instead of discarding late packets, the user experience just seems to
freeze for a few moments followed by a rapid application of messages
received.

additionally, real time data can come over TCP or UDP (i would
recommend keeping SCTP as an experimental option for the time being.)
when it comes as UDP, it frequently has to compete with TCP traffic.
as the network approaches its network rate and packets start
disappearing, it's frequently the UDP messages that suffer the most.
ergo, you'll start seeing real time data disappear. if you send it
over TCP, then you get latency induced by recovering from congestion
control.

so.. in short... we should be EXTREMELY certain that this is what we
want to do. we should also be EXTREMELY certain as to which parts of
the protocol should be given a "real time" option. and we should keep
it an option. for example, defining object updates in terms of RTP
would effectively eliminate a web client using XMLHttpRequest() as
it's primary mode of interaction from accessing state change
information. ditto for XMPP clients.

-cheers
-meadhbh

On Tue, Aug 4, 2009 at 8:32 PM, David W Levine<[email-masked]> wrote:
>
> Based on some discussion after the BOF, i want to offer up the following to
> provoke discussion:
>
> * The protocol needs to support the processing of real time user inputs and
> low level state changes As part

---

From: Meadhbh Siobhan <[email-masked]>
Date: Wed, 5 Aug 2009 05:13:23 -0700

On Tue, Aug 4, 2009 at 7:03 PM, Mojito Sorbet<[email-masked]> wrote:
> loooong time sending data packets.  Similarly XMPP sends an XML 'document'
> that takes HOURS to send, very slowly, one stanza at a time;  in fact both
> ways at once.

i think the XMPP people would argue that it's sending event stream
updates using XML stanzas, not complete documents.

also, i think the reason people started streaming over HTTP was to get
through firewalls. i can't imagine that taking real time data, base64
encoding it and putting it on a HTTP transport was their first choice.

though a lesson might be gleaned from the fact that people had to do
these things.

> With those examples I see no problem in using HTTP(s) headers to describe
> the desired service endpoint (as Dave Crocker pointed out) and maybe
> encoding format, for a connection that stays open for a long time.  I do
> think an exchange of HTTP headers per operation would be huge overkill for
> all but bulk transfers:  textures, sounds, etc.

mmm... i would argue exactly the opposite. sending a single texture or
sound in a single HTTP exchange is... well... it's what HTTP was
designed to do, and several ISPs optimize for this use case.

also, the reason we want to use HTTP as a transport has less to do
with it's ability to get through firewalls or to make use of ISP
optimizations, and more to do with the fact that it defines messaging
semantics that are useful. if you look at the second life legacy
protocol, there were several points where we wanted the "fast"
behavior of UDP, but then realized we needed to get message
confirmation. we thus defined request/response semantics using UDP.
this was fine unless one of the request or response packets was
dropped, so we started developing per message rules on retransmitting
messages.

down this path leads insanity.

this is why we like HTTP. it has well defined request/response
semantics. this means that we don't have to redefine the concept of a
request in a custom UDP protocol. it is layered on top of TCP, so if
there's packet loss, an optimized software module in each hosts'
operating system will handle the recovery.

if those features did not exist in any existing protocol, it is likely
we would re-invent them. but, as it turns out, you do get them in HTTP
and you get a mature tool chain and you get the ability to interact
with OGP systems in a web browser.

> This meets the needs for both supra-transport addressing and wide network
> reach, without imposing unreasonable end-to-end round-trip delays blocking
> the channel.

i'm kind of at a loss to understand what "end to end round trip
delays" we're talking about.

> information, might even use separate connections, to different endpoints,
> depending how capabilities are managed within a given virtual world
> administrative domain.
>
> -Mo
>
> Rob Lanphier wrote:
>>

---

From: David W Levine <[email-masked]>
Date: Wed, 5 Aug 2009 14:41:24 -0400

So... Infinity made some very fair points. Lets try this.

For streaming:

I want to take a moment to walk the why... 

So, speaking a bit abstractly... 

When we inject an Avatar into a Region, we model this as a pretty straight 
forward request/response call. The region gets called, accepts the agent's 
avatar information and adds it to the
local state. The region is maintaining and continually updating the state 
of the virtual space it manages. The region needs to push down to the 
client, the current state, and then, incrementally
updates to that state. So, a side effect of entering the region is that 
the region sends its current state, and then begins to stream updates. 
This is, of course, the core business of the region. 

The Legacy Second Life Protocol streams down a series of "object updates" 
which consist of the shapes of things, along with pointers to the textures 
and (in the case of scuplties, the sculpt map) The client then can consult 
its cache, and either fetch these bulky items from the cache, or from the 
Region. 

The current charter doesn't say a lot about the nature of the Client / 
Region relationship. So.. lets try this... 

First, the attributes we want to address:

* Regions hold and manage the "state" of the virtual space they represent. 
They accept agent actions, simulate the region, and send updates to the 
clients who can see their portion of virtual space. 

Then.. in protocol characteristics:

* The specifications will include an asynchronous, region driven set of 
updates which are delivered to clients. The specifications will include a 
balanced blend of notifying clients of updates, over available transports, 
and pulling data from the region as needed. 

For realtime: 

In the attributes of worlds we want to address section:

add:

* Bounded by Latency constraints, are expected to be responsive to simple 
user inputs without queuing delays. This does not mean complex actions 
will be performed in real time, but that the overall specification set 
accepts the requirement that some low level operations happen without 
protocol imposed delays. 

(One wants forward step, turn and such, to be fast, we are NOT mandating 
"Rez 12,000 prim object in 400 mseconds" )

In the protocol characteristics:

* Managing the desired response time goals for low level user inputs may 
require routing some traffic on protocols optimized for low latency use. 
The working group will characterize these goals. The Working group will 
evaluate the suitability of proposed transports in light of these 
characterizations. 

NOTE: these are coupled. The goal is to deliver a near simultaneous 
experience, in which the collective actions of all the present avatars, 
along with scripted objects, physics simulations and other computational 
artifacts are updated in a smooth, continuous fashion. One could easily 
model the set of updates as a resource, which the client "gets" once every 
so often. At the several minute perspective,
this would likely deliver all the needed data. At the user level, it would 
not  permit the client to create a smooth, shared immersive experience. 

- David

---

From: Mojito Sorbet <[email-masked]>
Date: Wed, 05 Aug 2009 19:38:51 -0400

Meadhbh missinterpreted my points.  I did not say that XMPP  is 
transferring multiple documents,  but exactly ONE document, according to 
what the syntax rules of XML are.    There is an opening tag when the 
session opens, and the closing tag is not sent until the session 
closes.  At a syntax level, they are transferring xml stanzas, very 
slowly.  In fact those represent events, but they have the the form of xml.

Similarly we could send an HTTP header, followed by a series of 
<something> (and certainly not base64 coded), and claim to be using an 
HTTP transport.

Also, I specifically said that large objects like textures WERE an 
obvious candidate to send as independent HTTP transfers.  I would do 
that over a separate channel, so as not to tie up the shorter events.

------------------------------------------------------------------------

On Tue, Aug 4, 2009 at 7:03 PM, Mojito Sorbet<mojitotech at gmail.com> wrote:
>> Similarly XMPP sends an XML 'document'

---

From: Morgaine <[email-masked]>
Date: Mon, 17 Aug 2009 13:59:35 +0100

Regarding Joshua's 12 points, I think that Dave Crocker's post below
addresses the issues most clearly so far, so I'll treat that as a base and
fill in some details.  The following brings together the common elements of
points 1, 2, 4, 8 and 9, which are all descriptive and together explain "*what
we're trying to do*".

On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER <[email-masked]> wrote:

Joshua Bell wrote:

You suggested:

This is neither as concise nor as sexy as Chris' summary, but it also lacks
the proprietary reference. I think it also describes the core technical
activity, as I understand the goal.

I think that's fine as an introductory phrase, Dave. While it may not really
explain much, that's OK as long as more detailed explanations follow it.
And sexiness isn't required. :-)  Indeed, the allegedly "sexy" phrase used
at the BoF obscured far more than it illuminated.

One or more people then suggested:

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.

I like the immediate detailing of key features here, as it anchors the topic
very firmly right from the beginning.  However, the choice of words raises
questions rather than building on prior terms and explaining them.  In
particular, let's avoid "placing in a virtual world", since the reader has
no notion of virtual world at this point, only of regions as simulations.
So, let's stick to the aforementioned "regions" and explain the words as we
go, gently sliding in the notion of services, something like this:

"The protocol provides mechanisms for access to regions, each of which is a
virtual area or space implemented through one or more servers.  Access to a
region may involve authentication with an authentication service.  Regions
provide a 3D simulation of a shared environment that may contain avatars (3D
representations of users) and 3D objects of various kinds."

The above starts with "regions", explains what they are in broad physical
terms to aid understanding, and in a short paragraph brings together all the
main elements in the overall picture with the exception of object behaviours
(scripting) and asset services.  We can elaborate on those later, but first
let's build upon the concepts in the preceding paragraph and make clear the
demarcation between regions and clients in our protocol, because it's
fundamental:

"Regions perform spatial or environmental simulation of avatars and 3D
objects, while the graphic rendering of avatars and 3D objects is performed
within users' own client applications, commonly called *viewers*.  This is a
key separation in the protocol, which distinguishes it from other
approaches.  The combination of spatial simulation in regions and graphic
rendering in clients together provides the illusion of shared virtual spaces
that are commonly called *virtual worlds*."

Here at last we've defined what we mean by *virtual world* based on prior
terms.  It's not some kind of mandated conscription of participants into a
global federation (:P), but just a natural consequence of interop:  it
provides a unified visual mashup between graphic elements from various
sources in the user's viewer, driven by the simulation in the region with
added input from the user.  We need to say more about objects though to make
this clear, and crucially, to say what we mean by *interop*:

"The current protocol is an *interoperability* protocol, in other words it
provides communication between end points hosted by more than one party or
organization which provide *services*.  Typical services include identity,
authentication and authorization, region simulation, avatar and/or asset
provision (assets are the components of objects and avatars), and
communication services such as instant messaging."

"While a given organization may choose to implement many or all such
functions itself, the protocol treats all services as decoupled for maximum
flexibility.  For example, a region operated by one provider may be
simulating an environment in which avatars and objects originate from
several different asset providers and are supplied to the user's viewer from
their respective asset services."

And finally, I think it's worthwhile summarizing what this interop protocol
aims to do in respect of all the bits of the puzzle that we have explained
above:

"It is the purpose of the protocol to communicate between the user's client
application and services from diverse providers, in order to deliver the
experience of interoperating virtual worlds to the end user."

Hopefully this kind of progressive explanation can provide the desired level
of readability for the descriptive part of a good charter, while at the same
time mentioning all the required elements and defining what we mean by
interop.

 I've purposely left out object behaviours or scripting as it is a complex
topic and would probably detract from an otherwise easily readable charter.

Putting those snippets together, we get the following description:

"The protocol provides mechanisms for access to regions, each of which is a
virtual area or space implemented through one or more servers.  Access to a
region may involve authentication with an authentication service.  Regions
provide a 3D simulation of a shared environment that may contain avatars (3D
representations of users) and 3D objects of various kinds."

"Regions perform spatial or environmental simulation of avatars and 3D
objects, while the graphic rendering of avatars and 3D objects is performed
within users' own client applications, commonly called *viewers*.  This is a
key separation in the protocol, which distinguishes it from other
approaches.  The combination of spatial simulation in regions and graphic
rendering in clients together provides the illusion of shared virtual spaces
that are commonly called *virtual worlds*."

"The current protocol is an *interoperability* protocol, in other words it
provides communication between end points hosted by more than one party or
organization which provide *services*.  Typical services include identity,
authentication and authorization, region simulation, avatar and/or asset
provision (assets are the components of objects and avatars), and
communication services such as instant messaging."

"While a given organization may choose to implement many or all such
functions itself, the protocol treats all services as decoupled for maximum
flexibility.  For example, a region operated by one provider may be
simulating an environment in which avatars and objects originate from
several different asset providers and are supplied to the user's viewer from
their respective asset services."

"It is the purpose of the protocol to communicate between the user's client
application and services from diverse providers, in order to deliver the
experience of interoperating virtual worlds to the end user."

For the high complexity of what we're trying to achieve, that seems to
combine good coverage and readability, defines interop, and limits the scope
to our particular worlds model.  Comments?

Morgaine.

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

On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER <[email-masked]> wrote:
>> 1. Include a succinct but realistic summary of what the problem space and
protocol are. At the BOF, Chris Newman made the comment "The impression I've
got is this is a 3-D multi-vendor Facebook. I think that's really cool."
(thanks, Chris!). This really helped BOF participants unfamiliar with VWs
understand what the heck we were talking about.
educational, and catchy?
> proprietary reference.  (Perhaps the social networking usage aspect,
however, needs to be included? But then, I'm not clear how the protocol work
mandates that usage.)  I think is also describes the core technical
activity, as I understand the goal.  That presumes that I understand it
correctly...
>
>
>>   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."
deliverables.
> what it will/might/must do with them, nor what the limits on modification
to those documents are -- if any.
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
mechanisms,
>
>
>> Are there any other suggestions, preferences, or vetos? Does the proposed
protocol name need to be reflected in a revised Working Group name?
>> 7. Explicitly list extant drafts which will be the starting point for the
WG effort:
> Since these document represent a substantial history, it really is
important for the charter to cite them explicitly and specify how maleable
their content is. "Starting point" could mean that the final result has no
visible relationship to these documents and that they merely used for
initial discussion. As I've noted earlier, I am pretty sure you folks want
more constraints than that.  Whatever you choose, it's likely to be a point
of negotiation with the IESG, but you should state what role these docs are
expected/required to play.
>> 8. The protocols are intended to provide a clear seperation of concerns
between mechanisms  used to access resources and policies controlling use of
those mechanisms. Many deployment choices will be defined by policy, not
protocol. This needs to be clear in the charter.
>
> 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?
>
> 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.
default transport.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Aug 2009 15:31:23 +0100

>On Sat, Aug 1, 2009 at 6:54 PM, Dave CROCKER<[email-masked]> wrote:
 [even more stuff removed]

>that was actually deployed last summer.
Frequently WG Charters contain a list of documents used as the starting 
point. This helps to emphasize that you are not starting from scratch.

>modification?" discussion again?
>
I don't think we need to have this discussion again, we just need to 
document what you and others said several times.

This is one of the things that both IESG and IAB will be asking about, 
because disagreement on which changes can and can't be done lead to 
failure of multiple WGs that tried to bring in work to IETF.
 [...]

>is used for something other than virtual world simulation?
>
To answer this specific question: unlikely.

>i don't
IESG is frequently looking at charters to verify if WGs produced what 
they promised to produce.
A mismatch between the charter text and end result might be a symptom of 
a trouble.

Of course it doesn't mean that the charter needs to document every 
restriction. The group might not know or might not agree on them before 
starting work.

Does this help?

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 17 Aug 2009 07:40:55 -0700

k. thx for the info. especially the last bit about people comparing
goals and achievements.

On Mon, Aug 17, 2009 at 7:31 AM, Alexey
Melnikov<[email-masked]> wrote:
>> list and at
>> http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Meetings
> because disagreement on which changes can and can't be done lead to failure
> of multiple WGs that tried to bring in work to IETF.
> [...]
>
>>>> out of
>>> any
> IESG is frequently looking at charters to verify if WGs produced what they
> promised to produce.
> A mismatch between the charter text and end result might be a symptom of a
> trouble.
>