[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XDI/XRI Question
Some thoughts inline.
Dave
>Basically the scenario I'm seeing is that in some context, say a >corporate intranet, instead of having multiple protocols and >mechanisms for looking up info (databases, web, ldap for email) >XRI's are used to access the information in a unified way. > >For example with email... > >The current way: I type a name in my email client, it looks up the >address of my LDAP server, contacts the LDAP server, and fetches the >email address mapped to that name. > >The new way: I type a name in my email client, it converts the name >into an XRI and resolves that XRI by > >a) Contacting the corporations HR department, which runs the authority >for the context employee identification, @pin, and getting the pin >associated with the name by resolving xri:@pin.Bill which returns som >e sort of GUID. This is because there may be several Daves, and because >if it was Ms. X who became Mrs. Y their GUID would remain the same > >b) That GUID is then used within an XRI that is resolved by the IT >department's authority for @email context. > >I'm thinking the resolution would go like this? > > Original XRI: xri:@epok.email.(@epok.pin.(=Dave)) > > -> xri:@epok.email.DavesGUID > > -> mailto:dave.mcalpin@epok.net >
XRI supports both the idea of reassignable identifier and permanent identifiers. The GUID you're suggesting might be better represented as an XRI that consists entirely of non-reassignable sub-segments. It's also possible to have xri:@pin.Dave resolve to an alternative XRI, something like xri:=:1:2:3. The spec doesn't make it clear how to do this, but I have proposed errata that will hopefully correct that.
But now I'd have to ask what we're gaining by the extra level of indirection. What does @pin.Dave or @epok.pin.(=Dave) give us that we don't get just from =Dave, particularly if =Dave just resolves to a permanent version of an XRI?
I'd suggest that xri:@epok.email.(=dave) would be just a good. However, it's important to note that the resolution spec does not require the independent resolution of =dave; it says that cross-references are opaque for the purpose of resolution. That doesn't mean a particular identifier authority (.email, in this case) couldn't have it's own rules for resolving cross-references registered in its namespace, just that it's not required by the spec.
Incidentally, the reason the resolution of this XRI results in an email address might be because there's a local access element in the final XRIDescriptor that describes email and has a mailto: URI. Alternatively, there might be a local access element that described some way to query for email address.
>A few other questions: > >1) The xri form I'm looking for was something that could be put on a >biz card and the email would be good even if you transferred jobs, >assuming you updated a registry. Is there a form for that? I saw >electronic business cards as one example use case, but has the >syntax for that use been developed?
The form proposed up to this point (xri:@epok.email.(=dave)) is always resovled in the context of @epok. That means if I change jobs, resolving that XRI will only result in a new email address if @epok cooperates. If we want to relax that restriction, we might need some global authority (something like @email) whose job is to provide current email addresses. In that case we'd have an XRI like xri:@email.(=Dave).
If we're going to do that, though, why not just have xri:=Dave and take @epok or @email out of the picture entirely? In either of the last two cases (xri:@email.(=Dave) and xri:=Dave), the company wouldn't participate in resolution, which may not be appropriate in the corporate environment you initially proposed.
> >2) Is there a mechanism for reserving/querying a name within the = >namespace, or is that part of what we are doing in XDI?
The = namespace is global, just like the @ namespace. There's a single global authority that's responsible for registration and resolution.
> >3) For the purpose of an email that follows you regardless of company >or marital status would the following be better? >xri:=DavesRegisteredGuid.email
That's pretty much where I was going in 1) above.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]