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