Pat, I agree that 2.d is highly unlikely, but the protocol needs to support the broadest set of possible practices.
Roger, do you see an issue in adding the definition of the OPTIONAL “standard” attribute on the <fee:command> element with a default value of “0” (or “false”), that indicates whether the command fees match the “standard” classification command fees? I’ve attached a sample XSD (fee-0.25.xsd) that incorporates this as well as sample XML for a valid check response (good-check-response.xml), a valid check response using partial failure (good-check-response-partial-fail.xml), and a valid check response (good-check-response-fast-fail.xml) using fast fail. — JG [id:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pat Moroney <pmoro...@name.com> Date: Saturday, November 18, 2017 at 12:53 AM To: James Gould <jgo...@verisign.com> Cc: Andreas Huber <ahu...@united-domains.de>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document James, This will meet our needs. Thanks for whipping that up real quick. My only concern would be with 2.d. Although I know of no TLD that has a model without a standard fee, I can imagine one. I worry that it might provide too much freedom and be abused in the case where there is a de facto standard class, but it is named something other then standard, which would defeat the purpose of the standard fee attribute. I guess the chances of that happening could be mitigated using verbiage in the draft though, and I definitely prefer this remote chance to not having the standard fee attribute. Thanks again, -Pat On Thu, Nov 16, 2017 at 4:39 PM Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Pat, In thinking about it a little bit, how about the following proposal that I believe will address both of our concerns. 1. To meet the definition of the classification, move the <fee:class> element up from the <fee:command> element to the <fee:cd> element. a. This will clearly make the optional classification an object-level attribute in the check response. b. This will provide a hint to the client of the validity of the fee schedule for the object, where the “standard” classification fee schedule should be well known and more stable than a “non-standard” classification fee schedule. 2. Add a new optional “standard” boolean attribute to the <fee:command> element, with the default value of “0” (or “false”), that indicates whether the fees for the command and period matches the “standard” classification fees for the command and period. a. I believe this would match your use case of a “non-standard” classification domain name, where the create command fee is different from the “standard” classification fee (standard=”0” or undefined) and where the renew command fee is the same as the “standard” classification fee (standard=”1”). b. All of the <fee:command> elements for a “standard” classification domain name, would have standard=”1”. c. This requires the server to compare the “non-standard” classification fee schedule for each specified command against the “standard” classification fee schedule to set the appropriate “standard” attribute. d. There is no assumption that there is a “standard” fee schedule for the TLD, which would mean that the “standard” classification (<fee:class>) would not be specified and the “standard” attribute would be set to “0” or not set for all commands. Thoughts? — JG [mage001.png] James Gould Distinguished Engineer jgo...@verisign.com<http://jgo...@verisign.com> 703-948-3271<tel:(703)%20948-3271> 12061 Bluemont Way<https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> Reston, VA 20190<https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> Verisign.com<http://verisigninc.com/> From: Pat Moroney <pmoro...@name.com<mailto:pmoro...@name.com>> Date: Friday, November 17, 2017 at 1:36 AM To: James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>> Cc: Andreas Huber <ahu...@united-domains.de<mailto:ahu...@united-domains.de>>, "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] REGEXT Fee Document James, We are not advocating the classification at the period level. Adding the class to the command level doesn't require the server to be any more complex. It can internally keep the same model where the object has a classification and thus each command has the same classification. But, with this extra freedom, the server can then decide to offer more detailed information such as standard renewals on objects with non-standard creates, which is becoming a more common model. The class element came about when I suggested having a boolean flag for standard vs non-standard fees. If I remember correctly, Jens Wagner suggested extending it to allow a tier name. Registries currently use different tiers for different commands, and limiting it to a per-object classification would restrict their ability to market and price these domains. Since the current draft leaves it up to the server operator to define the non-standard classes out of band, I would assume it would be up to them what would happen in your "gold" vs "silver" example. To address Andreas's suggestion to omit standard fees: we prefer all fees be transmitted. This has prevented issues in the past when the standard rates change. Out of band transmission of fees is prone to manual error, and those errors can be costly. Thanks, -Pat Moroney On Thu, Nov 16, 2017 at 2:32 AM Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: Andreas, The point of the fee extension is to return the actual fee values, with the option of including a classification as a hint to the client of the fee schedule being used for the object (domain). There is no concept of a “standard” or “non-standard” fee, but a “standard” or “non-standard” object (domain). What classifications (one, both, or none) would be returned for a renew if there were two “non-standard” classifications (e.g., “gold” and “silver”) with the same renew fee that does not match the “standard” renew fee? There is not a single fee for a command, but a fee for the combination of the command and the supported periods. Defining a classification at the command and period level adds a whole new level of confusion and complexity for the client and the server. Maybe the concept of fee classification in general is too vague where there is no one fee classification data model on the server-side and there is certainly not a single fee processing model on the client-side to come up with a standard definition and protocol to support it. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271<tel:(703)%20948-3271> 12061 Bluemont Way<https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> Reston, VA 20190<https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> Verisign.com <http://verisigninc.com/> On 11/16/17, 4:16 PM, "regext on behalf of Andreas Huber" <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org> on behalf of ahu...@united-domains.de<mailto:ahu...@united-domains.de>> wrote: Hi all, <fee:class> should be under <fee:command>. I have the same points than Pat. We do not need to know if a price of a single command *COULD* be non-standard. Thats the same as completely skipping <fee:class>. Indeed, what I really need, is to know if a single fee is "standard" or "non-standard" priced, because we do a completely different processing of premium and standard (or promotion) fees. While registries had premium fees for create, renew and transfer, this wasn't a big thing, but since most registries switch to premium create with standard renew fees, we need to differentiate. So, I would suggest to clarify section 3.7 and change it to fee level. To save some bytes in the check response, <fee:class> with "standard" could be assumed as default and therefore optional, but mandatory if non-standard (premium, promotion, etc.). Another solution would be to not transmit standard fees in the fee extension at all. Thanks, Andreas Am 16.11.2017 um 04:44 schrieb Gould, James: > Pat, > > > > I will go back to the definition of the classification, which is an object-level attribute (e.g., “standard” or “premium” domain). Each classification has a fee schedule (commands and periods) that is assigned at the object-level, where the combination of the command and the period has a fee and not a classification. The classification (<fee:class>) should be placed in the location that reflects the definition to remove any confusion, which is under the <fee:cd> element. > > > > — > > > _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext -- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025<tel:(720)%20663-0025> -- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025
good-check-response-fast-fail.xml
Description: good-check-response-fast-fail.xml
good-check-response-partial-fail.xml
Description: good-check-response-partial-fail.xml
good-check-response.xml
Description: good-check-response.xml
<?xml version="1.0" encoding="utf-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema"; xmlns:fee="urn:ietf:params:xml:ns:fee-0.25" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" targetNamespace="urn:ietf:params:xml:ns:fee-0.25" elementFormDefault="qualified"> <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/> <import namespace="urn:ietf:params:xml:ns:domain-1.0"/> <annotation> <documentation> Extensible Provisioning Protocol v1.0 Fee Extension </documentation> </annotation> <!-- Child elements found in EPP commands and responses --> <element name="check" type="fee:checkType"/> <element name="chkData" type="fee:chkDataType"/> <element name="create" type="fee:transformCommandType"/> <element name="creData" type="fee:transformResultType"/> <element name="renew" type="fee:transformCommandType"/> <element name="renData" type="fee:transformResultType"/> <element name="transfer" type="fee:transformCommandType"/> <element name="trnData" type="fee:transformResultType "/> <element name="update" type="fee:transformCommandType"/> <element name="updData" type="fee:transformResultType"/> <element name="delData" type="fee:transformResultType "/> <!-- client <check> command --> <complexType name="checkType"> <sequence> <element name="currency" type="fee:currencyType" minOccurs="0"/> <element name="command" type="fee:commandType" minOccurs="1" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="objectIdentifierType"> <simpleContent> <extension base="eppcom:labelType"> <attribute name="element" type="NMTOKEN" default="name"/> </extension> </simpleContent> </complexType> <!-- server <check> result --> <complexType name="chkDataType"> <sequence> <element name="currency" type="fee:currencyType"/> <element name="cd" type="fee:objectCDType" maxOccurs="unbounded"/> </sequence> </complexType> <complexType name="objectCDType"> <sequence> <element name="objID" type="fee:objectIdentifierType"/> <element name="class" type="token" minOccurs="0"/> <element name="command" type="fee:commandDataType" minOccurs="0" maxOccurs="unbounded"/> <element name="reason" type="fee:reasonType" minOccurs="0"/> </sequence> <attribute name="avail" type="boolean" default="1"/> </complexType> <!-- general transform (create, renew, update, transfer) command --> <complexType name="transformCommandType"> <sequence> <element name="currency" type="fee:currencyType" minOccurs="0"/> <element name="fee" type="fee:feeType" maxOccurs="unbounded"/> <element name="credit" type="fee:creditType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <!-- general transform (create, renew, update) result --> <complexType name="transformResultType"> <sequence> <element name="currency" type="fee:currencyType" minOccurs="0"/> <element name="period" type="domain:periodType" minOccurs="0"/> <element name="fee" type="fee:feeType" minOccurs="0" maxOccurs="unbounded"/> <element name="credit" type="fee:creditType" minOccurs="0" maxOccurs="unbounded"/> <element name="balance" type="fee:balanceType" minOccurs="0"/> <element name="creditLimit" type="fee:creditLimitType" minOccurs="0"/> </sequence> </complexType> <!-- common types --> <simpleType name="currencyType"> <restriction base="string"> <pattern value="[A-Z]{3}"/> </restriction> </simpleType> <complexType name="commandType"> <sequence> <element name="period" type="domain:periodType" minOccurs="0" maxOccurs="1"/> </sequence> <attribute name="name" type="fee:commandEnum" use="required"/> <attribute name="customName" type="token"/> <attribute name="phase" type="token"/> <attribute name="subphase" type="token"/> </complexType> <complexType name="commandDataType"> <complexContent> <extension base="fee:commandType"> <choice> <sequence> <element name="fee" type="fee:feeType" minOccurs="0" maxOccurs="unbounded"/> <element name="credit" type="fee:creditType" minOccurs="0" maxOccurs="unbounded"/> </sequence> <element name="reason" type="fee:reasonType"/> </choice> <attribute name="standard" type="boolean" default="0"/> </extension> </complexContent> </complexType> <complexType name="reasonType"> <simpleContent> <extension base="token"> <attribute name="lang" type="language" default="en"/> </extension> </simpleContent> </complexType> <simpleType name="commandEnum"> <restriction base="token"> <enumeration value="create"/> <enumeration value="delete"/> <enumeration value="renew"/> <enumeration value="update"/> <enumeration value="transfer"/> <enumeration value="restore"/> <enumeration value="custom"/> </restriction> </simpleType> <simpleType name="nonNegativeDecimal"> <restriction base="decimal"> <minInclusive value="0"/> </restriction> </simpleType> <simpleType name="negativeDecimal"> <restriction base="decimal"> <maxInclusive value="0"/> </restriction> </simpleType> <complexType name="feeType"> <simpleContent> <extension base="fee:nonNegativeDecimal"> <attribute name="description"/> <attribute name="refundable" type="boolean"/> <attribute name="grace-period" type="duration"/> <attribute name="applied"> <simpleType> <restriction base="token"> <enumeration value="immediate"/> <enumeration value="delayed"/> </restriction> </simpleType> </attribute> </extension> </simpleContent> </complexType> <complexType name="creditType"> <simpleContent> <extension base="fee:negativeDecimal"> <attribute name="description"/> </extension> </simpleContent> </complexType> <simpleType name="balanceType"> <restriction base="decimal"/> </simpleType> <simpleType name="creditLimitType"> <restriction base="decimal"/> </simpleType> </schema>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
