Re: [vwrap] Why are we standardizing the login handshake? (was RE: one question)

["Hurliman, John" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Crista Lopes
> Sent: Friday, September 24, 2010 3:41 PM
> To: [e-mail]
> Subject: Re: [vwrap] Why are we standardizing the login handshake? (was
> RE: one question)
> 
> On 9/24/2010 3:36 PM, Hurliman, John wrote:
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Crista Lopes
> >> Sent: Friday, September 24, 2010 3:16 PM
> >> To: [e-mail]
> >> Subject: Re: [vwrap] Why are we standardizing the login handshake?
> >> (was
> >> RE: one question)
> >>
> >> On 9/24/2010 3:11 PM, Hurliman, John wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of Crista Lopes
> >>>> Sent: Friday, September 24, 2010 3:07 PM
> >>>> To: [e-mail]
> >>>> Subject: Re: [vwrap] Why are we standardizing the login handshake?
> >>>> (was
> >>>> RE: one question)
> >>>>
> >>>> John,
> >>>>
> >>>> You may also want to read the intro draft.
> >>>> http://tools.ietf.org/html/draft-ietf-vwrap-intro-00
> >>>>
> >>>> This is in 4.4:
> >>>>
> >>>> "VWRAP defines formats  for describing objects and avatar shapes,
> >>>> but more importantly it
> >>>>       describes the mechanism by which those digital asset descriptions
> are
> >>>>       transferred between client applications, agent domains and region
> >>>>       domains."
> >>>> ...
> >>>> "Accessing and manipulating digital assets is  performed via
> >>>> capabilities which expose the state of the asset to an authorized client.
> "
> >>>>
> >>>> In other words, assets are fetched by the client. So if my world
> >>>> pushes them to the client, it's not VWRAP-compliant.
> >>>>
> >>>>
> >>>>
> >>> You keep saying "if my world does X, it's not VWRAP-compliant".
> >>> That's not
> >>>
> >> correct. "If my world does not have service endpoint X, it's not
> >> VWRAP- compliant" is the correct statement here. Your world can send
> >> assets to your client in any way it wishes, but if your asset service
> >> does not expose a VWRAP asset fetch capability (regardless of whether
> >> your own client uses it or not) then it is not VWRAP-compliant.
> >>
> >>>
> >> So what exactly does this mean? (especially the 2nd sentence, the 1st
> >> is just for context of the word "client")
> >>
> >>
> > Let's say I have a blog running Wordpress. The default way to leave
> comments on the blog is to create an account, confirm the e-mail activation,
> login, then leave a comment. Wordpress is doing a non-standard login
> (equivalent to "if my world does X"), which makes it neither compliant with
> OpenID nor non-compliant with OpenID. It is completely orthogonal.
> >
> > Now I install an OpenID plugin for Wordpress that allows people to either
> use the traditional method, or use OpenID authentication when leaving
> comments. I've added a service endpoint for accepting OpenID
> authentication, and my blog is now OpenID compliant.
> >
> > Pushing assets to your client does not make your world non-compliant with
> VWRAP. Being compliant with VWRAP depends on whether you also have a
> service endpoint that speaks the VWRAP language, in addition to whatever
> else your system might be doing.
> >
> 
> So why is this prescription in the intro document at all?
>   "Accessing and manipulating digital assets is  performed via capabilities
> which
>   expose the state of the asset to an authorized client. " (where client means
> the client application, in the context of that section)
> 

As Morgaine said, the intro doc is in desperate need of a rewrite. But in this specific case I don't see the conflict. I read that as:

"If my client is trying to fetch an asset from a foreign asset service or save an asset to a foreign asset service, where I don't have the luxury of using my optimized non-standard protocol and will be using the VWRAP interop protocol, then my client will be doing that using one or more HTTP capabilities with carefully crafted protocols."

HyperGrid uses this same model, except assets are only fetched server to server instead of directly from the client. When a foreign user is in a grid, there are a set of capabilities (service URLs in HG terminology) attached to that presence and there is an implicitly defined protocol about how you use the asset service URL to fetch a remote asset.