Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt

From: Gavin Brown <[email-masked]>
Date: Thu, 01 May 2014 18:12:23 +0100

Thanks to all for the feedback. I am working on a revised draft that
will use a single <fee:check> element in commands and a single
<fee:chkData> element in responses.

Here are some example commands and responses: let me know what you think.

Thanks,

C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:   <command>
C:     <check>
C:       <domain:check
C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:         <domain:name>example.com</domain:name>
C:         <domain:name>example.net</domain:name>
C:         <domain:name>example.org</domain:name>
C:       </domain:check>
C:     </check>
C:     <extension>
C:       <fee:check
C:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
C:         <fee:domain>
C:           <fee:name>example.com</fee:name>
C:           <fee:currency>USD</fee:currency>
C:           <fee:command phase="sunrise">create</fee:command>
C:           <fee:period unit="y">1</fee:period>
C:         </fee:domain>
C:         <fee:domain>
C:           <fee:name>example.net</fee:name>
C:           <fee:currency>EUR</fee:currency>
C:           <fee:command phase="claims" subphase="landrush">
C:           create</fee:command>
C:           <fee:period unit="y">2</fee:name>
C:         </fee:domain>
C:         <fee:domain>
C:           <fee:name>example.org</fee:name>
C:           <fee:currency>EUR</fee:currency>
C:           <fee:command>transfer</fee:command>
C:         </fee:domain>
C:         <fee:domain>
C:           <fee:name>example.xyz</fee:name>
C:           <fee:command>restore</fee:command>
C:           <fee:period unit="y">1</fee:period>
C:         </fee:domain>
C:       </fee:check>
C:     </extension>
C:     <clTRID>ABC-12345</clTRID>
C:   </command>
C: </epp>

S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:   <response>
S:     <result code="1000">
S:       <msg>Command completed successfully</msg>
S:     </result>
S:     <resData>
S:       <domain:chkData
S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:cd>
S:           <domain:name avail="1">example.com</domain:name>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail="0">example.net</domain:name>
S:           <domain:reason>In use</domain:reason>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail="0">example.org</domain:name>
S:           <domain:reason>In use</domain:reason>
S:         </domain:cd>
S:       </domain:chkData>
S:     </resData>
S:     <extension>
S:       <fee:chkData
S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
S:         <fee:cd
S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
S:           <fee:name>example.com</fee:name>
S:           <fee:currency>USD</fee:currency>
S:           <fee:command phase="sunrise">create</fee:command>
S:           <fee:period unit="y">1</fee:period>
S:           <fee:fee description="Application Fee">5.00</fee:fee>
S:           <fee:fee description="Registration Fee">5.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
S:           <fee:name>example.net</fee:name>
S:           <fee:currency>EUR</fee:currency>
S:           <fee:command phase="claims" subphase="landrush">
S:           create</fee:command>
S:           <fee:period unit="y">2</fee:period>
S:           <fee:fee>5.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
S:           <fee:name>example.org</fee:name>
S:           <fee:currency>EUR</fee:currency>
S:           <fee:command>transfer</fee:command>
S:           <fee:period unit="y">2</fee:period>
S:           <fee:fee description="Transfer Fee">2.50</fee:fee>
S:           <fee:fee description="Renewal Fee">10.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
S:           <fee:name>example.xyz</fee:name>
S:           <fee:currency>GBP</fee:currency>
S:           <fee:command>restore</fee:command>
S:           <fee:period unit="y">1</fee:period>
S:           <fee:fee description="Restore Fee">25</fee:fee>
S:           <fee:fee description="Renewal Fee">5.00</fee:fee>
S:         </fee:cd>
S:       </fee:chkData>
S:     </extension>
S:     <trID>
S:       <clTRID>ABC-12345</clTRID>
S:       <svTRID>54322-XYZ</svTRID>
S:     </trID>
S:   </response>
S: </epp>

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

---

From: Pat Moroney <[email-masked]>
Date: Thu, 1 May 2014 12:03:55 -0600

Another addition I was hoping we could consider is a flag of some sort that
would signal that the fee is somehow special or unusual.
A good example of this would be where a certain tld has different pricing
for 2 character domains then the normal base price.
This would be particularly useful if we have to account for those
differently or perform additional checks in those cases.

