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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] Point Steve brought up


+1 to have a flag that tells the resolver to select the given criteria (not just service type – if a path is given it should also be matched explicitly).

 

I propose an optional parameter in _xrd_r called “explicit” which has a default value of “false”. If sep=true and explicit=”true” then the resolver must match services explicitly according to the given Type, MediaType and Path explicitly, i.e. do not process match=”default”.

 

Comments?

 

=wil (http://xri.net/=wil)

 

 


From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Thursday, August 24, 2006 11:59 AM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Point Steve brought up

 

I think your idea of adding some type of flag is a lot better than forcing the application to validate the XRD.

 

~ Steve

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wednesday, August 23, 2006 5:14 PM
To: 'Steven Churchill'; xri@lists.oasis-open.org
Subject: [xri] Point Steve brought up

 

[Important: this is NOT about CanonicalIDs, but another point Steve brought up in this message that bothers me and which we may need to deal with in WD11.]

 

In the message below, Steve explains how a resolver might return a status 100 for selection of a SEP that doesn’t in fact match the Type of service it asked for.

 

That really bothers me.

 

In other words, the logic Steve describes is needed in step 2 below should NOT be needed. There should be a way to tell a resolver that when sep=true, the Type MUST match _xrd_t.

 

Do you agree? If so, any ideas on the best solution for this?

 

I don’t have time to fully grok this right now, but I’m sensing this + the issue Wil’s been bringing up of trying to find a way to simplify the match=”default” issue = something we really have to figure out for WD11 because it’s going to have a big impact on implementations.

 

More grist for the mill for tomorrow. I’ve added Steve’s message below to the WD11 wiki page under issue #21.

 

=Drummond

 


From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Wednesday, August 16, 2006 11:51 PM
To: xri@lists.oasis-open.org
Subject: [xri] Observataion about service obtaining CanonicalID given a QXRI passed to a service endpoint.

 

Here’s an observation about obtaining the CanonicalID given a QXRI passed to the service endpoint.

 

First some motivation: using the CanonicalID as a primary key for the I-service account (rather than the using i-name in the QXRI) allows synonyms to be passed in the QXRI. This includes the usage of Refs. For example, if @ootao*steve contains a Ref to =steve, where the =steve authority defines the i-service, then @ootao*steve can be passed in the QXRI.

 

Now to the point: Step (2) below in the below algorithm is required.

 

Here’s the algorithm one of our I-Services uses to obtain the CanonicalID (that it uses for its primary key) from a given QXRI.

 

1.               Obtain the XRD from Appendix E’s resolveSEPToXRD() setting the sepType argument to the given service type.

2.               Check if a service of the given type actually resides in the returned XRD.

3.               Extract the CanonicalD from the XRD.

 

Here’s an example why step (2) is needed:

 

Say that the qxri has =steve and that =steve does not have a service of the type in question but that it does have a default service such as a contact service. Step (1) will return an XRD with status 100 even though it does not contain the correct service type. Without step (2) we would get a CanonicalID for an authority that doesn’t have an SEP for our service.

 

Perhaps this algorithm should be provided in the spec somewhere as a best practice.

 

~ Steve

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]