[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Updated error codes
Wil, The thing I like about REF_NOT_FOLLOWED is
that it allows a resolver (local or proxy) to make a very clear response as to
why the final XRD it returns does not have all the info the calling application
might expect in the final XRD. In other words, if a client makes a call with
the _xrd_n flag and gets back an
XRDS ending an an XRD with a Status of REF_NOT_FOLLOWED, it knows for certain
that: 1) there was a Ref in the resolution chain, and 2) there was no other
error. The reason I’m not convinced that we
need REF_NOT_FOUND is that I believe the two cases you mention net out to the
same thing. In other words: 1) Case 1: the requested SEP is missing and so the resolver looks for
a Ref and finds none. Logically the resolver should then return REF_NOT_FOUND. 2) Case 2: the requested SEP is missing and so the resolver looks for
a Ref and finds one and follows it and THEN the next XRD doesn’t have the
requested SEP either so the resolver looks for a Ref and this time it doesn’t
find one and returns REF_NOT_FOUND. Same conclusion as Case1. Ultimately with if we go with REF_NOT_FOUND,
we don’t need AUTH_RES_NOT_FOUND and SERVICE_NOT_FOUND because the result
of the SEP selection phase is always either going to be either SUCCESS or
REF_NOT_FOUND. The other option is that if a requested
SEP is missing and the resolver looks for a Ref and finds none, it returns: 1) AUTH_RES_NOT_FOUND if it’s an $auth*res SEP not found during
the Authority resolution phase, and 2) SERVICE_NOT_FOUND if it’s another SEP not found during the service
endpoint selection phase. Again, both of these latter results would
ALWAYS ultimately imply that a Ref was not found – otherwise you’d
end up with SUCCESS. But IMHO the second option of at least being able to tell
the resolution phase at which the SEP was not found is more useful than just
always getting REF_NOT_FOUND and not even knowing what resolution phase that
happened. Do you agree? =Drummond From: Tan, William
[mailto:William.Tan@neustar.biz] 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]