On Feb 14, Andreas Savva modulated:
Ok ... I'm really not trying to be difficult with this.
Hah, don't be discouraged! I am just trying to help "channel" Chris since I've bent his ear on this topic many times before. I agree the specific faults seem a bit screwy... It sounds like there is a need for more separate faults: InvalidRequest: IMHO should mean invalid, e.g. doesn't validate to schema, just in case the user's tooling didn't already stop that before it got to the service. is this a MUST or a SHOULD for an implementation to validate input? UnsupportedRequest: detected some feature or extension not implemented (an implementation limit, not a site policy), and I would advocate that a service MUST detect and refuse unsupported/unrecognized features rather than silently proceeding, unless you have some way to mark fields as mandatory or not Unavailable: we cannot give what you are asking for, and this one has to be more generic I think and could be thrown when an implementation cannot be bothered to distinguish any of the following The previous seem very important and basic, while these latter ones seem more useful to expose more information but allow various levels of implementation complexity at the same time, all being alternatives to the generic Unavailable: Disallowed: if you want to report on site policy limits such as min/max thresholds, to help problem determination? OutOfRange: the parameter of a supported feature is out of range for either making sense or being available (Chris calls this being "configured" in a cluster, I think) or due to site policy, e.g. overlaps with Disallowed Depleted: this is a temporary condition such everything being allocated, so it is disjoint with Disallowed and OutOfRange. karl -- Karl Czajkowski karlcz@univa.com