RE: [xri] Revised _xrd_r proposal & Outputs section

["Steven Churchill" <steven.churchill@xdi.org>]

In essence this looks great to me. I agree whole-heartedly with the need (1)
to expose SEP selection via the proxy resolver and (2) to return the
entirety of <Service> metadata from both the local and proxy resolvers. 

I think we should formally change the terminology in the spec from: "HTTP
proxy resolution service" to "HTTP proxy resolver" as Drummond has used
below. The former sounds too much like it is implementing the behavior of an
authority resolution service.

~Steve



> -----Original Message-----
> From: Drummond Reed 
> Sent: Saturday, February 25, 2006 3:52 PM
> To: xri@lists.oasis-open.org
> Cc: 'Gabe Wachob'
> Subject: [xri] Revised _xrd_r proposal & Outputs section
> 
> In keeping with the points made in the previous thread - namely, that we
> have defined three possible outputs of XRI resolution, this is a revised
> proposal for the definition and use of the _xrd_r (Return) parameter.
> 
> Note: if we have consensus on this proposal, we would also change the
> existing "Input Processing" section to the spec to one called "Inputs and
> Outputs" where this content would appear.
> 
> The proposal is to define the _xrd_r (Return) parameter as an enumerated
> list whose values are:
> 
> xrds		XRDS document
> sep		Service endpoint
> uri		URI
> 
> There is NO default value if the parameter is absent or null. See below
> for
> the rules for that case.
> 
> The proposed rules when this parameter is PRESENT AND NON-NULL are:
> 
> 1) IF THE VALUE IS XRDS
> 
> SUCCESS - LOCAL RESOLVER: MUST return an XRDS document.
> 
> ERROR - LOCAL RESOLVER: Same - the XRDS document will describe the error.
> 
> SUCCESS - PROXY RESOLVER: Same.
> 
> ERROR - PROXY RESOLVER: Same.
> 
> 
> 2) IF THE VALUE IS SEP
> 
> SUCCESS - LOCAL RESOLVER: SHOULD return an array of name/value pairs where
> the name is the fully-qualified XPATH of each element/attribute in the
> selected service endpoint and the value is the contents of the
> element/attribute. In this array, element values must be followed by
> attribute values for that element, and elements must be in the priority
> order specified in the XRI resolution spec.
> 
> ERROR - LOCAL RESOLVER: SHOULD return the error code and message in the
> same
> fully-qualified XPATH name/value pair format.
> 
> SUCCESS - PROXY RESOLVER: MUST return the selected service endpoint as a
> single <Service> element in the XRD namespace.
> 
> ERROR - PROXY RESOLVER: MUST return a single <Status> element in the XRD
> namespace describing the error.
> 
> 
> 3) IF THE VALUE IS URI
> 
> SUCCESS - LOCAL RESOLVER: SHOULD return a string with the fully-
> constructed
> highest priority URI from the selected service endpoint.
> 
> ERROR - LOCAL RESOLVER: SHOULD return a string containing the error code
> followed by a space followed by an error description string.
> 
> SUCCESS - PROXY RESOLVER: MUST return the fully-constructed highest
> priority
> URI from the selected service endpoint as a string with content type
> "text/plain".
> 
> ERROR - PROXY RESOLVER: MUST return a string containing the error code
> followed by a space followed by an error description string with content
> type "text/plain".
> 
> 
> ******
> The proposed rules when the _xrd_r input parameter is ABSENT OR NULL ARE:
> 
> 1) WHEN TYPE=NULL, PATH=NULL, AND MEDIATYPE=APPLICATION/XRDS+XML (OR -
> SAML)
> 
> Same as option 1 above.
> 
> 2) FOR ANY OTHER SET OF INPUT PARAMETERS
> 
> SUCCESS - LOCAL RESOLVER: Same as option 2 above.
> 
> ERROR - LOCAL RESOLVER: Same as option 2 above.
> 
> SUCCESS - PROXY RESOLVER: MUST return an 3xx redirect to highest priority
> URI from the selected service endpoint.
> 
> ERROR - PROXY RESOLVER: SHOULD return a human-readable error message with
> content type "text/plain" or "html".
> 
> =Drummond
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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