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

 

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.



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