Subject: [vwrap] Conditioners and refineries

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 19:34:20 -0700

If we say the conditioner basically authenticates or re-signs an asset 
from grid X to grid Y, and the refinery would make sure the physics of 
the object described by the asset is translated from the topology of 
grid X to the topology of grid Y, then this is basically what COLLADA 
expects in exchange. This exchange is this different from the usual 
import/export process. It doesn't have to be this exact process, as this 
is only an example to us be more familiar.

It seems a complete waste to not realize that LL has implemented the 
import process and physics refinery into their browser, and this very 
feature, though not fully automated as such, could be used to help move 
assets in-between grids/v-worlds. Since the import is from local basis, 
the authentication is not implemented. What's to stop to basically 
export to DAE format on the local storage, from one world, and continue 
to import that DAE into another grid.

Note that the refineries may be proprietary. They may produce 
non-COLLADA formats (from DAE files) that are for optimal render/display 
capability of the software "client" (i.e. that the end-user has to view 
graphics).

As with Google Earth and Sony HOME, they already have their assets 
conditioned and refined for those virtual worlds such that they can 
optimally display them. The key note is not the optimal display, as it 
is about being able to exchange and use in other virtual worlds.

The DAE format does have extensive abilities, yet the goal of COLLADA is 
still to define the basic material, scripts, model, etc in the most 
portable format. The DAE may contain hybrid or specific formats that is 
stored in the extensions, so that custom objects are retained/transferred.

If virtual worlds start to not agree upon how they store objects, I see 
COLLADA as the default format for digital asset exchange.

https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F

