Subject: [ogpx] Greetings from the Area Director sponsoring the OGPX BOF

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Jun 2009 20:12:02 +0100

Greetings,
As you already heard from Meadhbh, the OGPX BOF in Stockholm was approved.
I am quite excited about this and I very much hope that it goes well, so 
that a new Working Group can be formed after Stockholm.

I will be announcing the BOF chairs soon. I trust them to make sure that 
the BOF is a success.

In the meantime, as the sponsoring AD I would appreciate some discussion 
on the mailing list about the proposed charter. Comments about what is 
missing or should be removed, wrong, etc. would be greatly appreciated.

Regards,
Alexey

/**/

---

From: David W Levine <[email-masked]>
Date: Wed, 24 Jun 2009 13:06:33 -0400

This is an informal draft intended to drive some feedback and discussion. 
The content follows the discussion a week ago, in SL at the weekly 
AWGroupies meeting. Feedback is welcome, and encouraged, here, and at next 
week's AWGroupy meeting. For those who do not follow the weekly 
discussions, they are held in world, on Second Life Contact Zha Ewry (me) 
or Saijanai Kuhn in world for an invite. The AWGroupies meet Tuesday 
mornings at 9:30 AM Pacific time, in second life. For those who do not 
routinely use second life, a free account is available, details at the 
Linden Lab web site: http://secondlife.com/   I expect the next iteration 
of the document to be posted as an IETF input for discussion at IETF75 in 
Stockholm. 

- David Levine
~ Zha Ewry  (In Second Life)

---

From: Joshua Bell <[email-masked]>
Date: Thu, 25 Jun 2009 09:54:55 -0700

Still digesting, but some quick feedback:

* Re: the eventq(s) schemes - am I correct in my interpretation that 
these URIs would not be exposed outside of a single (agent, region) 
domain? If so, would these be considered a "best 
practice"/"implementation detail" rather than something normative? (The 
document is clearly discussing patterns so it's within scope for the 
document.) If not, then I'm misinterpreting something.

* For *examples* in documents, could we informally standardize on using 
JSON serialization of LLSD rather than the XML serialization? I realize 
that XML is more expressive (e.g. you can distinguish strings vs. UUIDs) 
but JSON is more compact and it avoids having non-LLSD-savvy XML-centric 
users readers from gagging at the seemingly crazy implied schema. 
(Formal interface specifications should use LLIDL.)

David W Levine wrote:
>
> This is an informal draft intended to drive some feedback and 
> discussion. The content follows the discussion a week ago, in SL at 
> the weekly AWGroupies meeting. Feedback is welcome, and encouraged, 
> here, and at next week's AWGroupy meeting. For those who do not follow 
> the weekly discussions, they are held in world, on Second Life Contact 
> Zha Ewry (me) or Saijanai Kuhn in world for an invite. The AWGroupies 
> meet Tuesday mornings at 9:30 AM Pacific time, in second life. For 
> those who do not routinely use second life, a free account is 
> available, details at the Linden Lab web site: 
> _http://secondlife.com/_   I expect the next iteration of the document 
> to be posted as an IETF input for discussion at IETF75 in Stockholm.
>
>
>
>
>
> - David Levine
> ------------------------------------------------------------------------
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx

---

From: Infinity Linden <[email-masked]>
Date: Thu, 25 Jun 2009 11:13:29 -0700

i think the idea is that there might be a trust relationship between
two domains (where a domain is a collection of machines administered
by a distinct entity) where the first domain provides an event queue
to a client and the second domain has need to send a message to the
client. the event queue uri scheme provides an addressing mechanism
for the first domain to identify the client-server connection to the
second domain.

trust is an important part of this equation, but is addressed in the
URI scheme only to the degree you can select an eq: or eqs: scheme
(the latter indicating the mandatory use of TLS.) david and i are
working on the PKIX profile for inter-domain trust, so we expect
service consumers and providers who are in different domains to
implement a security policy in line with their own security
requirements. for instance, a large public grid operator might require
all incoming event queue requests to be made via TLS with a trusted
client certificate while small experimental grids might be promiscuous
when honoring connection requests.

the utility of this scheme is more apparent when we consider client
side capabilities. in some cases, it is useful for a client
application to generate a capability and pass it to the domain host
managing an event queue. the domain host may then pass this capability
off to a third party for processing. the advantage is we can avoid the
confused deputy problem while supporting flexible deployment. (i.e. -
we can use this to build an ecosystem of service providers that rely
on client capabilities.)

so yeah. we think it's good for it to be normative. that being said,
if your service doesn't use it and won't honor requests, then you may
choose not to deploy code that supports it.

