OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: RE: [xri-editors] Alternative to Resolution Errors inside Descriptors


This makes sense to me, and a good use of HTTP, but the original suggestion
did not strike me as "drastic" at all, and allowed the error data/metadata
to be dealt with in the context of the XRID, which is something which might
more easily be passed to an application.

Do you now think this is a bad idea?

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Thursday, January 27, 2005 4:03 PM
To: xri-editors@lists.oasis-open.org
Subject: [xri-editors] Alternative to Resolution Errors inside Descriptors

After some discussion internally, it became clear that there is an
alternative, and much less drastic proposal that would satisfy our
needs.

Basically, when a proxy (or lookahead) resolver performed a request that
had resulted (somewhere along the authority chain) in a failed
resolution (either because an authority could not be contacted, or
because an authority said a subsegment was not found, or other reasons),
the proxy/lookahead would return to the client an HTTP error status
code, and as content within the error code response body, the XRI
Descriptor elements it had *successfully* retrieved until encountering
an error. This complies with RFC 2616 which (for both 4xx and 5xx status
codes) allows an entity in the response that contains an explanation of
the error condition. 

Now, we also would like to distinguish between the following situations:
* the error occurred because the authoritative authority affirmatively
does not know about the subsegment - ie it is not registered
* there is some other error with the authority resolution process, like
a authority server is down, or a URL is incorrect

The proposal is that the error condition returned by a proxy/lookahead
is 404 Not Found if the authoritative authority affirmatively says it
can't find the subsegment and 502 Bad Gateway if the authoritative
server was unreachable or otherwise failed. 

I'd propose that returning the successful XRIDescriptor elements is a
SHOULD requirement (but the HTTP error codes would be a MUST). Also, I
*don't* think this has any effect on trusted rez, since the negative
results are, of course, unsigned (and therefore untrustable as negative
responses). 

Example:

This result might occur when lookahead resolving xri://@yoyodyne*labs at
the @ root and @yoyodyne explicitly states *labs is not registered:

HTTP/1.1 404 Not Found
<other headers>

<XRIDescriptors ...>
  <XRIDescriptor>
    <Resolved>@</Resolved>
    ...
  </XRIDescriptor>
  <XRIDescriptor>
    <Resolved>*yoyodyne</Resolved>
    ...
  </XRIDescriptor>
</XRIDescriptors>

Note that a 502 Bad Gateway HTTP status code might indicate that the
authority server for @yoyodyne could not be contacted or had a bad HTTP
URL in the descriptor for *yoyodyne.. 

There's some issue about whether or not we are overloading these HTTP
status codesand whether or not, as a practical matter that
non-XRI-resolution error conditions might happen when the XRI resolution
might otherwise be successful and confuse resolvers. 

In general, however, I think it's a good reuse of HTTP - Mark Baker's
"HTTP is an application protocol, not a Pipe" mantra keeps on
reverberating in my head...

	-Gabe

> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com] 
> Sent: Thursday, January 27, 2005 9:49 AM
> To: xri-editors@lists.oasis-open.org
> Subject: [xri-editors] Resolution Errors inside Descriptors
> 
> I have a use case where I would like to know that a resolution failed
> and have that result expressed inside of  an XRI Descriptor.
> 
> Take the case where I am using lookahead (or proxied) trusted
> resolution. If I request resolution of a subsegment that is not a
> subsegment the responding authority is directly responsible for, how
> does the proxy/lookahead resolver let me know as a client 
> that there is
> such a failure? If I'm resolving directly to an authority, I 
> get a 404 -
> but if I'm getting the result *indirectly*, we haven't said how such a
> negative result is expressed or cached.
> 
> So I therefore think we need to have a mechanism for expressing a
> negative result that can be cached and signed. Just an 
> element inside a
> XRI Descriptor - something like "Failure" or "Error" which contains a
> code (a URI) and a textual description (which we don't specify - as in
> HTTP). Now, there are a lot of concerns about extensibility and the
> ability of a processor to only partially undersatnd an error condition
> (such as HTTP's use of 3-digit error codes, or SOAP's use of
> hierarchical error codes - from most general to more specific) - this
> allows expression of as specific an error code as one wishes, without
> loss of appropriate behavior by processing nodes that don't understand
> themore specific error, but understand something more general. 
> 
> I'm not sure what mechanism we should use. I really don't 
> want to invent
> a bunch of error codes, or a complicated error extension mechanism, so
> the simplest thing we could do would be best. Do we need to go beyond
> something like:
> 
> <Failure>
>    <Code>..some uri..</Code>
>    <Description>...english language description...</Description>
>    ... extension elements ... 
> </Failure>
> ?
> 
> 	-Gabe
>  
> __________________________________________________ 
> gwachob@visa.com
> Chief Systems Architect
> Technology Strategies and Standards
> Visa International 
> Phone: +1.650.432.3696   Fax: +1.650.554.6817
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe
rs/leave_workgroup.php.
> 
> 

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xri-editors/members/leave_workg
roup.php.





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