James, I understand your concern with option #1, but I think option #3 goes into a different set of issues where we mix the domain sales pipeline with domain management activities, for which domain:info is commonly used. I'm neutral between option #1 and option #2, but while both work me, I would really like to know which option has more chance of being implemented by registrars; and if they favor either #1 or #2, I would favor that as well.
Rubens > Em 28 de abr de 2017, à(s) 17:55:000, Gould, James <jgo...@verisign.com> > escreveu: > > 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 > > <http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm> > ). > > Thoughts? > > — > JG > > > > James Gould > Distinguished Engineer > jgo...@verisign.com <mailto:jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com <http://verisigninc.com/> <http://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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
