Re: New Version Notification for draft-brown-epp-fees-01.txt
Jens Wagner <[email protected]> Thu, 08 May 2014 17:19:08 +0200
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============2666760109599687631==
Content-Type: multipart/alternative;
boundary="------------070505060509090001000104"
This is a multi-part message in MIME format.
--------------070505060509090001000104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
I'd also be in favour of adding an optional(?) special or type attribute=20
or element to the fee extensions, that reflects the price class of=20
domains differing from the standard pricing e.g.
*<special>Tier1</special>* or <fee:cd ... *type=3D"Tier1"*>
The extension right now reflects the billing between the registry and a=20
registrar. But when dealing with customers or resellers, this would=20
limit the flexibility for reseller and retail pricing models. Domains=20
are typically sold through a chain:
REGISTRY -> REGISTRAR (-> RESELLER)* -> CUSTOMER
For registries offering premium domains, it makes sense to limit the=20
number of different premium price classes. That way registrars and=20
resellers can define their own pricing models for those classes.=20
Otherwise registrars and resellers would be limited to fix increments or=20
percentage based markups.
A fee check response could look like this:
S: <fee:cd xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5" *type=3D"AAA+"*>
S: <fee:name>somepremium.tld</fee:name>
S: <fee:currency>USD</fee:currency>
S: <fee:command>create</fee:command>
S: <fee:period unit=3D"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=20
should also be required on create, renew, transfer and restore. E.g.
C: <fee:create xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.4" *type=3D"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=20
a business model, where the registration fee for premium domains matches=20
the standard fee for that TLD, but those premium domains have a higher=20
renewal price. Requiring the attribute (that indicates a premium domain)=20
for those domains would prevent an accidental premium registration.
Best regards,
- jens
Am 01.05.2014 21:41, schrieb Rubens Kuhl:
>
> 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-regi=
stering-premium-name-for-12-99
> http://domainincite.com/16555-101domain-shifts-blame-to-google-as-premi=
um-buyers-offered-50-discount
>
>
>
> Rubens
>
> On May 1, 2014, at 4:21 PM, Pat Moroney <[email protected]=20
> <mailto:[email protected]>> wrote:
>
>> Seth, you hit the nail on the head. We currently have to figure out=20
>> if the domain is a premium domain name via numerous methods, some of=20
>> which can take time or are unreliable. It would be safer to get that=20
>> 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 protected]=20
>> <mailto:[email protected]>> 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=F1oz" <[email protected]
>> <mailto:[email protected]>> wrote:
>> >
>> >
>> > On May 1, 2014, at 11:03 AM, Pat Moroney <[email protected]
>> <mailto:[email protected]>> 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
>> >
>> > _______________________________________________
>> > provreg mailing list
>> > [email protected] <mailto:[email protected]>
>> > https://www.ietf.org/mailman/listinfo/provreg
>>
>>
>>
>>
>> --=20
>> -Pat Moroney
>> SVP of Accounting / Sr. Software Engineer
>> Name.com <http://Name.com>
>> http://www.youtube.com/watch?v=3DV1GKGXXF12c
>> 720-663-0025
>>
>> _______________________________________________
>> provreg mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/provreg
>
>
>
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
--=20
Jens Wagner
Chief Executive Officer
HEXONET GmbH
T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: [email protected]
W: http://www.hexonet.net
HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany. CEO & General Manag=
er: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbr=FCcken, VAT-ID: DE-13=
8316882
HEXONET Services Inc., #104 - 7455 132nd Street, Surrey, B.C., V3W 1J8, C=
anada. CSO & General Manager: Robert Birkner
This email and any files transmitted are confidential and intended only o=
r the person(s) directly addressed. If you are not the intended recipient=
, any use, copying, transmission, distribution, or other forms of dissemi=
nation is strictly prohibited. If you have received this email in error, =
please notify the sender immediately and permanently delete this email wi=
th any files that may be attached.
--------------070505060509090001000104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
<b><tt><special>Tier1</special></tt></b> or <tt><fee:cd
... <b>type="Tier1"</b>></tt><br>
<br>
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:<br>
<br>
<tt> REGISTRY -> REGISTRAR (-> RESELLER)* -> CUSTOMER</tt><br>
<br>
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.<br>
<br>
A fee check response could look like this:<br>
<br>
<tt>S: <fee:cd xmlns:fee="urn:ietf:params:xml:ns:fee-0.5" <b>type="AAA+"</b>></tt><tt><br>
</tt><tt>S: <fee:name>somepremium.tld</fee:name></tt><tt><br>
</tt><tt>S: <fee:currency>USD</fee:currency></tt><tt><br>
</tt><tt>S: <fee:command>create</fee:command></tt><tt><br>
</tt><tt>S: <fee:period unit="y">1</fee:period></tt><tt><br>
</tt><tt>S: <fee:fee>1234.00</fee:fee></tt><tt><br>
</tt><tt>S: </fee:cd></tt><br>
<br>
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.<br>
<br>
<tt>C: <fee:create xmlns:fee="urn:ietf:params:xml:ns:fee-0.4"
<b>type="AAA+"</b>></tt><tt><br>
</tt><tt>C: <fee:currency>USD</fee:currency></tt><tt><br>
</tt><tt>C: <fee:fee>12.00</fee:fee></tt><tt><br>
</tt><tt>C: </fee:create></tt><tt><br>
</tt><br>
<br>
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.<br>
<br>
Best regards,<br>
- jens<br>
<br>
<br>
Am 01.05.2014 21:41, schrieb Rubens Kuhl:<br>
</div>
<blockquote cite="mid:[email protected]"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><br>
</div>
Recent events showed there is a need for a reliable way of knowing
it.
<div><a moz-do-not-send="true"
href="http://domainincite.com/16534-guy-hit-with-1600-bill-a-month-after-registering-premium-name-for-12-99">http://domainincite.com/16534-guy-hit-with-1600-bill-a-month-after-registering-premium-name-for-12-99</a></div>
<div><a moz-do-not-send="true"
href="http://domainincite.com/16555-101domain-shifts-blame-to-google-as-premium-buyers-offered-50-discount">http://domainincite.com/16555-101domain-shifts-blame-to-google-as-premium-buyers-offered-50-discount</a></div>
<div><br>
</div>
<div><br>
<div><br>
</div>
<div>Rubens</div>
<div><br>
<div>
<div>On May 1, 2014, at 4:21 PM, Pat Moroney <<a
moz-do-not-send="true" href="mailto:[email protected]">[email protected]</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">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.
<div>
<br>
</div>
<div>A type attribute could work for that nicely.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, May 1, 2014 at 12:38
PM, Seth Goldman <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:[email protected]" target="_blank">[email protected]</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">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.</p>
<div><br class="webkit-block-placeholder">
</div>
<div>
<div class="h5">On May 1, 2014 2:35 PM, "Luis
Muñoz" <<a moz-do-not-send="true"
href="mailto:[email protected]" target="_blank">[email protected]</a>>
wrote:<br>
><br>
><br>
> On May 1, 2014, at 11:03 AM, Pat Moroney
<<a moz-do-not-send="true"
href="mailto:[email protected]"
target="_blank">[email protected]</a>>
wrote:<br>
><br>
> > 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.<br>
><br>
> 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.<br>
><br>
> Perhaps you're thinking about a promotional
price that can be valid only during a certain
period?<br>
><br>
> Best regards<br>
><br>
> -lem<br>
><br>
</div>
</div>
<div class="">
>
_______________________________________________<br>
> provreg mailing list<br>
> <a moz-do-not-send="true"
href="mailto:[email protected]" target="_blank">[email protected]</a><br>
> <a moz-do-not-send="true"
href="https://www.ietf.org/mailman/listinfo/provreg"
target="_blank">https://www.ietf.org/mailman/listinfo/provreg</a><br>
</div>
<div><br class="webkit-block-placeholder">
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div>-Pat Moroney</div>
<div>SVP of Accounting / Sr. Software Engineer</div>
<div><a moz-do-not-send="true" href="http://Name.com">Name.com</a></div>
<div><a moz-do-not-send="true"
href="http://www.youtube.com/watch?v=V1GKGXXF12c"
target="_blank">http://www.youtube.com/watch?v=V1GKGXXF12c</a><br>
</div>
<div>720-663-0025</div>
<div><br>
</div>
</div>
</div>
_______________________________________________<br>
provreg mailing list<br>
<a moz-do-not-send="true" href="mailto:[email protected]">[email protected]</a><br>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/provreg">https://www.ietf.org/mailman/listinfo/provreg</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
provreg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/provreg">https://www.ietf.org/mailman/listinfo/provreg</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Jens Wagner
Chief Executive Officer
HEXONET GmbH
T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a>
W: <a class="moz-txt-link-freetext" href="http://www.hexonet.net">http://www.hexonet.net</a>
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.
</pre>
</body>
</html>
--------------070505060509090001000104--
--===============2666760109599687631==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
--===============2666760109599687631==--