[mmox] My reading of draft-lentczner-ogp-base-00

[Latha Serevi <[e-mail]>]

I'm trying to read all of the MMOX internet-drafts and work out my own
perspective on them, before the meeting.   Perhaps we can do that together.
(I consider myself a neutral participant in MMOX who hopes to see a
WG formed that can build some protocol pieces that we all can use.)

In this installment:  my initial take on OGP Base (Foundation),
 http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt
I would appreciate your thoughts on the document; please keep
this thread strictly for discussion of our understanding of this one
document, and our BRIEF reactions to it.


Summary of section 2, which is where the protocol contributions are.
OGP Base makes use of:  HTTP, REST, LLSD, LLIDL, XML, JSON.
OGP Base defines:  named resources; capabilities; seed capability;
event_queue/get and its flow (which defines a mechanism for streaming
events from an entity to the viewer at the request of the viewer).

Commentary on section 2.  The word "events" seems to be shorthand
for "resource invocations that the entity wants performed on the viewer".
The viewer is a particular kind of protocol endpoint.  I don't see why
this mechanism shouldn't be defined between more general endpoints.
Overall, though, this all seems fairly straightforward and potentially 
useful.


Summary of section 1, which tries to define the overall
structure of the OGP protocol.   Section 1 loosely
defines the terms:  viewer; agent;  virtual world; region.
It introduces the entities "region domain" and "agent domain".
It states that the "basic flow of the protocol" is for a human to
use a viewer to instantiate an agent (via an agent domain)  in
a region (via a region domain), thereby setting up an interaction
where the viewer is streamed object updates from the (authoritative)
region, and the region is streamed avatar update requests from the viewer.


Commentary on section 1.   It seems as though the most common
OGP use case is being defined as the required structure of the protocol.
Is it really required that there MUST be a human in the loop?  The region
is always authoritative?  Requests from the human to the region must
go via the agent domain?

I think there's a strong need for such motivating use cases, but I think
the author shoots himself in the foot by putting it in the first chapter
of the document to which every compliant implementation MUST conform.
Instead, I'd like to see this document use more general definitions and
relate them to use cases defined elsewhere.


Please help me understand what I've missed and where I'm off base.


Latha Serevi (SL)