Re: [ogpx] Informal draft for discussion -- client sidecapabilitiesand setup flows

[Infinity Linden <[e-mail]>]

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<[e-mail]> wrote:
> 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.)
>
>

[stuff removed]