[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? From: 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] [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: 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]