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
