|
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
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.
|