[higgins-dev] RE: Version 2 of proposal 2B (IdAS Registries)

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Drummond wrote:
> 
> Paul,
> 
> Finally, here's my detailed feedback about the proposal.
> 
> First, this is minor, but with XRIs (as with URIs and IRIs), the authority
> segment is case-insensitive but the path is case sensitive. For this
> reason
> XRI (like IRI & URI) specifies all lower case normalization. So XRIs like
> +OPENID, +SQL, and +LDAP, which by themselves are absolute XRIs, SHOULD be
> normalized to lowercase even when used in the path.

Okay, http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B is now
fixed (version 3).

> 
> Second, while the overall structure of the proposal makes sense, my key
> question is why you chose authority/path/type as the Higgins context
> identifier algorithm. 

You give me too much credit. I'm not thinking that deeply. I simply know the
semantics of what I'm trying to represent in the identifier and I'm
completely open to advice as to the best practice syntax to express that. We
needed to be able to do this:

1) point to an XRDS document
2) within that XRDS refer to a SEP (that provides Context metadata)

For inames like =drummond we realized that we can do #1, but not #2. So we
needed to add something. In this case =drummond refers to N>1 possible
contexts, each with a different service type. So it seemed to make sense to
add a little something to =drummond to disambiguate by 'type' (hence the
+opened add-on).

For cases where =drummond not only had N>1 Contexts but that some of them
WERE explicitly named (e.g. "bizcard", "webSurfingPersona") we thought we'd
add a little something (e.g. "/bizcard") to arrive at =drummond/bizcard.

Once I learned that you can resolve by type AND path at the same time I
thought I'd just string the pieces together in this order:

   Authority [/ [path] [/ type]

And ALWAYS resolve by path and type (ignoring one or the other if it was
missing). Seemed clean and consistent.

We're open to another suggestion of how to encode the semantics.

> The reason I ask is that both XDI models (the ATI
> model and the RDF model) use the authority/type pattern (specifically the
> ATI model uses authority/type/instance and the RDF model uses
> authority/type+subtype).
> 
> From an XRI parsing standpoint, using the first segment of the path as the
> synonym for the type seems conceptually cleaner than the last segment of
> the
> path (although technically either one could work).

Okay, I'm open to swapping these.

> 
> I suspect you chose that direction in order to be able to deal with http
> and
> https identifiers that are not XRIs, as you can't "compose" these
> identifiers the way you can XRIs (which of course is one key reason we did
> XRI as an infrastructure for structured identifiers).

More or less. To me the <path> seems the more ordinary way to
name/disambiguate Contexts and the <type> is used only if necessary (as a
last resort). So having the <type> at the end felt more natural.

> 
> If so, I can understand that, but let me point out that the TC has begun
> discussing adding the capability for XRI resolution to be able to resolve
> http and https identifiers directly when used as cross-references within
> an
> XRI.
> 
> Here's a simple use case: you have the URL "http://example.com/some/path";
> and you want to make it a node in the XRI resolution network, so that if
> an
> XRI resolver asks it for an XRDS document, it will return one (if it
> exists).
> 
> If that's the root node of the XRI authority segment, then the XRI would
> be:
> 
> 	$(http://example.com/some/path)
> 
> Note that this entire XRI is an XRI authority segment, i.e., even though
> the
> URL inside the cross-reference has a path, as an XRI there is no path yet.
> So if you want to add a path containing an XRI identifying the type as the
> first segment, it's easy:
> 
> 	$(http://example.com/some/path)/+openid
> 
> Again, this "composeability" of identifiers is exactly the reason we
> created
> XRI, so it's no coincidence that this all works. Essentially you can
> create
> and use your own XRI patterns for your own use cases, anywhere from an
> individual program or open source project (like Higgins) on up to an
> entire
> protocol (like XDI).

I really like the additional capability implied here:

    $(http://example.com/some/path)/+openid

When it's available we'll use it.

As for a better ordering of the three bits, or any other suggestions on what
I'm now thinking of as the "Higgins profile of XRI", we're interested in
being as conformant to the "XRI way" as possible. 

> Let me know if you want more details about this approach. (Note that I'll
> be
> largely offline until mid-afternoon tomorrow.)
> 
> =Drummond
> 
> -----Original Message-----
> From: Paul Trevithick [mailto:paul@xxxxxxxxxxxxxxxxx]
> Sent: Tuesday, March 06, 2007 11:05 PM
> To: 'Higgins (Trust Framework) Project developer discussions'; 'Drummond
> Reed'
> Subject: Version 2 of proposal 2B (IdAS Registries)
> 
> I have made a couple of minor changes to [1]:
> 
> 1) Both path and type are optional in the syntax of ContextIds; all that
> matters is that exactly one SEP is matched within the XRDS document (with
> or
> without path and type matching). So I changed some of the use cases to not
> use Type matching (within in the Context Registry).
> 
> 2) Added new section 'Locally Deployed Context Provider Registry' in
> response to Tom's recent comments
> 
> Drummond, if you could review just this (new) section [2] that would be
> great.
> 
> [1] http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B
> [2]
> http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal_2B#ContextIds
> 
> -Paul
>