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


I think passing through the error code, as Dave proposes, probably is
fine. That's certainly what happens with today's HTTP proxies. I notice
the "via:" header for proxy/gateways is REQUIRED (RFC section 14.45,
however, and wonder whether we should abide by this requirement. We are
sort of a gateway or a proxy, but its not clear that we fall within the
intent of gateway and proxy in RFC 2616. 

Hmm. 

	-Gabe

> -----Original Message-----
> From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] 
> Sent: Thursday, January 27, 2005 4:13 PM
> To: Wachob, Gabe; xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] Alternative to Resolution Errors 
> inside Descriptors
> 
> I'd support this general approach. Thinking about it more, 
> I'm inclined
> to require that the XRID chain be returned in the response 
> and that the
> client pass on whatever error code it received from the upstream
> resolver. For example, if the authoritative resolver returns 
> a 404, the
> proxy/lookahead resolver passes that along to the client together with
> the chain of successful resolutions. No change there. But if the
> authoritative resolver returns a 500 (Internal Server Error), for
> example, the proxy/lookahead resolver returns the same code to the
> client along with the chain of successful resolutions. The client can
> distinguish between an immediate and upstream error by the body of the
> message (i.e. whether or not there's an XRID chain included in the
> response) and has full information about why the upstream request
> failed.
> 
> Dave
> 
> -----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/membe
> rs/leave_w
> orkgroup.php.
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.302 / Virus Database: 265.8.1 - Release Date: 1/27/2005
>  
> 


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