Re: [vwrap] one question

vwrap-bounces@ietf.org wrote on 09/24/2010 11:12:53 AM:

> From:
>
> Cristina Videira Lopes <lopes@ics.uci.edu>
>
> To:
>
> Meadhbh Hamrick <ohmeadhbh@gmail.com>
>
> Cc:
>
> vwrap@ietf.org
>
> Date:
>
> 09/24/2010 11:13 AM
>
> Subject:
>
> Re: [vwrap] one question
>
> Sent by:
>
> vwrap-bounces@ietf.org
>
> Let me go back to my original comments by reposting my original
> question: "Is VWRAP set up to develop protocols for interoperability
> between virtual worlds that, like these ones, use the web browser as the
> client?" John and Jonathan answered yes. Morgaine, Meadhbh and David
> gave ambiguous answers somewhere between yes and no.
>

I don't think my answer was even slightly ambiguous. I'll quote it:

"A web based client is just another client. If it is rich enough to accept
the content and render it effectively, its a client. I don't think anyone
would say otherwise"

But if that wasn't clear enough. Yes,  the intent is to cover VWs which use
web browsers as clients.
We will ignore that "Web browsers" is itself deeply ambiguous and imprecise
and assume
reasonably capable web browsers.

> The answer to this question cannot be ambiguous, for the following
reason.
>
> It has been stated here countless times that the goal of these standards
> is to define "mechanism, not policy". The current instantiation of
> VWRAP, as described in the drafts, goes deep into the realm of policy
> when a web browser is involved, as it prescribes that (a) the login
> procedure results in a seed capability sent to the client, which then
> invokes it to get more capabilities; and (b) assets are pulled by
> clients. Were these fundamental for interoperability of VWs on the Web,
> then we wouldn't have an option but to accept them. But they aren't.
> They are policies -- possible implementation options.

I think you are confusing the meanings of the words Policy and Mechanism.

The way those two phrases have been used in VWRAP is that A mechanism is
how
you do something. A policy is deciding when to use various mechanisms.

>
> I understand that for a client with a fixed viewer the situation is
> different: the viewer component doesn't change, so, for a fixed family
> of virtual worlds, we need to devise one single mechanism governing the
> client, the server, and the access to resources. But the Web is exactly
> this: hypermedia that includes programs.
>
> Hence my original review comment: you need to come clear with the
> specification of the client.
>
> It's ok to say that VWRAP is thought for clients with fixed viewers, and
> that clients with variable viewers -- like the web browser -- may want
> to follow these mechanisms because they are sensible, but they don't
> have to.

The capability and seed cap approach is a mechanism for securing access
to distributed resources in the internet based on REST with an interesting
mix of security, delegation and indirection features. The intent is to be
relatively client independent. There has been a rich discussion about
how to include caps to different transports, as well as how to grant caps
in interesting ways. I can imagine a good discussion on how to deal
with clients which have native websocket support.
>
> It's not ok to mislead readers of these documents into thinking that VW
> interoperability on the Web MUST follow the mechanisms prescribed here
> (as they are now).
>
This is a strawman in classic form. VWRAP proposes to solve a set of real
and useful interopability problems. Nobody has stated that it solves all
VW interoperability issues, and that ANYONE has to use it for any purpose
at all.

> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap

- David
~ Zha