I feel that the best place for such a flag would be as an attribute to the
fee:fee element. I'm not sure of the best name for such an element, but as
an example I'll use "special":
<fee:fee description="Renewal Fee" special="0">5.00</fee:fee>
or
<fee:fee description="Renewal Fee" special="1">5.00</fee:fee>
And omission of that attribute would imply that the value is 0.

Another option is that if the base fee is always one of the listed fees and
they are differentiated by their descriptions. The problem I see with that
is it could get messy with different registries utilizing different
descriptions for their fees. Also I could see that a registry could use
something like "Registration Fee" as a description for both premium and non
premium registrations, thus removing the ability to discern if it is a
premium or not.

Let me know if any of this makes sense or if there is a better venue or way
for me to make these suggestions since I am new to this list.

On Thu, May 1, 2014 at 11:12 AM, Gavin Brown <[email-masked]>wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>
>

-- 
-Pat Moroney
SVP of Accounting / Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: Luis Muñoz <[email-masked]>
Date: Thu, 1 May 2014 11:35:27 -0700

On May 1, 2014, at 11:03 AM, Pat Moroney <[email-masked]> wrote:

> Let me know if any of this makes sense or if there is a better venue or way for me to make these suggestions since I am new to this list.

Why does it matter if the price is "special" (or "exceptional" as opposed to "regular")? The reason I ask is that I suspect you intent to convey some other meaning into the transaction.

Perhaps you're thinking about a promotional price that can be valid only during a certain period?

Best regards

-lem

---

From: Seth Goldman <[email-masked]>
Date: Thu, 1 May 2014 14:38:17 -0400

I have heard from at least one registrar that they'd like premium domain
names delineated from non-premium. I'd suggest adding an optional "type"
attribute that can be extended for custom types.

On May 1, 2014 2:35 PM, "Luis Muñoz" <[email-masked]> wrote:
> > Let me know if any of this makes sense or if there is a better venue or
way for me to make these suggestions since I am new to this list.
>
> Why does it matter if the price is "special" (or "exceptional" as opposed
to "regular")? The reason I ask is that I suspect you intent to convey some
other meaning into the transaction.

---

From: Luis Muñoz <[email-masked]>
Date: Thu, 1 May 2014 11:42:36 -0700

On May 1, 2014, at 11:38 AM, Seth Goldman <[email-masked]> wrote:

> I have heard from at least one registrar that they'd like premium domain names delineated from non-premium. I'd suggest adding an optional "type" attribute that can be extended for custom types.

++

-lem

---

From: MICHAEL W YOUNG <[email-masked]>
Date: Thu, 1 May 2014 14:52:08 -0400

Hi Pat,

This sounds to me like you are starting to overlap with a "program" problem.  For example, many of the existing registries support some type of "program identifier" or "token" submitted as an extension during a registration to associate that registration with an existing marketing discount/rebate/specialized pricing.

I don't want to spin this into something overtly complicated, but it seems this extension, since its all about querying fees, could extend to query fees by domain, by "program" as well.

It would be interesting to query a given domain for an answer on which programs its applicable for.  Lets say I am a registrar that signed up for marketing programs (out of registry band) "A1" and program "B2" with the registry operator, instead of keeping track of that in my registrar systems, whenever I go to check pricing on a domain, I would also receive any current programs that are applicable to that domain along with the base pricing I originally queried.  I can then do subsequent lookups on the program pricing if I don't have the program pricing handy, or if the program pricing varies depending on the specific string.

When I registered the domain, I can then opt to submit "A1" or "B2" with the registration, etc based on having been told the relevant "special" or "program" pricing for each.

-Michael

On May 1, 2014, at 2:03 PM, Pat Moroney <[email-masked]> wrote:

