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