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. 3. Crosscutting input element error (invalid currency, invalid command, invalid command period, invalid class, invalid command phase or invalid subphase – Since each of these input elements apply to all objects in the check command, an error with any of them will impact the ability to return a complete set of fee information. 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. — 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, 8:48 AM, "Thomas Corte" <thomas.co...@knipp.de> wrote: Hello James, On 28/04/2017 14:32, Gould, James wrote: > Thomas, > > I don’t agree that failing the entire check command if someone passes invalid input in the fee extension, unless it is syntactically incorrect. The point is to communicate whether the fee information is available for the given object and commands, and if it is return the fee information. Sure, but the current draft would require the following response for a <check> with a wrong currency "BLA", assuming that two domains with 3 commands each were specified: <chkData xmlns="urn:ietf:params:xml:ns:fee-0.17"> <currency>BLA</currency> <cd avail="false"> <objID>example1.tld</objID> <command name="create" phase="open"> <period unit="y">2</period> <reason>the selected currency is not supported (supported currency is "USD")</reason> </command> <command name="transfer" phase="open"> <period unit="y">1</period> <reason>the selected currency is not supported (supported currency is "USD")</reason> </command> <command name="renew" phase="open"> <period unit="y">1</period> <reason>the selected currency is not supported (supported currency is "USD")</reason> </command> </cd> <cd avail="false"> <objID>example1.tld</objID> <command name="create" phase="open"> <period unit="y">2</period> <reason>the selected currency is not supported (supported currency is "USD")</reason> </command> <command name="transfer" phase="open"> <period unit="y">1</period> <reason>the selected currency is not supported (supported currency is "USD")</reason> </command> <command name="renew" phase="open"> <period unit="y">1</period> <reason>the selected currency is not supported (supported currency is "USD")</reason> </command> </cd> </chkData> I.e. there is no shorter way to report the wrong currency (which should have prevented any further checks by the server whatsoever) than this. Note that the periods are there since the draft says "The <fee:period> element MUST be present in <check> responses." It gets a bit better by introducing the <choice> we discussed (see below), but even then the response would have to list each domain from the check, even though the error is independent from the domain name. Yet I'm aware that the only option to prevent this would be to introduce a framing element for the <cd> elements, which could then contain (yet another) reason for failure as an alternative for the <cd> children. > I agree that there should be a choice between inclusion of the commands or the reason in “objectCDType” to support returning either a successful list of commands or optionally providing a reason that the fee information is not available. My recommendation for “objectCDType” is below: > > <complexType name="objectCDType"> > <sequence> > <element name="objID" type="fee:objectIdentifierType" /> > <choice minOccurs=”0”> > <element name="command" type="fee:commandType" > maxOccurs="unbounded" /> > <element name="reason" type="eppcom:reasonType”/> > </choice> > </sequence> > <attribute name="avail" type="boolean" use=”required” /> > </complexType> > > The objectCDType can include the fee:objID, the fee:objID along with the commands, or the fee:objID along with the reason. The “avail” flag is changed to required without a default to be explicit, which is consistent with how the “avail” flag works in the check response. The reason leverages the “eppcom:reasonType” to support use of the optional “lang” attribute to be consistent with the check response. Agreed, this is what I had in mind. However, the question from the e-mail I sent yesterday remains - how to report "mixed" results (i.e., what value should "avail" have if fees are available for some nested commands, but not for others (see the example from my e-mail). Best regards, Thomas -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: thomas.co...@knipp.de Software-Entwicklung E-Mail: thomas.co...@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