> Another addition I was hoping we could consider is a flag of some sort that would signal that the fee is somehow special or unusual.
> A good example of this would be where a certain tld has different pricing for 2 character domains then the normal base price.
> This would be particularly useful if we have to account for those differently or perform additional checks in those cases.
> 
> I feel that the best place for such a flag would be as an attribute to the fee:fee element. I'm not sure of the best name for such an element, but as an example I'll use "special":
> Another option is that if the base fee is always one of the listed fees and they are differentiated by their descriptions. The problem I see with that is it could get messy with different registries utilizing different descriptions for their fees. Also I could see that a registry could use something like "Registration Fee" as a description for both premium and non premium registrations, thus removing the ability to discern if it is a premium or not.
> 
> On Thu, May 1, 2014 at 11:12 AM, Gavin Brown <[email-masked]> wrote:

MICHAEL W YOUNG
[email-masked]

---

From: Luis Muñoz <[email-masked]>
Date: Thu, 1 May 2014 12:05:37 -0700

> It would be interesting to query a given domain for an answer on which programs its applicable for.  Lets say I am a registrar that signed up for marketing programs (out of registry band) "A1" and…

Why not return the pricing associated to each program in the same transaction? That would save on queries and I think it's a fair assumption that server-side looking up the list of programs will also provide the relevant pricing information with the same effort.

Best regards

-lem

---

From: Pat Moroney <[email-masked]>
Date: Thu, 1 May 2014 13:21:30 -0600

Seth, you hit the nail on the head. We currently have to figure out if the
domain is a premium domain name via numerous methods, some of which can
take time or are unreliable. It would be safer to get that information in a
standard way which is guaranteed to be up to date.

A type attribute could work for that nicely.

On Thu, May 1, 2014 at 12:38 PM, Seth Goldman <[email-masked]> wrote:

> > > Let me know if any of this makes sense or if there is a better venue
> or way for me to make these suggestions since I am new to this list.
> >
> > Why does it matter if the price is "special" (or "exceptional" as
> opposed to "regular")? The reason I ask is that I suspect you intent to
> convey some other meaning into the transaction.
> >

---

From: Rubens Kuhl <[email-masked]>
Date: Thu, 1 May 2014 16:41:28 -0300

Recent events showed there is a need for a reliable way of knowing it. 
http://domainincite.com/16534-guy-hit-with-1600-bill-a-month-after-registering-premium-name-for-12-99
http://domainincite.com/16555-101domain-shifts-blame-to-google-as-premium-buyers-offered-50-discount

Rubens

On May 1, 2014, at 4:21 PM, Pat Moroney <[email-masked]> wrote:

> Seth, you hit the nail on the head. We currently have to figure out if the domain is a premium domain name via numerous methods, some of which can take time or are unreliable. It would be safer to get that information in a standard way which is guaranteed to be up to date. 
>

---

From: Seth Goldman <[email-masked]>
Date: Fri, 2 May 2014 12:26:14 -0400

I think this could be modeled by having extensible custom types on each "
*fee"* element, or maybe on each "*cd"* element. I would be hesitant to
embed too much application logic into the protocol, and instead just make
the schema flexible enough to model different scenarios.

On Thu, May 1, 2014 at 3:05 PM, Luis Muñoz <[email-masked]> wrote:

> > It would be interesting to query a given domain for an answer on which
> programs its applicable for.  Lets say I am a registrar that signed up for
> marketing programs (out of registry band) "A1" and program "B2" with the
> registry operator, instead of keeping track of that in my registrar
> systems, whenever I go to check pricing on a domain, I would also receive
> any current programs that are applicable to that domain along with the base
> pricing I originally queried.  I can then do subsequent lookups on the
> program pricing if I don't have the program pricing handy, or if the
> program pricing varies depending on the specific string.
>
> Why not return the pricing associated to each program in the same
> transaction? That would save on queries and I think it's a fair assumption
> that server-side looking up the list of programs will also provide the
> relevant pricing information with the same effort.
>
> Best regards
>
> -lem
>

---

From: Jens Wagner <[email-masked]>
Date: Thu, 08 May 2014 17:19:08 +0200

I'd also be in favour of adding an optional(?) special or type attribute 
or element to the fee extensions, that reflects the price class of 
domains differing from the standard pricing e.g.

*<special>Tier1</special>* or <fee:cd ... *type="Tier1"*>