(Yes, we can put all inventory items in DAE format through the user-data 
and asset extensions, despite the format mainly being for 3D... just sayin')

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 04:42:36 +0100

We've maintained throughout that our protocols would be extensible with
regard to data formats, allowing worlds and user expectations to evolve
without requiring protocol redefinition.

In the area of meshes, it is very much to be expected that COLLADA will
figure strongly among the graphic formats used (particularly since it was
chosen for the iED initiative), but it's not of any special interest to the
VWRAP protocols other than as a potential content type.  All we have to do
is to make sure that we label each transfer with its appropriate type, and
possibly also include other metadata that may be needed.

We're certainly not standardizing what graphics are used in virtual worlds,
beyond assigning types where they might not yet exist.  Hardwiring them
would be a recipe not for extensibility but for stagnation.  Other bodies
may be standardizing which graphics formats are used, whereas we're trying
to define useful deployment architectures and standardizing the protocols
through which they are accessed.

Morgaine.

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

On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol <[email-masked]> wrote:

> If we say the conditioner basically authenticates or re-signs an asset from
> grid X to grid Y, and the refinery would make sure the physics of the object
> described by the asset is translated from the topology of grid X to the
> topology of grid Y, then this is basically what COLLADA expects in exchange.
> This exchange is this different from the usual import/export process. It
> doesn't have to be this exact process, as this is only an example to us be
> more familiar.
>
> It seems a complete waste to not realize that LL has implemented the import
> process and physics refinery into their browser, and this very feature,
> though not fully automated as such, could be used to help move assets
> in-between grids/v-worlds. Since the import is from local basis, the
> authentication is not implemented. What's to stop to basically export to DAE
> format on the local storage, from one world, and continue to import that DAE
> into another grid.
>
> Note that the refineries may be proprietary. They may produce non-COLLADA
> formats (from DAE files) that are for optimal render/display capability of
> the software "client" (i.e. that the end-user has to view graphics).
>
> optimally display them. The key note is not the optimal display, as it is
> about being able to exchange and use in other virtual worlds.
>
> still to define the basic material, scripts, model, etc in the most portable
> format. The DAE may contain hybrid or specific formats that is stored in the
> extensions, so that custom objects are retained/transferred.
>
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 31 Mar 2011 08:21:31 -0700

Don't need to assume too much like that, Morgaine; however, we need 
something more of "trust domains" defined and the example(s) I wrote 
about fit in well as lead-in. I stated these use-cases specially to 
avoid the use of terminology that now exists, and this leans towards the 
need to center on "trust domains." I see the use of current 
client/server-* terminology continually to confuse us (even if some like 
it, not all do). If we have to think about such terminology for more 
than 90 seconds each time then it needs to change.

My side-point was that VWs may have their own object format in their 
world, and I'm thinking more then just the regions that exist now that 
the monolithic client connects. Perhaps, others only think about SL 
compatible grids, and don't worry about the default format.

Morgaine wrote:
> We've maintained throughout that our protocols would be extensible 
> with regard to data formats, allowing worlds and user expectations to 
> evolve without requiring protocol redefinition.
>
> In the area of meshes, it is very much to be expected that COLLADA 
> will figure strongly among the graphic formats used (particularly 
> since it was chosen for the iED initiative), but it's not of any 
> special interest to the VWRAP protocols other than as a potential 
> content type.� All we have to do is to make sure that we label each 
> transfer with its appropriate type, and possibly also include other 
> metadata that may be needed.
>
> We're certainly not standardizing what graphics are used in virtual 
> worlds, beyond assigning types where they might not yet exist.� 
> Hardwiring them would be a recipe not for extensibility but for 
> stagnation.� Other bodies may be standardizing which graphics formats 
> are used, whereas we're trying to define useful deployment 
> architectures and standardizing the protocols through which they are 
> accessed.
>
>
> Morgaine.
>
>
>
>
> ===================
>
> On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     If we say the conditioner basically authenticates or re-signs an
>     asset from grid X to grid Y, and the refinery would make sure the
>     physics of the object described by the asset is translated from
>     the topology of grid X to the topology of grid Y, then this is
>     basically what COLLADA expects in exchange. This exchange is this
>     different from the usual import/export process. It doesn't have to
>     be this exact process, as this is only an example to us be more
>     familiar.
>
>     It seems a complete waste to not realize that LL has implemented
>     the import process and physics refinery into their browser, and
>     this very feature, though not fully automated as such, could be
>     used to help move assets in-between grids/v-worlds. Since the
>     import is from local basis, the authentication is not implemented.
>     What's to stop to basically export to DAE format on the local
>     storage, from one world, and continue to import that DAE into
>     another grid.
>
>     non-COLLADA formats (from DAE files) that are for optimal
>     render/display capability of the software "client" (i.e. that the
>     end-user has to view graphics).
>
>     conditioned and refined for those virtual worlds such that they
>     can optimally display them. The key note is not the optimal
>     display, as it is about being able to exchange and use in other
>     virtual worlds.
>
>     The DAE format does have extensive abilities, yet the goal of
>     COLLADA is still to define the basic material, scripts, model, etc
>     in the most portable format. The DAE may contain hybrid or
>     specific formats that is stored in the extensions, so that custom
>     objects are retained/transferred.
>
>     If virtual worlds start to not agree upon how they store objects,
>     I see COLLADA as the default format for digital asset exchange.
>
>     (Yes, we can put all inventory items in DAE format through the
>     user-data and asset extensions, despite the format mainly being
>     for 3D... just sayin')
>
>     -- 
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

--

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 17:23:00 +0100

There is no default format, and nowhere does VWRAP deal in SL-compatible
grids.

We are defining a services-oriented architecture which is nothing like that
of today's SL, and we cannot for a moment assume that SL will adopt it in
the future, as that is their choice, not ours.

The only partly-compatible VW frameworks over which we have a small amount
of influence are Opensim and realXtend (which uses Opensim server-side),
because we can take their open source code and adapt it to our protocols if
we wish.  In that sense, we could be said to be defining an
Opensim-compatible protocol, but never an SL-compatible protocol.  That
would be a misapprehension.

We occasionally say that we are defining an SL-like *data* architecture, but
even that isn't really correct since VWRAP doesn't favor one in-world
content type over another.  All content types are denoted merely by a type
tag and there is no standard set of content types required.

So what is the real commonality between VWRAP and SL?  Currently, only LLSD
is reasonably compatible with SL, although LLSD might well change in more
than just its name if we find the current spec not sufficiently powerful or
lacking extensibility for our needs.

Morgaine.

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

On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol <[email-masked]> wrote:

> something more of "trust domains" defined and the example(s) I wrote about
> fit in well as lead-in. I stated these use-cases specially to avoid the use
> of terminology that now exists, and this leans towards the need to center on
> "trust domains." I see the use of current client/server-* terminology
> continually to confuse us (even if some like it, not all do). If we have to
> think about such terminology for more than 90 seconds each time then it
> needs to change.
>
> My side-point was that VWs may have their own object format in their world,
> and I'm thinking more then just the regions that exist now that the
> monolithic client connects. Perhaps, others only think about SL compatible
> grids, and don't worry about the default format.
>
> Morgaine wrote:
>
>> VWRAP protocols other than as a potential content type.� All we have to do
>> worlds, beyond assigning types where they might not yet exist.� Hardwiring
>> them would be a recipe not for extensibility but for stagnation.� Other
>> bodies may be standardizing which graphics formats are used, whereas we're
>> trying to define useful deployment architectures and standardizing the
>> protocols through which they are accessed.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> ===================
>>
>> On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>
>>    --     --- https://twitter.com/Dzonatas_Sol ---

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 31 Mar 2011 09:55:11 -0700

Added "trust domains" to the subject line to hopefully narrow this 
thread before it goes into some random debate.

At the source level, in the (voted upon?) client/server roles, who is 
the trust domain? If user A connect to asset server B, and B connects to 
grid X and grid Y, is the trust domain B, X, and Y, or just B and 
whatever A determines? I don't think there is any determinate 
client/server role here.

Being able to export/import objects with given "trust domain" is 
obviously either going to be "local only" or maybe combination of above 
A, B, X, Y. Should we simply establish trust domains based upon sign-in 
capabilities keep it simple to PGP/GPG keys. I think the URI/GPG-key is 
the simpler way for non-local assets, yet to be proven.

Do consider more complex assets that are "manufactured", and may contain 
encrypted assets within asset bundles in order to move objects between 
regions/v-worlds. The current SL(-compatible) protocols don't seem to 
handle bundles. What-if an asset is made for grid X and bundled with 
another asset for export/import. If grid Y cannot establish any "trust 
domain" with grid X then where should the export/import fail?

Yes, I'm thinking ahead... but the "manufactured" use-case is old (and 
by Morgaine's keeps being set aside to argue other "misapprehensions"). 
The manufactured use-case may get as complex as materials from many 
different grids in order to put together one object. Then we'll have to 
consider if that object requires a predefine trust domain in order to 
interop at various levels.

Let me also include this (un-rephrased from other email): Does "service 
level interop" include anything about "region-crossing"? If it does not, 
then we surely can then partition capabilities into different 
client/server clusters. If people want more seamless movement while in 
"service level interop" then mabye that needs to be upgraded to 
the"region-crossing" level.

When is interop from grid X to grid Y seamless, when do assets need to 
be conditioned (keep "trust domains" in mind), and when do objects need 
to be refined? To continue to use client/server terminology in that 
question is just to complex (or confuses the discussion into further 
endless debate).

Morgaine wrote:
> There is no default format, and nowhere does VWRAP deal in 
> SL-compatible grids.
>
> We are defining a services-oriented architecture which is nothing like 
> that of today's SL, and we cannot for a moment assume that SL will 
> adopt it in the future, as that is their choice, not ours.
>
> The only partly-compatible VW frameworks over which we have a small 
> amount of influence are Opensim and realXtend (which uses Opensim 
> server-side), because we can take their open source code and adapt it 
> to our protocols if we wish.  In that sense, we could be said to be 
> defining an Opensim-compatible protocol, but never an SL-compatible 
> protocol.  That would be a misapprehension.
>
> We occasionally say that we are defining an SL-like /*data*/ 
> architecture, but even that isn't really correct since VWRAP doesn't 
> favor one in-world content type over another.  All content types are 
> denoted merely by a type tag and there is no standard set of content 
> types required.
>
> So what is the real commonality between VWRAP and SL?  Currently, only 
> LLSD is reasonably compatible with SL, although LLSD might well change 
> in more than just its name if we find the current spec not 
> sufficiently powerful or lacking extensibility for our needs.
>
>
> Morgaine.
>
>
>
>
> On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol <[email-masked] 
>     Don't need to assume too much like that, Morgaine; however, we
>     need something more of "trust domains" defined and the example(s)
>     I wrote about fit in well as lead-in. I stated these use-cases
>     specially to avoid the use of terminology that now exists, and
>     this leans towards the need to center on "trust domains." I see
>     the use of current client/server-* terminology continually to
>     confuse us (even if some like it, not all do). If we have to think
>     about such terminology for more than 90 seconds each time then it
>     needs to change.
>
>     My side-point was that VWs may have their own object format in
>     their world, and I'm thinking more then just the regions that
>     exist now that the monolithic client connects. Perhaps, others
>     only think about SL compatible grids, and don't worry about the
>     default format.
>
>     Morgaine wrote:
>
>         We've maintained throughout that our protocols would be
>         extensible with regard to data formats, allowing worlds and
>         user expectations to evolve without requiring protocol
>         redefinition.
>
>         In the area of meshes, it is very much to be expected that
>         COLLADA will figure strongly among the graphic formats used
>         (particularly since it was chosen for the iED initiative), but
>         it's not of any special interest to the VWRAP protocols other
>         than as a potential content type.� All we have to do is to
>         make sure that we label each transfer with its appropriate
>         type, and possibly also include other metadata that may be needed.
>
>         We're certainly not standardizing what graphics are used in
>         virtual worlds, beyond assigning types where they might not
>         yet exist.� Hardwiring them would be a recipe not for
>         extensibility but for stagnation.� Other bodies may be
>         standardizing which graphics formats are used, whereas we're
>         trying to define useful deployment architectures and
>         standardizing the protocols through which they are accessed.
>
>
>         Morgaine.
>
>
>
>
>         ===================
>
>         On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

--

---

From: Mike Dickson <[email-masked]>
Date: Thu, 31 Mar 2011 13:19:23 -0400

> There is no default format, and nowhere does VWRAP deal in

That's actually for the contributors to define.  There's no reason we
can't choose to favor a direction that's compatible or at least
complimentary with existing practice.

> adopt it in the future, as that is their choice, not ours.

You have a tendency to use "we" as this inclusive, everyone agrees with
me so its a done deal concept.  Again wether the group chooses to
leverage some of the concepts in SL (like LLSD for instance) is still
open to discussion.  And protocol standard are what "we" are about here.
Honestly if we fail to produce something that can "inter-operate" with
SL at least to some degree I think the usefulness is minimal.

> protocol.  That would be a misapprehension.

This is all about implementation and isn't related to standards work at
all.  How what is produced here is implemented into a "product" (open
source or not) is irrelevant. And again, wether the protocol is
"SL-compatible" is open to discussion.  You clearly have a bias away
from it but its not clear that's true for everyone.

> 
> We occasionally say that we are defining an SL-like data architecture,
> but even that isn't really correct since VWRAP doesn't favor one
> in-world content type over another.  All content types are denoted
> merely by a type tag and there is no standard set of content types
> required.
> 

Again, your making assumptions based on what you'd like to see.  If you
really feel as strongly as you do that an alternative is appropriate I'd
get to drafting some documents that describe it.  Otherwise IMO,
standardizing around existing current practice is completely reasonable
and appropriate.  Not that there isn't room for improvement of course.
But those improvements can be incremental in nature rather than
revolutionary.

Mike

>         need something more of "trust domains" defined and the
>         example(s) I wrote about fit in well as lead-in. I stated
>         these use-cases specially to avoid the use of terminology that
>         now exists, and this leans towards the need to center on
>         "trust domains." I see the use of current client/server-*
>         terminology continually to confuse us (even if some like it,
>         not all do). If we have to think about such terminology for
>         more than 90 seconds each time then it needs to change.
>         
>         only think about SL compatible grids, and don't worry about
>         the default format.
>         
>         Morgaine wrote:
>                 We've maintained throughout that our protocols would
>                 be extensible with regard to data formats, allowing
>                 worlds and user expectations to evolve without
>                 requiring protocol redefinition.
>                 
>                 In the area of meshes, it is very much to be expected
>                 that COLLADA will figure strongly among the graphic
>                 formats used (particularly since it was chosen for the
>                 iED initiative), but it's not of any special interest
>                 to the VWRAP protocols other than as a potential
>                 content type.� All we have to do is to make sure that
>                 we label each transfer with its appropriate type, and
>                 We're certainly not standardizing what graphics are
>                 used in virtual worlds, beyond assigning types where
>                 they might not yet exist.� Hardwiring them would be a
>                 recipe not for extensibility but for stagnation.�
>                 Other bodies may be standardizing which graphics
>                 formats are used, whereas we're trying to define
>                 useful deployment architectures and standardizing the
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 22:51:31 +0100

> SL at least to some degree I think the usefulness is minimal.

Mike, in the post you quoted, I made no reference to what I personally would
like to see.  When I've used the word "we" and suggested that "we" hold some
view, it is because the participants of THIS GROUP have expressed similar
ideas in sufficient numbers for it to be an approximate majority view, and
often (but not always) unanimous.  If the "we" does not include yourself, it
is because you were either not participating at the time, or because you
were in the minority on the topic at the time.

A default content format has never even been *mentioned* here until
Dzonatas' recent post, so when I wrote "There is no default format" it was a
wholly accurate statement up to this point in time, and not just my
opinion.  And while we cannot foretell the future, that statement will
continue to be accurate until such a time as we've discussed the issue and
decided that there will be a default format.  In the interim, the fact that
there is no default format specified, agreed, or even discussed in VWRAP,
stands, regardless of whether you or I would wish it otherwise personally.

With regard to our relationship with SL, I don't think I need to explain
further the fact that we are not defining Linden Lab's future architecture,
protocols, nor service concepts for them.  We don't have that power, and
they are under no obligation to take any notice of what we do, particularly
now that they have officially withdrawn from the table.  At best we can hope
that our protocols are good enough and flexible enough that a subset of them
is useful for a proprietary service like Second Life.

Our work is not being undertaken for their benefit however, but to serve the
needs of the entire Internet community as per our mandate under the *IETF
Mission Statement*.  If Linden Lab can benefit as well then we have done a
good job.

I hope that you are not disagreeing that "we are defining a
services-oriented architecture", so I'm not sure why you cited that
sentence.  Having witnessed all the discussions since the start of AWG and
OGP and MMOX all the way through to VWRAP, I believe that we are completely
unanimous that that is exactly what we are doing, so the "we" was, again,
accurate.  If you don't think that we should be defining a services-oriented
architecture, I have yet to read any objections in that regard.

> from it but its not clear that's true for everyone.

That is incorrect.  IETF drafts are not promoted to Internet standards
unless they have implementations --- again, the Mission Statement is worth
reading.  "*Rough consensus and running code*" is a cardinal principle
highlighted in BCP 95.  Since we do not have the power to test our ideas
within Second Life, but only within open source frameworks like Opensim, SL
compatibility is beyond our reach until such a time as Linden Lab provides
the required test implementation.  In the absence of that, only Opensim
and/or realXtend compatibility is within our grasp because we can add the
"running code" there ourselves.

(Adding VWRAP protocol code to other open source VW frameworks such as
OpenWonderland, OpenCobalt, or Sirikata is potentially within our grasp as
well, but would require much more work and knowledge of those systems.)

> But those improvements can be incremental in nature rather than

What you refer to as my "assumptions" are nothing more than rather obvious
observations which have never been a matter of disagreement here.  Our
target for VWRAP testing is Opensim because, as I already explained, the SL
platform is outside of our control.  Indeed, Linden Lab has probably
disclaimed more than once any unwarranted expectation that they undertake to
implement VWRAP concepts, so it would be quite odd for us to insist that we
are designing a protocol that will be compatible with a new generation of
SL.

That is not something which we can claim, nor work towards.  The most we can
do is design a flexible protocol usable in many different deployments
(including commercial services), and hope that Linden Lab decides to adopt
it.  Much more important though is that our protocols serve the much broader
Internet community well, and that goes far beyond the needs of one
commercial provider.  That is a duty which we have undertaken by being
members of this IETF working group.

Morgaine.

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