OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[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]