Wil,
Thanks, this is
excellent, highly detailed feedback – exactly what we need right now. I am
travelling this week but know that Gabe and others are also engaged in a
detailed review right now. Once their comments are in, the editors will
collate and start assembling WD10.
I won't be on
Friday's call but I'm hoping that a number of these issues can get discussed
then in prep for WD10.
Please keep posting
anything else you notice/suggest changes on in
WD09.
=Drummond
From: Tan,
William [mailto:William.Tan@neustar.biz]
Sent: Wednesday, November 16, 2005
4:00 AM
To: xri@lists.oasis-open.org
Subject: [xri] Additional comments about
resolution draft 09
Hi,
More comments following a second
reading of the draft:
1. Section 6.7 confuses me – rule
#1 says that if application/xrd+xml is specified, the proxy MAY elect to
perform local resolution. But it has the choice of not performing this step?
My understanding is that the proxy should always perform local resolution to
obtain the XRD for the resource, depending on the Accept header, decides what
to do next. Based on that, it goes like:
Step 1 – perform local resolution
to obtain the XRD for the QXRI. If failed, return
404.
Step 2 – If application/xrd+xml is
specified, return the XRD. (Else, proceed to next
step)
Step 3 – If other content type is
specified in the Accept header, try to locate an SEP and return it. (If not
found, proceed to next step)
Step 4 – Try to locate a redirect
URI and return 302 if found. Otherwise, return
404.
2. Section 6.3 point #7 says that
the proxy resolution server should follow XRI redirects. I think this should
be split into two cases, where client is XRI-aware (presence of Accept:
application/xrd+*) and in the case of non XRI-aware client. In the former
case, if XRI redirect was followed, the chain of XRIDescriptor’s would be
different from the authority segment of the original QXRI, thereby confusing
clients. So, the proxy MUST/SHOULD return the XRD terminating at the
redirection instruction. In the latter case, the proxy SHOULD of course
process the XRI redirect on behalf of the client.
################# Kunal wrote:
###############
Completely agree here. Though
we built an HPR that further resolved an XRI synonym returned by loal
resolution, I think we'll change it to just return the XRD if there is an XRD
in accept header.
#############################################
3. Minor editorial: Section 6.4
Line 1093 – “If a URI meets this test but the domain name is less than
two three levels deep…”
4. I think we should make a
recommendation that the <Query> element be returned in the same form as
the query on the GET request. This would facilitate the client when checking
the returned response (this would be a SHOULD). However, the client SHOULD be
able to do a case-insensitive match, and possibly differences in percent
encoding.
/5. If there is no space for an
error message in an XRD, how is a server going to communicate an error
condition back to the client. I understand that an XRD is not meant for human
consumption, but it may make sense to differentiate between “I can’t connect
to the authority resolution endpoint” and “I know nothing about the community
root (+galaxy)”.
6. Section 5.3, point #3 says that
if no XRD is available to describe the identified resource, return 404. Should
it not return a 406 when an Accept header cannot be fulfilled as specified by
RFC2616?
wil.