Xavier Vilajosana <xvilajos...@eecs.berkeley.edu> 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
