James Gould wrote: > The availability of the domain name and the availability of the fee > information > can be separate.
I understand that. If the *only* semantics of the "avail" attribute is to provide the (redundant) information that "fee" elements are contained in the "command" element, then fair enough - it's still a redundant element, because it's sole purpose is then to indicate whether the "command" element contains "fee" elements (or not). I just don't want situations in which clients would interpret the "avail" flag as an indication that the respective command *will go through* (similar to what the "avail" attribute on the regular section of the check command implies for the "create" command). That's why i suggested truncating the respective definition to its core meaning. > Consider the use case where a client does a check for > an existing domain name (e.g., “existing-domain.example”), where the > availability > check returns “false” but the fee extension could return the fee information, > which > may be useful if the existing domain name is in pendingDelete. That's fine, of course. But whether or not fees are available could also be deducted from the fact that they are actually included in the response? > Let me be clear > that the fee information for an existing domain name is based strictly off > the fee > tables and not looking at the fee and credit information of the existing > domain itself. Interesting point. Of course, for the sake of simplicity, i'm with you. However, I *could* think of situations where renewal of an *existing* domain name has a different price compared to the renewal price if said domain was deleted and picked up on a (now different, lower) price class. But i don't want to go there. > The opposite case is sending a check for an available domain name (e.g., > “invalid-currency.example”) > with an invalid currency. In this case, the availability check would return > “true” but the fee extension would return “false” at the object level. Understood, and agreed. > It’s best to separate the availability values, where the availability of the > object is based > on the availability for registration and the availability of the fee is based > on the availability > of the fee information. I believe it’s best to support a fast-fail at the > object level > by including the avail attribute at the <fee:objID> level and leave the avail > attribute out of the <fee:command> level. Again, i do understand the difference between domain availability and fee information availability - but, again, the information whether or not fee information is available can be deducted from the presence of the *actual* fee elements, hence that element is syntactic "fluff", isn't it? best, Alex _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
