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
