Good Morning,
Thanks for the comments Thomas! I will look at the consistency of the error codes in sections 3.2 and 5.1.1. As far as the text in the "avail" section you mention, I think this was meant as some combination of these items makes it invalid, not necessarily that a single item is invalid. I will look at wording to clarify. Thanks for catching the mismatch on the <fee:command>. Before updating the scheme I think it would be good to have the discussion on if this functionality is needed/wanted: would it be useful for the client to be able to not pass a <fee:command> in the <check> command? Thanks Roger -----Original Message----- From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Thomas Corte Sent: Wednesday, March 22, 2017 6:08 AM To: regext@ietf.org Subject: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard Hello, I've noticed two more issues with the latest EPP fee extensions draft, detailed below. Generally, I wonder if this mailing list is the right place to report such issues. Should I rather contact the authors directly, or is there a bug tracker set up for this purpose? Issues: 1) There seem to be contradictory requirements regarding the handling of invalid currency codes. In section 3.2, the draft says: "Servers SHOULD NOT perform a currency conversion if a client uses an incorrect currency code. Servers SHOULD return a 2004 "Parameter value range" error instead." However, in 5.1.1, it says: "An OPTIONAL <fee:currency> element. If the server does not support <fee:currency> value, it MUST return a 2306 error response;" Further below, the draft offers a third option: "The <fee:command> element also has an OPTIONAL "avail" attribute which is a boolean. If the value of this attribute evaluates to false, this indicates that the server cannot calculate the relevant fees, because the object, command, currency, period or class is invalid according to server policy." So this would indicate that an invalid currency in a <fee:check> should not result in an EPP error at all, but merely cause a non-available fee check result (an option which I would prefer). I believe this requires some unification, or clarification as to when to use which code (in the responses to transform commands at least), or when to use avail="false". 2) In the description for the <fee:check> response, the draft says: "If a <fee:object> element in the client command contains no <fee:command> element the server SHOULD return a <fee:command> element for each server billable transaction combination of the <fee:object>." However, such a case cannot occur since the definition of the "objectCheckType" complex type currently requires at least one <fee:command> element (minOccurs is not set and defaults to 1). This should be changed in the schema so that the intended "command wildcard" option becomes available. Best regards, Thomas -- TANGO REGISTRY SERVICES(r) 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<mailto:supp...@tango-rs.com> Germany _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
