Jim,
In the past
ContextRefs have been implemented using a two part identifier. The first part uniquely
identified the provider/factory the second part was the unique id of a context
managed by that factory. This is what you call 1) in your email below.
We want to
move towards your 2). We want the IdAS user to be able to request that it open
a Context by URI without having to know which provider/factory to use a priori (use
case #1 here).
Whereas in
#1 the form of the context id part was entirely up to its “creator”
provider/factory, now we envision a ContextRef being a URI formatted string that
may be used by (or at least examined by) more than one provider. This raises
lots of questions.
Consider
the following ContextRefs:
- http://www.fabrikam123.example/HR/employees
- an LDAP directory
- proprietary-scheme-a://contactlist - user’s
contact list stored as tab delimited file
IdAS can
ask each registered provider whether or not it can open this ContextRef.
Provider A may respond that it can open #1 above and Provider B may respond
that it can open both #2 and #1.
Questions:
- Since
providers are ultimately the generators/assigners of new ContextRefs
should we allow them to assign their own schemes if they use proprietary
technology (as in “proprietary-scheme-a” in #2 above)?
- Do
we assume all URIs that use the HTTP scheme are resolvable? (URLs)
- Beyond
resolvable, should we require as Tony has suggested that all HTTP-scheme URIs
are also WS-Addressing endpoint references? (This would solve the problem
of how a provider could get the policy and other metadata to help it try
to open and access the context data)
BTW, I
envision some context providers will be developed that use XRIs for their ContextRefs.
-Paul
Jim wrote:
I wonder if we have different ideas about what's
in the Context Reference URI.
1) Until lately, I thought it contained at least the name
of a context factory, plus the name of a context. I wasn't sure what either of
these looked like, just assumed they were both required.
2) From discussions, I think some others think it only
holds the name of a context (in some form). This allows one URI to be used
against multiple factories to produce the same Context (albeit possibly via
different IContext instances, using different config and policy, using
different AuthN, and thus semantically different).
3) Tom assumed it was a pointer into a context definition
file. In our world, that segment of the definition file names the factory used
to produce that context.