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