Thomas,
I’m sorry, I missed the existence of a reason under the command since I thought the “avail” attribute and the reason element moved from the command level to the object level. My main concern with providing a highly feature rich fee extension to the domain check is ensuring that the domain check continues to meet the performance requirements, and that we don’t start down the path of creating extension upon extension of the domain check that will transition it into a domain “everything” command. I view the options for providing fee information in the fee extension as follows: 1. Extend the check command, as defined in draft-ietf-regext-epp-fees-03, with object level availability and unavailability reasons. a. Your use case would be handled by returning <cd avail=”0”> for example.tld with no commands and with the reason “domain name not available as a promotion name”. The server would fast fail the fee extension for the domain example.tld. This keeps the check command lighter weight, but it is still much heavier weight than a standard check command. 2. Extend the check command by defining a new command called the “fee check command”. a. The “fee check command” can include the availability along with the fee information, but it is treated differently from a standard check command and future extensions of the check command would not automatically apply to the “fee check command”. This change is strictly associated with the wording in the draft like defining the “claims check command” in section 3.1.1 of draft-ietf-regext-launchphase. In this case, we can provide for a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain). This removes the concern over the performance of the check command, since this is a fee check command and it does not encourage future heavyweight extensions. 3. Implement #1 and extend the info command by defining a new command called the “fee info command” that supports getting fee information for existing and non-existing objects, but it does not return the standard info response. a. The fee info command could include a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain). This supports getting more complex fee information without making the check command too complex. An example of a similar info command extension is defined with the Related Domain Info Command in our Related Domain Extension (http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm ). Thoughts? — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 4/28/17, 10:09 AM, "Thomas Corte" <thomas.co...@knipp.de> wrote: James, On 28/04/2017 15:27, Gould, James wrote: > Thomas, > > There are three classifications of errors that can occur with the fee > extension to the check command: > > 1. Syntax error – This should result in an error for the entire > check command. > > 2. Object (domain) name error (incorrect domain name, reserved > domain name, blocked domain name, etc.) – This should result in returning > avail=”0” for the associated fee:cd element for the object in the response. Agreed. > My recommendation > is to fast fail the processing of the fee information and return back > avail=”0” for each of the objects in the response with an appropriate > reason like “Invalid currency XXX”, “Invalid command XXX”, or “Invalid > command XXX period YYY”. I don’t believe that it will help to attempt to > put a higher level avail attribute and reason for the entire fee check > response extension, since the client would be expecting a fee result for > each object in the check command on a successful response. The check > command should not fail based on a data issue, so I would apply that same > approach with the fee extension to the check command. > > a. Since we’re extending the check command and response, I don’t > believe that the processing should flag errors below the object level. > This means that if one command is valid and another command is invalid, > the fee information is not available for the object. The server will > fast fail the processing of the fee extension in the event of a failure > to one command, class, period, phase, subphase, or currency. If there is > an expectation that the server should not fast fail, then we should > consider adding or moving the fee extension to the info command and > response. Agreed, even if the response would in this case not really reflect the server's internal fast failure, since it would still return the same error message for each checked object. But I can live with that. The question remains how to respond in situations where, for the same name, some <command> report assessed fees (since the name is e.g. OK for a certain phase or period), but some others have a <reason> indicating an error. Which value should the <cd> element's "attribute" have? Here's the example from yesterday's e-mail again: <chkData xmlns="urn:ietf:params:xml:ns:fee-0.17"> <currency>EUR</currency> <cd avail="???"> <objID>example.tld</objID> <command name="create" phase="open"> <period unit="y">1</period> <fee applied="immediate" description="domain creation in phase 'open'" grace-period="PT1M" refundable="true">60.00</fee> </command> <command name="create" phase="custom" subphase="defensive"> <period unit="y">1</period> <fee applied="immediate" description="domain creation in phase 'defensive-registration'" grace-period="PT1M" refundable="true">30.00</fee> </command> <command name="create" phase="custom" subphase="promotion"> <reason>domain name not available as a promotion name</reason> </command> </cd> </chkData> My suggestion would be to always include all <command> results in the <cd> element (whether they have fees or reason), and to have <cd avail="true"> as long as at least one <command> does not have a <reason> indicating an error. I.e., only if all the <command> elements in the response contain a reason indicating an error, the <cd> element should indicate the non-availability of fees. Thoughts? Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
