Subject: [ogpx] VWRAP still alive?

From: Vaughn Deluca <[email-masked]>
Date: Sun, 29 Nov 2009 14:42:41 +0100

It has gotten terribly silent on the list, and its not hard to see why;
without updates of the drafts the discussion floats free and people are
bound to loose interest.

I  do understand that drafting these types of documents takes time, and too
much discussion in an early stage sometimes only complicates matters, yet, a
quick status update and maybe even a working version of the drafts in their
current form would be nice to keep everybody synchronised...

-Vaughn

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 29 Nov 2009 06:31:50 -0800

yes, VWRAP _is_ still alive.

we're currently working on three documents: LLSD / LLIDL, Intro and
Requirements, and Assets

* LLSD / LLIDL

LLIDL was in the middle of getting a well deserved face lift when
multiple, conflicting changes forced us to return to agreeing on the
problem definition instead of pushing out a draft. LLIDL / LLSD draft
development has been being informed by several pairwise / intense
descussions involving investigation of specific use cases. i hope to
get a wiki page up describing proposed changes at the end of this
week.

but essentially what we're looking at is thus:

- peeps didn't grok why LLSD has the "you get the default value when
you read a map key that's not there" semantics, so i'm integrating the
"structure and interpretation of LLSD messages" email into the draft
as motivation for why LLSD is needed. (
http://www.ietf.org/mail-archive/web/mmox/current/msg00679.html )

- peeps thought the LLIDL syntax was odd, that it didn't look "Cish
enough." i'm developing a proposal for making LLIDL look more like an
ALGOL derived language so C/C++/C#/Java programmers can look at it and
have a more immediate understanding of what it's doing.

- we want to be able to support GETs as well as POSTs when LLSD is
carried over HTTP(S). this is so we an make use of intermediaries like
caching squid servers. so we're working on a way to map a resource
definition to a GET instead of a POST. i know there are some people
who want to carry LLSD over XMPP, so we're interested in avoiding
simply saying... "oh... just make this kind of message a GET" since
that's more of a HTTP(S) specific construction.

- related to the item above, we're looking at ways to encode a request
as a query string. the idea here being that since some caching
intermediaries can cache two GET requests with the same URL, including
the query string, we want to be able to encode the request in the
query string to take advantage of the caching behavior.

- some people thought that the variant syntax was confusing.
specifically, the relationship  between a variant record and the
selector. (the selector is the element _in_ the variant map
declaration that has a literal value.) in other words, the way the
LLIDL parser knows that a particular variant is "valid" is that one of
the members of the map has a specific value. the relationship to the
variant and the selector was considered "haphazard" by some reviewers.

- explaining the use of "late keys." i.e. - the '$' in some LLIDL
definitions. the use of the dollar sign ('$') in LLIDL as the key of a
map declaration indicates that there'll be a number of keys, the
symbol for each is determined at message send time, not at resource
definition time.

- fixing things like broken XML DTDs.

- changing the comment character from a semi-colon (';') to a hash mark ('#')

* Intro and Goals

There was a lot of commentary on the original "intro and requirements"
doc in Stockholm, and a trickle of interest since then. There are a
few minor changes to the draft, and the inclusion of a much better
glossary. David is writing a section on deployment patterns, and we
plan to integrate our changes "any day now."

* Assets

The Assets draft is in a much more "complicated" state. We're
coordinating our efforts with John Hurliman who's the lead developer
on the Cable Beach project. We hope that what will emerge will be a
unified protocol for accessing second life resources as cable beach
resources.

-cheers
-meadhbh

On Sun, Nov 29, 2009 at 5:42 AM, Vaughn Deluca <[email-masked]> wrote:
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

---

From: Morgaine <[email-masked]>
Date: Sun, 29 Nov 2009 16:30:03 +0000

Might I suggest that, instead of working on several documents behind closed
doors, that instead those documents be worked on *one at a time* right here
*in the VWRAP list* where that effort belongs?

That was how we managed to arrive at a group charter in a timely fashion, by
focusing on one thing at a time so that the whole group could contribute
meaningfully to a linear discussion.  The documents are not independent of
each other, so writing a pile of them simultaneously just creates inertia in
the process of change and promotes a desire for rubber-stamping, which isn't
going to happen.

The Intro document req

---

From: Morgaine <[email-masked]>
Date: Sun, 29 Nov 2009 17:06:16 +0000

The preceding reply escaped from Gmail while only half done, please ignore
or delete.  The intended reply will follow.

Morgaine.

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

On Sun, Nov 29, 2009 at 4:30 PM, Morgaine <[email-masked]>wrote:

> doors, that instead those documents be worked on *one at a time* right
> here *in the VWRAP list* where that effort belongs?
>
> That was how we managed to arrive at a group charter in a timely fashion,
> by focusing on one thing at a time so that the whole group could contribute
> On Sun, Nov 29, 2009 at 2:31 PM, Meadhbh Hamrick <
> [email-masked]> wrote:
>

---

From: Morgaine <[email-masked]>
Date: Sun, 29 Nov 2009 17:13:01 +0000

Might I suggest that, instead of working on several documents behind closed
doors, that those documents be worked on *one at a time* right here *in the
VWRAP list* where that effort belongs?

That was how we managed to arrive at a group charter in a timely fashion, by
focusing on one thing at a time so that the whole group could contribute
meaningfully in a linear discussion.  The documents are not independent of
each other, so writing a number of them simultaneously just creates inertia
in the process of change and promotes a desire for rubber-stamping, which
isn't going to happen.

The Intro document requires a very large number of changes as a result of
our removal of "one world" wording from the charter, for consistency and
clarity and to avoid the question of "Which world?" at any given time.

Our protocol is very different now from the early days of OGP.  In effect,
it treats every region domain (and potentially every region) as a separate
world, since they can each have local policies, separate asset services, and
so on --- in other words, there is no longer any single world, which is why
we found an easy basis for agreement in the charter.  The documents need to
reflect that, starting from the Intro.

The right place for coordinating this is VWRAP, so that decisions made in
the name of "coordination" obtain early input from the VWRAP contributors.
That's what we're here for.

In particular, we have already been discussing the operation of multiple
asset services right here with Joshua, so how this might work in conjunction
with Cable Beach is a matter of much interest to us.  There are bound to be
numerous alternative approaches, so I recommend that they be discussed
openly here with a lot of eyeballs on the problem, while ideas are still
fluid.

Morgaine.

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

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 29 Nov 2009 09:39:49 -0800

okay. you go first.

On Sun, Nov 29, 2009 at 9:13 AM, Morgaine
<[email-masked]> wrote:
> doors, that those documents be worked on one at a time right here in the
> VWRAP list where that effort belongs?
>
> On Sun, Nov 29, 2009 at 2:31 PM, Meadhbh Hamrick <[email-masked]>
> wrote:
>
> On Sun, Nov 29, 2009 at 2:31 PM, Meadhbh Hamrick <[email-masked]>
> wrote:
>>

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Sun, 29 Nov 2009 10:11:04 -0800

what issues do you wish to discuss, specifically, morgaine?

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Sun, Nov 29, 2009 at 09:13, Morgaine <[email-masked]>wrote:

> doors, that those documents be worked on *one at a time* right here *in
> the VWRAP list* where that effort belongs?
>

---

From: Carlo Wood <[email-masked]>
Date: Sun, 29 Nov 2009 21:34:34 +0100

> we're currently working on three documents: LLSD / LLIDL, Intro and

Hmm, surprisingly so! Who is "we"?

Although I admire the working spirit and the fact that someone is
actually DOING something(!), in general it seems a bad idea to do
all that work on your own without any feedback / discussion on this
list, since it's the people on this list that will have to agree
with every detail, in fact - even come up with those details in
the first place. This approach might turn out to be very inefficent.

There is a not so small chance that you'd be working out details
of an otherwise flawed design (or at least, where the majority
of team would choose a different/better approach) and you'd just
be wasting time, since it will have to be redone once it's made
public to this list.

Imho, the correct way is to have all ideas posted here on this
list, a little at a time (or per thread; many threads can run
in parallel), so that the people on the team who have to agree
with whatever will be proposed to the IEEE can discuss it.
And only work on details once there is a general consensus on
the road being taken.

-- 
Carlo Wood <[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Sun, 29 Nov 2009 22:19:01 +0000

On the Intro, a good place to start would be to take the document apart
top-down, get agreement on its scope and on what is NOT to be included
because it belongs in more detailed documents, agree on appropriate
sections, and fill them in --- largely from the old OGP material modified as
appropriate, I hope.  (This is how we made good progress on the charter
too.)   Another possibility is to leave the Intro until last, once we know
all the material that it's meant to introduce in overview --- it may be far
too early now because so much is changing.

On the "coordination with Cable Beach", really that should start with John
giving us some idea here of how he sees Cable Beach and VWRAP dovetailing.
Cable Beach was announced  on the MMOX
list<http://www.ietf.org/mail-archive/web/mmox/current/msg01378.html>,
yet we have been told on many occasions that the material on MMOX is
(by
definition) out of scope of OGPX/VWRAP, so there would seem to be some
confusion about MMOX vs OGPX scopes here if we're "coordinating with CB".

Cable Beach was developed independently by John's team at Intel.  An early
version was incorporated into Opensim, and most recently the realXtend
mailing list has mentioned that Cable Beach is evolving to integrate into
realXtend's new system design with its WebDAV-powered inventories, as
I  reported
here earlier<http://www.ietf.org/mail-archive/web/ogpx/current/msg00391.html>.
 This is all extremely interesting and even
*exciting* in the rapid progress it shows, but it does beg the question of
how progress in VWRAP fits in with everyone else's ongoing evolution.  CB is
not any kind of standard after all, it's Work In Progress, and at a rather
early stage of its design, so dependence on it needs to be explained.

Back in September, John
said<http://www.ietf.org/mail-archive/web/ogpx/current/msg00338.html>"
*I can't personally commit any development effort to VWRAP work at this
time, but I will continue to periodically sync Intel's Cable Beach work with
the VWRAP work and aim for a merging of features in the future*".  That
seemed to suggest that CB would follow VWRAP, but it left a lot unsaid.  We
had not even considered multiple asset services and policy-determining
regions back then.  Is it still on track to follow us?  What exactly is the
dependency between our two projects?

Personally I am very happy to see OGP take on in VWRAP a more embracing
concept of interop than its original narrow one, but this does need a lot of
clarification so that we know exactly what we're doing and why, since our
charter was made a narrow one on purpose.  I welcome the new breadth, but we
need to state what we're doing clearly and openly, and explain our new scope
and dependencies.

Morgaine.

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

On Sun, Nov 29, 2009 at 6:11 PM, Infinity Linden (Meadhbh Hamrick) <
[email-masked]> wrote:

>> Might I suggest that, instead of working on several documents behind
>> closed doors, that those documents be worked on *one at a time* right

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sun, 29 Nov 2009 14:38:25 -0800

morgaine.

the scope of this working group is defined in the charter.

if the charter is unclear to you, re-read the discussions on the ogpx
mailing list and the commentary in the stockholm BoF session MP3
archive and the minutes from that meeting.

you do not need my permission (or anyone else's) to take apart the
intro draft point by point. and indeed, this is a place where it is
appropriate to do this. it may be advantageous to you to also take
apart other documents (like david's deployment patterns draft.)

however, i am not waiting for you to take this step. i, and my
co-authors, are working on additional revisions of previous drafts. i,
and my co-authors, have decided that we want to get input from people
who have implemented the LLSD draft and the OGP auth and teleport
drafts before seeking input from people who have not. we feel that
incorporating the experience of people who have implemented previous
revisions of the specifications will lead to a better document.

you may, at any time, comment on your experience implementing and
deploying LLSD related services including the authentication service
and teleport. you may, at any time, without prior approval, comment on
this list your thoughts about the architecture of proposed services
such as the asset service, the trust model, profile services for
avatars, etc. i am interested in your thoughts about deployment
patterns, and they will be reflected in the upcoming intro and goals
draft.

however, in the same way that i do not ask for prior editorial control
of your comments, i ask that you do not ask for editorial control of
my comments and work output. it is a requirement that any document we
produce reflect the consensus of this group. since david and i are the
co-authors of the intro and goals draft, it is our responsibility to
attempt to incorporate everyone's requirements (including yours.)

but i ask that you allow us to produce the document before you criticize it.

-sincerely
-meadhbh hamrick (aka infinity linden)

On Sun, Nov 29, 2009 at 2:19 PM, Morgaine
<[email-masked]> wrote:
> Cable Beach was announced  on the MMOX list , yet we have been told on many
> occasions that the material on MMOX is (by definition) out of scope of
> OGPX/VWRAP, so there would seem to be some confusion about MMOX vs OGPX
> scopes here if we're "coordinating with CB".
>
> realXtend's new system design with its WebDAV-powered inventories, as I
> reported here earlier .  This is all extremely interesting and even exciting
> in the rapid progress it shows, but it does beg the question of how progress
> in VWRAP fits in with everyone else's ongoing evolution.  CB is not any kind
> of standard after all, it's Work In Progress, and at a rather early stage of
> its design, so dependence on it needs to be explained.
>
> Back in September, John said "I can't personally commit any development
> effort to VWRAP work at this time, but I will continue to periodically sync
> Intel's Cable Beach work with the VWRAP work and aim for a merging of
> features in the future".  That seemed to suggest that CB would follow VWRAP,
> but it left a lot unsaid.  We had not even considered multiple asset
> services and policy-determining regions back then.  Is it still on track to
> follow us?  What exactly is the dependency between our two projects?
>
> On Sun, Nov 29, 2009 at 6:11 PM, Infinity Linden (Meadhbh Hamrick)
> <[email-masked]> wrote:
>>
>>> closed doors, that those documents be worked on one at a time right here in
>>> the VWRAP list where that effort belongs?
>>>
>>> Our protocol is very different now from the early days of OGP.  In
>>> effect, it treats every region domain (and potentially every region) as a
>>> separate world, since they can each have local policies, separate asset
>>> services, and so on --- in other words, there is no longer any single world,
>>> which is why we found an easy basis for agreement in the charter.  The
>>> documents need to reflect that, starting from the Intro.
>>>
>>> <[email-masked]> wrote:
>>>
>>> <[email-masked]> wrote:
>>>>

---

From: Morgaine <[email-masked]>
Date: Mon, 30 Nov 2009 03:05:07 +0000

On Sun, Nov 29, 2009 at 10:38 PM, Meadhbh Hamrick <[email-masked]

> archive and the minutes from that meeting.

Is there a need for this kind of response, and a poorly veiled insult about
not understanding the charter that we all put together as a team?

Please refrain from attacking people in this working group, either directly
or indirectly.  It's not professional, it does not advance our work, and we
just don't need it.

Our charter is quite clear, and equally clear is the split that we have
chosen to make between OGPX and MMOX --- indeed, it has been yourself who
has most often used the tactic of dismissing topics as "belonging in MMOX".
The split has been very useful I think, precisely because it narrowed the
scope of OGPX.  When it's broadened again, we need to know why.

The fact that Cable Beach was announced in MMOX and was never a part of OGP
during the two years of our AWG effort makes the question of its place in
VWRAP a real one.  The natural assumption would be that CB is out of scope,
unless stated otherwise.  If it is in scope for VWRAP then let's be clear
about it and describe why this is so.  And let's detail for everyone's
benefit why it is that we are coordinating with a particular group that is
designing a new interop mechanism.  (All kudos to John for doing this, but
CB is being designed in his team and VWRAP participants have no say on its
design, so clearly it's not an integral part of VWRAP and its relationship
to VWRAP is completely unknown.)

My own opinion is that Cable Beach is setting the pace in this area (in
conjunction with realXtend).  In contrast, it is a matter of fact that the
OGP team never publicly released a design for decoupled and distributed
asset sevices of any sort whatsoever.  Therefore I would guess that we are
reaching out to Cable Beach as the only solution on the table at this time.
Is this so?

That's my guess, but other people probably have other guesses.  Well let's
stop guessing and actually state *why* we are coordinating with John's
project, what the dependency with Cable Beach is, and how the VWRAP team is
going to be involved with dovetailing with CB, if that is our future.  The
charter may also have to be amended to reflect this integration with a new
protocol that is not an Internet standard.  In addition, we may also need
new deliverables to describe our interfaces to such external services.

Morgaine.

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

On Sun, Nov 29, 2009 at 10:38 PM, Meadhbh Hamrick <[email-masked]

> >> On Sun, Nov 29, 2009 at 09:13, Morgaine <[email-masked]
> >
> >> wrote:
> >>>
> >>>> - changing the comment character from a semi-colon (';') to a hash
> mark
> >>>> ('#')
> >>>>
> >>>> * Intro and Goals
> >>>>
> >>>> On Sun, Nov 29, 2009 at 5:42 AM, Vaughn Deluca <
> [email-masked]>
> >>>> wrote:
> >>>> > much discussion in an early stage sometimes only complicates
> matters,
> >>>> > yet, a
> >>>> > quick status update and maybe even a working version of the drafts
> in
> >>>> > their