> 1. <cd> "avail" attribute meaning on partial return of results, see > section 3.9 for some additional context. The extension allows servers > to choose between returning no results or partial results when a server > encounters an issue with one or more of the requested <command>s. The > question raised specifically was "Should a partial result set the <cd> > "avail" attribute to true or false". The intent of the draft was to > return "avail=0" on partial (there was some failure), but some > implementations have interpreted it as "avail=1" (some data returned). > What do people think?
Since the client chooses the list of fee:command to include, if some are missing in the reply, I think it means that cd should be zero, because if it is 1, the following sentence, in absence of command elements in reply could lead to wrong conclusions: If the "avail" attribute of the <fee:cd> element is true and if no <fee:fee> elements are present in a <fee:command> element, this indicates that no fee will be assessed by the server for this command. Basically a complete error to set any fee (because of incompatible request parameters from client) may be interpreted as if no fee is needed at all, which is a completely different case. Hence I am in favor of cd=0 as soon as one problem is detected. The client is free to check again with different parameters until it gets cd=1 > 2. Appropriate level of <fee:class>, see section 3.7 for more details. > There has been an ongoing discussion on moving the <class> element to > the object level (i.e. at the <cd> level versus the <command> level). > Currently the draft has this at the <command> level but I do believe in > the merits of the argument that in reality/practice <class> is defined > at the domain object level and not the command level, so unless there > are arguments to keep it at the command level the next version will > move this to the object, <cd>, level. I also believe that we talk about a class for a domain and not a class for a command, so it should be tied at the domain level. This is even what the first sentence of section 3.7 implies. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
