[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Updated error codes
Hi Drummond, I apologize for sending the large
attachment. In future, I will upload to Kavi instead. I don’t mind having the REF_NOT_FOLLOWED.
Yes it does make the status explicit and it would be trivial for the proxy
server to return that. However, it seems redundant because a client that
specifies no-follow-ref should know that if the returned XRDS is not complete
then either an error has occurred on the final XRD or the proxy could not
proceed to resolving the next subsegment. But seriously, I’m fine with
either way so maybe we can hear it from other TC members. Re: REF_NOT_FOUND, so we are not making a
distinction between Ref not found and Ref not panning out? I would think that
they are different classes of errors since Ref-not-found is a permanent failure
whereas tried-all-refs-but-they-all-failed may be permanent or temporary
depending on the error produced in the lower stack frames. Thanks. From: Drummond Reed
[mailto:drummond.reed@cordance.net] Wil, Thanks much for this. One note: we try to
avoid sending large attachments to the TC list. Instead upload them to Kavi
which will automatically send every TC member a link. RE your questions, see ### inline below. Best, =Drummond From: Tan, William
[mailto:William.Tan@neustar.biz] Hi Drummond, Here’s an updated error code table containing changes
that we agreed upon on Thursday’s TC call. With regards to the interaction between AUTH_RES_NOT_FOUND
and no-follow-ref, in order for me to understand it I divided it into 4
scenarios: Let’s set up a common QXRI =a*b, and the result of
resolution is that =a’s XRD has neither an $res*auth service nor a Ref
element.
### Good question. My vote would be that
since it was told not to follow Refs, it should just return the status of the
outcome, i.e., The latter, i.e., the proxy server would return one XRD from =
for the Query “*a” with a Status of SUCCESS plus one XRD for the
Query “*b” with a Status of AUTH_RES_NOT_FOUND. However I can
see the case for saying that in the second XRD it should return a Status code
of “REF_NOT_FOLLOWED” if there actually was a Ref in the XRD for *a
because that would be much more clear. Do you agree?
### Agreed – it should return
whatever error message on we decide on for #1..
### Here’s my rationale for why we
need *either* AUTH_RES_NOT_FOUND
or REF_NOT_FOUND but not both: the flowcharts showed that the logic paths are
identical. In other words, if you don’t find the service, you’re
supposed to look for a Ref. If you don’t find a Ref, or if a Ref
doesn’t pan out, then you didn’t find the Service. Between the two
options, the editors were leaning towards standardizing on AUTH_RES_NOT_FOUND
during the authority resolution phase and SERVICE_NOT_FOUND during the service
endpoint selection phase and dropping REF_NOT_FOUND. (However I think there is
a clear case for having REF_NOT_FOLLOWED as described above.)
### Agreed – again it should be
whatever error message we decide for #3. ### After you’ve processed this,
please send me your conclusion as to what we should change (if anything) in the
updated error table you sent – that’s what I’ll put in ED 07. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]