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] Resolution Flowchart (and xribuilders).


First point sounds great to me.

 

Second point your logic is great for fault tolerance.

 

I don’t have a very strong opinion on it, the only issue being if Server A returns a 404 but Server B manages to resolve it, it means that Server A and B, both authoritative for the resource, are out of sync.

 

Another way that Server A and B could be out of sync is that Server A could be serving an extremely outdated version of the resource. The client can’t reliably find that out and goes to Server B, right?

 

The same logic works in DNS, i.e. if a name server is somehow serving NXDOMAIN (queried domain not found), then the resolver takes it as the final answer.

 

My idea of the fault tolerance mechanism is mainly for network errors.

 

Also, if the resource really does not exist, and there is a large number of URIs, the client will have to try them in turn until the list is exhausted.

 

wil.

 

 

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Friday, December 30, 2005 4:35 AM
To: Tan, William; 'Wachob, Gabe'; xri@lists.oasis-open.org
Subject: RE: [xri] Resolution Flowchart (and xribuilders).

 

Wil,

 

On your first point, we are planning to separate the two flowcharts (authority resolution and service selection) into two completely separate "phases" or "layers". The first phase – authority resolution – will always end with either an XRDS document or an error.

 

The second phase – service selection – is processing logic that acts on an XRDS given three inputs (a Type, a Path, and a MediaType) to produce a URI array or an error. Right now I plan in Working Draft 10 to day that this processing logic (or any logic that produces an equivalent result) MUST be followed by any HTTP proxy resolver and SHOULD be followed by any XRI resolver API.

 

How does that sound?

 

On your second point (that in the authority resolution flowchart, [Request XRDS] -> [Error?] -- Yes --> should probably fail immediately if the returned error code is 404, because it is an assertion by the server that the resource does not exist), the reason it doesn't seem this should be an immediate failure is because if the current XRD (the one the resolver is working from to identify the XRI authority being queried) contains more than one URI for a $res*auth endpoint, and the first URI produces a 404, the resolver should still try the second/third/nth URIs because they may query different servers that might provide different responses.

 

Do you agree?

 

=Drummond

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Thursday, December 29, 2005 11:49 AM
To: Wachob, Gabe; xri@lists.oasis-open.org
Subject: RE: [xri] Resolution Flowchart (and xribuilders).

 

I’m quite happy with the way that XRI resolution error conditions using HTTP status codes, as defined in cd01. Things only get more complicated with proxy resolution, since the proxy would have to act as a client, and therefore contain a resolver library of sort. And because the resolver library does a fair bit of processing, there are more error conditions, most of which could not find a HTTP counterpart. I’ll wait for the proposal then.

 

I totally agree with you that we should have a implementers list outside of the TC. My argument for the first question is precisely that the application/xrds+xml special cases should be taken out of the resolution flowchart, and should be addressed at the implementation level.

 

Thanks.

 

wil.

 

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Friday, December 30, 2005 3:20 AM
To: Tan, William; xri@lists.oasis-open.org
Subject: RE: [xri] Resolution Flowchart (and xribuilders).

 

Wil-

The second question is a topic of open discussion - I think someone has an action item to follow up on the last phone call and propose a set of error conditions that ride on top of HTTP but don't use HTTP error codes. Thats the current proposal - please push back if you think we should be going back to using HTTP-layer error codes.

 

The first question is, of course, interesting, but to the extent that its purely an API issue, its probably out of scope for the flowchart. I forsee a lot of discussions among *implementers* about APIs - typically I would expect either implementers to each come up with their own, or to work together to come up with a common API (a la SAX). In spec land, I've seen these efforts happen outside the standards body - for example, I set up a "beepbuilders" list for BEEP (RFC 3080/3081) - focused on implementers who want to talk with other implementers (inspired by soapbuilders). Not that BEEP has really caught fire...

 

So, when we get to that point, I'd suggest doing something like soapbuilders/beepbuilders and having a implementation list that is comprised of all the different parties implementing XRI where they can discuss things like interop, apis, deployment, etc. This is something that would have to happen outside the confines of the TC, since we *don't* want to restrict this lists's participation to TC members, or even members of OASIS.

 

This is distinct from xri-users, which is a list that I think is targeted (obviously) more at users and people buildling applications on *top* of XRI and XRI implementations...

 

    -Gabe

 


From: Tan, William [mailto:William.Tan@neustar.biz]
Sent: Thursday, December 29, 2005 11:06 AM
To: xri@lists.oasis-open.org
Subject: [xri] Resolution Flowchart

After staring at the resolution flowchart wd04 long enough, I have a few comments and would like to hear from the TC:

 

1.       It would be nice if application/xrds+xml and application/xrds-saml+xml were not special media types used to signal to the resolver to return the XRDS without further processing. Instead, the resolver API could provide the means for getting at the XRDS (e.g. with an [out] parameter to the function call) or provide a separate API for performing authority resolution alone.

2.       In the authority resolution flowchart, [Request XRDS] -> [Error?] -- Yes --> should probably fail immediately if the returned error code is 404, which is an assertion by the server that the resource does not exist. One could argue that the server could be misconfigured, since 404 could also mean that the web server cannot find the end point CGI script / servlet / request handler.

 

Thoughts?

 

wil.



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