[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Minimizing the processing on the proxy resolver invoker.
A big +1. > -----Original Message----- > From: Chasen, Les [mailto:les.chasen@neustar.biz] > Sent: Wednesday, March 01, 2006 12:01 PM > To: xri@lists.oasis-open.org > Subject: RE: [xri] Minimizing the processing on the proxy > resolver invoker. > > Thanks Drummond. I think the return types (XRDS, XRD and > URI) supported > by any given instance of a proxy resolver must be optional. In fact I > think pretty much all functionality should be optional. For instance > caching, lookahead, trusted res all should be optional. > This provides > for the ultimate flexibility in load distribution. > > > I-Name: =les.chasen > > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Wednesday, March 01, 2006 2:09 PM > To: 'Wachob, Gabe'; 'Steven Churchill'; xri@lists.oasis-open.org > Subject: RE: [xri] Minimizing the processing on the proxy resolver > invoker. > > I agree with Gabe that doing these transforms on the XRD is > okay because > even if you asked for the proxy resolver to do trusted res (by setting > the > _xrd_a parameter to "application/xrds-saml+xml"), if you also set the > _xrd_r > parameter to "application/xrd+xml", that means you are trusting the > proxy > resolver to get everything via trusted res and then return to you just > the > final "filtered" XRD -- knowing that if trusted res fails because a > signature doesn't check, that XRD will simply have a Status > code telling > you > that. > > Now, about Gabe's second question: "Is return of the XRD an optional > function of a proxy or are we saying that to be compliant, a > proxy MUST > be > able to return any of the three types (URI list, XRDS, XRD)?" > > I can almost hear Les going off like a rocket!!!!!!! > > I'll let him speak for himself, but he feels pretty strongly > that proxy > resolver services need to be able to control their load by controlling > which > options they support. Since all three options (plus trusted > res) are now > represented by media types... > > application/xrds+xml > application/xrds-saml+xml > application/xrd+xml > text/uri-list > > ...I think the rule can be pretty simple, which is that IF a proxy > resolver > supports a particular media type, THEN to be compliant it must produce > that > media type in a manner compliant with the spec, but that > support for any > particular media type is optional. > > I think we should also add that XRI communities SHOULD > publish both the > URIs > and the capabilities (media types) of their proxy resolvers in their > community root XRDS documents. > > Again, everyone, please send any comments/feedback on this (or on > Steve's > suggestion for minimizing parsing of the XRD) ASAP, as I'm coding this > all > into ED 07 RIGHT NOW. > > =Drummond > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Wednesday, March 01, 2006 10:30 AM > To: Steven Churchill; xri@lists.oasis-open.org > Subject: RE: [xri] Minimizing the processing on the proxy resolver > invoker. > > This would be OK to do outside of trusted resolution. This sort of > transformation will screw up the hash/signature. > > But this is probably OK, since I think the obvious implication of the > "XRD only" return value is that only the proxy (if anyone) is > performing > trusted resolution validation, not the proxy's client. > > I lost track - is return of the XRD an optional function of a proxy or > are we saying that to be compliant, a proxy MUST be able to return any > of the three types (URI list, XRDS, XRD)? > > -Gabe > > > > -----Original Message----- > > From: Steven Churchill [mailto:steven.churchill@xdi.org] > > Sent: Wednesday, March 01, 2006 10:18 AM > > To: xri@lists.oasis-open.org > > Subject: [xri] Minimizing the processing on the proxy > > resolver invoker. > > > > > > Drummond, > > > > Regarding yesterday's change regarding the proxy resolver's > output, we > > should do our best to minimize redundant processing on the > > part of the proxy > > invoker. > > > > For example, I suggest that the XRD (for _xrd_r = "xrd") be > > output in such a > > way as to allow the invoker to use a simple/fast function such as: > > > > // For example, s.between("foo", "baz") returns "bar" in > > "foobarbaz" > > String between(String this, String that); > > > > in order to, say, pull out the selected service's highest > > priority URI. For > > example, allow the invoker to do something like this to get the URI: > > > > String highestPriorityURI = xrd.between("URI>", "<"); > > > > > > In order to support this, we'd need to specify some > > requirements on the > > output <XRD>: > > > > 1. The selected service is the first in the list. > > 2. The highest priority URI is the first in that list. > > 3. The <URI> has no attributes. This way we can say > > xrd.between("URI>". > > > > 4. The highest priority CanonicalID is the first in it's list. > > 5. The CanonicalID has no priority. > > > > The converse to this proposal (not doing something like this) > > seems a bit > > strange to me. That is, because we have the information at > hand in the > > Resolver, it's as though we'd intentionally be obfuscating it before > > returning it to the invoker. > > > > Thoughts? > > > > ~ Steve > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all > > your TCs in OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > > oups.php > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr oups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr oups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all > your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]