[ i hate responding to my own message, but i think i need to add something ]
I wrote my message under the impression that it was suggested to change the semantics of the "avail" flag, which is currently defined as: The <fee:command> element also has an OPTIONAL "avail" attribute which is a boolean. If the value of this attribute evaluates to false, this indicates that the server cannot calculate the relevant fees, because the object, command, currency, period or class is invalid according to server policy. The key part here is "indicates that the server cannot calculate the relevant fees". It should *not* imply that the command in question would be available for the given combination. I suggest that we simply truncate that paragraph to The <fee:command> element also has an OPTIONAL "avail" attribute which is a boolean. If the value of this attribute evaluates to false, this indicates that the server cannot calculate the relevant fees. It still has the potential for confusion with the semantics of "this command is available" rather than "we could calculate fees". We could clear this up by renaming the attribute to "feeavail" (or anything less awkward than that, just something that does not collide with the "regular" avail attribute) ? If we keep it, my preference would be to keep it on the command level, because a registry might be able to calculate fees for one command in the set, but not for another, so it should be specific to a certain combination. Alex Alex> I think we need to be very very clear what the "avail" attribute on either of the levels imply. We should *really* try to stick to the purpose of this extension, which is about *fees*. In detail: - I think it would be highly confusing and redundant to have it at both levels. This would mean we have three instances of "avail" attributes in a check response (including the one from the "regular" check). - As i have said before, "avail" on the command level seems overarching to me, if this is supposed to indicate whether a certain command (with a certain period, a certain phase, and a certain currency?) is available at this point in time. That's overlaying too many policy engine decisions, and sounds scary to me (besides that it has nothing to do with fees anymore - it's wrapping in "more stuff") - Then again, the "avail" attribute on the fee:objID would essentially be a 1:1 copy of the "regular" "avail" attribute - which is redundant too. Adding data to a machine-to-machine protocol just for the purpose of comfort seems weird to me. Therefore, thinking about all that, i suggest that we simply remove the "avail" attribute from the extension *unless* we find a really precise semantic definition of its meaning. We should keep the purpose of this check to *fees*, not make it a generic "policy query oracle" which command is available under which conditions. best, Ale
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
