I believe the classification <fee:class> should remain at the object-level, since the concept of standard or premium is done at the object-level and not at the command level. There may be the use case where a premium domain has a higher fee for the create but has the same fee as a standard domain for the renew and transfer, but that is based on the fee schedule defined for one or more premium domain names. The key is that the fee is more variable for premium domains than for standard domains, so it may be misleading to return “standard” for the renew and transfer commands of a premium domain if the premium fee and standard fee happens to be the same, since there is implied variability with the premium domain. It’s best to leave the classification as an object-level attribute and not attempt to derive it based on a comparison between the fee schedules.
— JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 4/26/17, 11:12 AM, "regext on behalf of Andreas Huber" <regext-boun...@ietf.org on behalf of ahu...@united-domains.de> wrote: Hi Roger, thanks for version 0.17! This one should solve most of our "registrar" issues (Hopefully, some registries plan to implement this version soon). Some thoughts to open questions: * Premium Domain Availability without Fee-Ext. I would also vote to respond with "unavailable". The status "premium" of a domain could be understood in a similar way to the domain status reserved, blocked or registered. Without using the fee extension, it's not possible to register such names, therefore they're "unavailable" for the registrar just like reserved names. If we don't want to use the Fee-Ext. for a specific registry (because of contractual reasons or something else), we're not interested in the availability of premium names which we can't/won't register anyway. Second thought: From a registry's perspective, I understand a name is always "available" if it is not registered, blocked or reserved, independent of any fees. But, ;) since EPP is a personalized communication protocol (client needs to login and register extensions to use), then responses should be personalized to the client. For a client not using the fee extension, a premium name is technically "unavailable". * <fee:class> in check responses The last weeks a question regarding the <fee:class> element came up a couple of times. <fee:class> is a child of <fee:command> since version 0.13, therefore section 3.7. should be clarified. Is <fee:class> an attribute of a specific fee or an object? There are some misunderstandings, especially before version 0.13, which describes "class" as a child of <fee:cd>. Several discussions with registries pointed out, that they understand <fee:class> as "attribute" of the object. This results in conditions where a domain has a premium create but a standard renewal fee to be both tagged with "premium", because an object can only have one value of the same attribute. As an example (from section 3.7): "The <fee:class> element which appears in <check> responses is used to indicate the classification of an object." should be changed to something like "... the classification of a command fee". As a registrar, we need to know if a "command fee" (not an object) is premium (e.g. <fee:class>premium</fee:class>) or standard, if one wants to respond standard fees at all. Responding standard fees are in fact unnecessary, btw. Thanks, Andreas Am 25.04.2017 um 23:40 schrieb Roger D Carney: > Good Afternoon, > > > > Here is the update draft document. This should include all of the agreed upon changes from the Chicago meeting (biggest change was the simplification of the <check> call). > > > > One topic that was discussed in Chicago (and not resolved) was on the concept of “premium names” and what is returned from the server if no fee extension was passed into the <check>. Many thought to be more “backwards compatible”/”user friendly”, especially for those registrars that do not and may > not be participating in the allocation of “premium names”, that the server should respond as unavailable. Others expressed that if it is available then the server should respond available. Please share your thoughts on the list on this topic and if this draft should even try to account for this concept. > > > > Please let me know if you have any questions. > > > > > > Thanks > > Roger > > > > > > -----Original Message----- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org > Sent: Tuesday, April 25, 2017 4:31 PM > To: i-d-annou...@ietf.org > Cc: regext@ietf.org > Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Registration Protocols Extensions of the IETF. > > > > Title : Registry Fee Extension for the Extensible Provisioning Protocol (EPP) > > Authors : Roger Carney > > Gavin Brown > > Jothan Frakes > > Filename : draft-ietf-regext-epp-fees-03.txt > > Pages : 33 > > Date : 2017-04-25 > > > > Abstract: > > This document describes an Extensible Provisioning Protocol (EPP) > > extension mapping for registry fees. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-regext-epp-fees-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-03 > > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
