Hi,
Regarding to how to choose a error code when multiple error codes could be
candidate, I think we can use a simple rule as follows. If a specific error
code, such as RC_ERR_NORES, is matched to the abnormal situation, then the
specific error code must be used. If there is no specific error code is matched
to the abnormal situation, then the generic error code RC_ERR must be used.
BTW, I haven't seen there is any overlap among different specific error codes.
Did I miss something?
ThanksQin
On Monday, October 3, 2016 2:55 PM, Dale R. Worley <[email protected]>
wrote:
Xavier Vilajosana <[email protected]> writes:
>> - Also, if the 6p response has multiple cases matched (for example,
>> the candidate cells are occupied RC_ERROR and also no enough resource
>> ERROR_NORES...), which one should the mote choose? (add priority for the
>> error code? at least we need a decision)
>>
> that is a good point. The two options I see are, either returning the list
> of error codes or defining priorities and returning the most important. We
> should consider that in the next version of the draft.
I've seen situations in another protocol (SIP) where a single request
could be responded to with multiple error codes. There has been no
pressure to specify which of the possible error codes MUST be returned.
The understanding is that different implementations process various
aspects of a request in different orders, and that an implementation
will generally return the first error condition that it discovers and
then abort processing of the request. A rule for which of the multiple
errors must be returned would require either that an implementation
process the request in a fixed order, or that it must somehow complete
processing and then select the "best" error code. Worse, if a request
is erroneous in one particular aspect, then it may be ill-defined
whether it is erroneous in another particular aspect.
Dale
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