with respect to JSON vs. XML, i have no personal preference per se.
however, if XML examples lead people to believe we're using a fixed
XML schema, then JSON examples may lead other people to believe our
system is stock 4627 JSON, which it isn't. maybe both?

On Thu, Jun 25, 2009 at 9:54 AM, Joshua Bell<[email-masked]> wrote:
> * Re: the eventq(s) schemes - am I correct in my interpretation that these
> URIs would not be exposed outside of a single (agent, region) domain? If so,
> would these be considered a "best practice"/"implementation detail" rather
> than something normative? (The document is clearly discussing patterns so
> it's within scope for the document.) If not, then I'm misinterpreting
> something.
>
> * For *examples* in documents, could we informally standardize on using JSON
> serialization of LLSD rather than the XML serialization? I realize that XML
> is more expressive (e.g. you can distinguish strings vs. UUIDs) but JSON is
> more compact and it avoids having non-LLSD-savvy XML-centric users readers
> from gagging at the seemingly crazy implied schema. (Formal interface
> specifications should use LLIDL.)
>
>

[stuff removed]

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 25 Jun 2009 13:07:18 -0600

In what ways is the JSON that is created when serializing LLSD messages not compatible with RFC 4627?

John

---

From: Infinity Linden <[email-masked]>
Date: Thu, 25 Jun 2009 12:06:05 -0700

and some nits...

in requirements, item 2, were we going to add the use case of the
client application having a routable IP address and responding to HTTP
requests directly? i think we talked about it and we (Linden) figured
we would probably rarely see such a use case, but you (IBM) thought it
was likely enough to be supported. personally, i think it would be
okay if we identified it as an option (not a requirement) of the
client application and that client capabilities were simply formulated
as http(s): URIs, we could just not deploy it in our client ('cause it
DOES have security ramifications.)

the example ... hmm ... we've got to be able to come up with a better
example. one of the things i've been thinking about is how the
underlying OGP mechanisms may be used with HyperGrid and CableBeach.
maybe there's a use case here for when users direct their avatars to
move across HG grid boundaries? if i understand it correctly,
different HG grids may specify distinct agent domains and asset
servers. perhaps the use case of a client mediated grid transfer in HG
would bear fruit.

i think.. in general... the existing event queue defined in OGP:Base
is perfectly acceptable for a wide number of uses, and will be less of
a lightening rod for security screeds. but yeah... when you need a
client side cap, sending a message down an event queue just won't
work.

so... i guess i'm thinking... we should do a little more word defining
WHEN client side caps are appropriate and when an existing event queue
structure is acceptable.

and about the URI scheme... i thought we were going to call it eq://
and eqs://. and lets be more explicit:

EQ://client_id@host:port/path?query#fragment

or

EQS://client_id@host:port/path?query#fragment

and... the example at the end seems to imply that it's the agent host
that creates the capability. shouldn't the client be the one that
creates the path portion of the capability and passes it off to the
agent host?

On Wed, Jun 24, 2009 at 10:06 AM, David W Levine<[email-masked]> wrote:
> week's AWGroupy meeting. For those who do not follow the weekly discussions,
> they are held in world, on Second Life Contact Zha Ewry (me) or
> Saijanai Kuhn in world for an invite. The AWGroupies meet Tuesday mornings
> at 9:30 AM Pacific time, in second life. For those who do not routinely use
> second life, a free account is available, details at the Linden Lab web
> site: http://secondlife.com/   I expect the next iteration of the document

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 Jun 2009 20:25:28 +0100

Infinity Linden wrote:
 [...]

>system is stock 4627 JSON, which it isn't. maybe both?
It would be better to avoid having both. If you can't avoid, make one of 
them normative and the other one informative.

---

From: Infinity Linden <[email-masked]>
Date: Thu, 25 Jun 2009 14:25:53 -0700

it is compatible with the 'value' non-terminal instead of the
'JSON-text' non-terminal defined in RFC4627. this is because we wanted
to allow a JSON serialized LLSD message to encode non-collections.
(RFC4627 REQUIRES valid JSON-text messages to begin with a '[' or
'{'.)

as described in the draft, valid JSON serialized LLSD messages are a
subset of valid JSON messages since LLSD REQUIRES UTF8. ergo, it is
possible to have a message that is valid under RFC4627 but an invalid
JSON serialized LLSD message.

however, given JavaScript parsing rules, a client which respects the
UTF-8 requirement of LLSD will be able to parse messages described by
the 'value' non-terminal in RFC4627 with the code given in the RFC.

in other words, we allow servers to give us JSON messages that are not
strictly compliant with RFC4627, and like virtually every web browser
in common use, we do not require JSON messages to be collections.