The extension right now reflects the billing between the registry and a 
registrar. But when dealing with customers or resellers, this would 
limit the flexibility for reseller and retail pricing models. Domains 
are typically sold through a chain:

     REGISTRY -> REGISTRAR (-> RESELLER)* -> CUSTOMER

For registries offering premium domains, it makes sense to limit the 
number of different premium price classes. That way registrars and 
resellers can define their own pricing models for those classes. 
Otherwise registrars and resellers would be limited to fix increments or 
percentage based markups.

A fee check response could look like this:

S:  <fee:cd xmlns:fee="urn:ietf:params:xml:ns:fee-0.5" *type="AAA+"*>
S:    <fee:name>somepremium.tld</fee:name>
S:    <fee:currency>USD</fee:currency>
S:    <fee:command>create</fee:command>
S:    <fee:period unit="y">1</fee:period>
S:    <fee:fee>1234.00</fee:fee>
S:  </fee:cd>

If the registry uses an attribute that reflects the price class, then it 
should also be required on create, renew, transfer and restore. E.g.

C:  <fee:create xmlns:fee="urn:ietf:params:xml:ns:fee-0.4" *type="AAA+"*>
C:    <fee:currency>USD</fee:currency>
C:    <fee:fee>12.00</fee:fee>
C:  </fee:create>

This would also cover the following case: A registry could come up with 
a business model, where the registration fee for premium domains matches 
the standard fee for that TLD, but those premium domains have a higher 
renewal price. Requiring the attribute (that indicates a premium domain) 
for those domains would prevent an accidental premium registration.

Best regards,
- jens

Am 01.05.2014 21:41, schrieb Rubens Kuhl:
> On May 1, 2014, at 4:21 PM, Pat Moroney <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Seth, you hit the nail on the head. We currently have to figure out 
>> if the domain is a premium domain name via numerous methods, some of 
>> which can take time or are unreliable. It would be safer to get that 
>> information in a standard way which is guaranteed to be up to date.
>>
>> On Thu, May 1, 2014 at 12:38 PM, Seth Goldman <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     I have heard from at least one registrar that they'd like premium
>>     domain names delineated from non-premium. I'd suggest adding an
>>     optional "type" attribute that can be extended for custom types.
>>
>>
>>     On May 1, 2014 2:35 PM, "Luis Muñoz" <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     >
>>     >
>>     > On May 1, 2014, at 11:03 AM, Pat Moroney <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     >
>>     > > Let me know if any of this makes sense or if there is a
>>     better venue or way for me to make these suggestions since I am
>>     new to this list.
>>     >
>>     > Why does it matter if the price is "special" (or "exceptional"
>>     as opposed to "regular")? The reason I ask is that I suspect you
>>     intent to convey some other meaning into the transaction.
>>     >
>>     > [email-masked] <mailto:[email-masked]>
>> Name.com <http://Name.com>
>> [email-masked] <mailto:[email-masked]>

-- 
Jens Wagner
Chief Executive Officer
HEXONET GmbH

T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: [email-masked]
W: http://www.hexonet.net

HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany.  CEO & General Manager: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbrücken, VAT-ID: DE-138316882
HEXONET Services Inc., #104 - 7455 132nd Street, Surrey, B.C., V3W 1J8, Canada.  CSO & General Manager: Robert Birkner

This email and any files transmitted are confidential and intended only or the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

---

From: Jens Wagner <[email-masked]>
Date: Thu, 08 May 2014 17:42:10 +0200

Thank you Gavin!

Got a couple of questions regarding the fee extension:

1. Is there are reason, that a client provides the <fee:currency> 
element when sending a query command, e.g. <check>?

2. Do the <fee:domain> elements in <fee:check> need to match the 
<domain:name> elements in <domain:check>?

3. May a <fee:domain> element for a single domain get repeated in 
<domain:check>, e.g. for different periods?
E.g. useful, when providing a [period => price] dropdown in a shoppingcart:

C:         <fee:domain>
C:           <fee:name>example.com</fee:name>
C:           <fee:currency>USD</fee:currency>
C: <fee:command>create</fee:command>
C:           <fee:period unit="y">1</fee:period>
C:         </fee:domain>
C:         <fee:domain>
C:           <fee:name>example.com</fee:name>
C:           <fee:currency>USD</fee:currency>
C: <fee:command>create</fee:command>
C:           <fee:period unit="y">2</fee:period>
C:         </fee:domain>
...
C:         <fee:domain>
C:           <fee:name>example.com</fee:name>
C:           <fee:currency>USD</fee:currency>
C: <fee:command>create</fee:command>
C:           <fee:period unit="y">10</fee:period>
C:         </fee:domain>

Btw, this would not be needed, if supporting price classes.

4. Some registries return an error on <domain:info>, if a different 
registrar manages the domain, so <fee:infData> wouldn't get returned 
either, correct? Does <fee:info> have any advantage over <fee:check>?

5. The EPP <renew> command example should use <fee:renew> instead of 
<fee:create>?

Best,
- jens

---

From: Seth Goldman <[email-masked]>
Date: Thu, 8 May 2014 11:54:51 -0400

I think most/any of these scenarios are possible, depending on the
registry's business logic. For example, perhaps the price returned on an
<info> is different price than on a <check> because the registry has some
special incentive program for existing renewals versus new registrations
(assuming that's allowable under ICANN rules). Same might go for a repeated
<fee:domain> element.

In general, I'd advocate for making the protocol as flexible as possible
for expressing the data (within reason), while leaving the exact semantics
of that data as "server policy". Otherwise you end up embedding a lot of
business logic into the protocol, which then forces registries and
resellers to modify or add extensions when their use case doesn't exactly
match the canonical use case of the spec.

On Thu, May 8, 2014 at 11:42 AM, Jens Wagner <[email-masked]> wrote:

> 1. Is there are reason, that a client provides the <fee:currency> element
> when sending a query command, e.g. <check>?
>
> provreg mailing [email-masked]://www.ietf.org/mailman/listinfo/provreg
>
>

---

From: Pat Moroney <[email-masked]>
Date: Thu, 8 May 2014 10:07:08 -0600

Hi Jens,

I like the optional type attribute being added to the <fee:cd> as well as
required on the <fee:create> if it was set.
Especially if that optional description attribute is added to the <fee:fee>
element as well, which was hinted at in Gavin's email about the new draft.

He had the following example:
S:         <fee:cd
S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">

That, combined with the type attribute, allows a lot of flexability for
registries.
For example, Donuts, if they used this extension, could then return the
following for a premium domain during their Early Access Period day 2:

S:         <fee:cd
S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5" type="BBB+">
S:           <fee:name>example.com</fee:name>
S:           <fee:currency>USD</fee:currency>
S:           <fee:command>create</fee:command>
S:           <fee:period unit="y">1</fee:period>
S:           <fee:fee description="Early Access Fee">2500.00</fee:fee>
S:           <fee:fee description="Registration Fee">66.00</fee:fee>
S:         </fee:cd>

That allows a registrar to recognize that the domain is a premium as well
as there being added fees, and differentiating what those fees are for.

On Thu, May 8, 2014 at 9:19 AM, Jens Wagner <[email-masked]> wrote:

> or element to the fee extensions, that reflects the price class of domains
> differing from the standard pricing e.g.
>
> registrar. But when dealing with customers or resellers, this would limit
> the flexibility for reseller and retail pricing models. Domains are
> typically sold through a chain:
>
> resellers can define their own pricing models for those classes. Otherwise
> registrars and resellers would be limited to fix increments or percentage
> based markups.
>
> This would also cover the following case: A registry could come up with a
> business model, where the registration fee for premium domains matches the
> standard fee for that TLD, but those premium domains have a higher renewal
> price. Requiring the attribute (that indicates a premium domain) for those
> domains would prevent an accidental premium registration.
>
> Best regards,
> - jens
>
>
>  Seth, you hit the nail on the head. We currently have to figure out if
> the domain is a premium domain name via numerous methods, some of which can

---

From: Gavin Brown <[email-masked]>
Date: Thu, 08 May 2014 18:04:42 +0100

The working draft at the URL below has been updated to use this syntax.
There have also been a number of additional changes - please check the
change history and the git changelog for further details.

---

From: Gavin Brown <[email-masked]>
Date: Thu, 08 May 2014 18:06:41 +0100

Sorry, that URL is:

https://github.com/centralnic/epp-fee-extension

---

From: Gavin Brown <[email-masked]>
Date: Thu, 08 May 2014 18:31:48 +0100

> element when sending a query command, e.g. <check>?

This is now optional in commands but is still mandatory in responses.

> <domain:name> elements in <domain:check>?

No: this is implicit in the text but could be made implicit.

> E.g. useful, when providing a [period => price] dropdown in a shoppingcart:

Yes. each <fee:domain> element will be completely independent of the others.

> either, correct? Does <fee:info> have any advantage over <fee:check>?

That's a matter of server policy.

> 5. The EPP <renew> command example should use <fee:renew> instead of

Yes - that's probably a typo :-)

G.

---

From: Gavin Brown <[email-masked]>
Date: Thu, 08 May 2014 18:35:33 +0100

On 08/05/2014 16:54, Seth Goldman wrote:
> for expressing the data (within reason), while leaving the exact
> semantics of that data as "server policy". Otherwise you end up
> embedding a lot of business logic into the protocol, which then forces
> registries and resellers to modify or add extensions when their use case
> doesn't exactly match the canonical use case of the spec.

+1 - that's my objective. This extension needs to be fairly flexible
because I don't want the next registry to come along with a novel
business model to reinvent the wheel.

G.

---

From: Gavin Brown <[email-masked]>
Date: Thu, 08 May 2014 18:55:36 +0100

On 08/05/2014 17:07, Pat Moroney wrote:
> Hi Jens,
> 
> I like the optional type attribute being added to the <fee:cd> as well
> as required on the <fee:create> if it was set.
> Especially if that optional description attribute is added to the
> <fee:fee> element as well, which was hinted at in Gavin's email about
> the new draft.
> 
> That allows a registrar to recognize that the domain is a premium as
> well as there being added fees, and differentiating what those fees are for.

The current working draft includes a "description" attribute on the
<fee:fee> elements. If we're going to add additional syntax to describe
the domain itself, then I think that syntax should be added to the
<fee:name> element, like so:

S:  <fee:cd>
S:    <fee:name class="premium">example.com</fee:name>

The above example uses "class" as the attribute name, but it could just
as easily be "category" or "type" or something similar. The value of the
attribute would be a token, which would presumably come from a set of
possible tokens that the server would provide to clients out-of-band.

Thoughts?

---

From: Pat Moroney <[email-masked]>
Date: Thu, 8 May 2014 12:13:47 -0600

Hi Gavin,

That works for me. I am indifferent in the terminology: class vs type vs
category.

Thanks,

---

From: Jens Wagner <[email-masked]>
Date: Thu, 08 May 2014 23:19:55 +0200

+1
That would work, but according to the draft, EPP clients provide the 
<fee:name> element on <check> requests only.
Would also need the attribute for <domain:create>, renew, transfer and 
so on.
Maybe we could use an element e.g. <class>, instead of an attribute? Or 
also assign the attribute to the <fee:create>, <fee:renew> ... elements?

Best,
- jens

Am 08.05.2014 20:13, schrieb Pat Moroney:
> Hi Gavin,
>
> That works for me. I am indifferent in the terminology: class vs type 
> vs category.
>
> Thanks,
>
>
> On Thu, May 8, 2014 at 11:55 AM, Gavin Brown 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > S:           <fee:name>example.com <http://example.com></fee:name>
>     S:    <fee:name class="premium">example.com
>     <http://example.com></fee:name>

---

From: Gavin Brown <[email-masked]>
Date: Thu, 08 May 2014 22:34:04 +0100

> also assign the attribute to the <fee:create>, <fee:renew> ... elements?

Yes, I realised that shortly after I sent the email. It needs to be an
element rather than an attribute.

<fee:type> perhaps?

G.

---

From: Jens Wagner <[email-masked]>
Date: Thu, 08 May 2014 23:43:27 +0200

Yes, <fee:type> or <fee:class>, I don't have any favorites.

Thank you,
- jens