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.


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_workgroups.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_workgroups.php 



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