[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Updated error codes
|
That’s fine with me. In that case,
please add a new error code 101 REF_NOT_FOLLOWED – “The subsegment was
not resolved because the resolver was given the no_follow_ref option. This
indicates that no authority resolution service was found in the parent
subsegment, but at least one Ref element was present so the client should try
again without the no_follow_ref option.” Feel free to change the wording as
appropriate. Thanks. From: Drummond Reed
[mailto:drummond.reed@cordance.net] 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: 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: 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]