Re: New Version Notification for draft-brown-epp-fees-01.txt
Pat Moroney <[email protected]> Thu, 8 May 2014 10:07:08 -0600
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <CADJsPYyYiR3FZH-HNcw=4sgw9E0uCfR_orD4TAVPfDvPQSVySQ@mail.gmail.com> |
--===============0402083228678737583== Content-Type: multipart/alternative; boundary=001a11c26a424f55b304f8e5ac6b --001a11c26a424f55b304f8e5ac6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D"urn:ietf:params:xml:ns:fee-0.5"> S: <fee:fee description=3D"Application Fee">5.00</fee:fee> S: <fee:fee description=3D"Registration Fee">5.00</fee:fee> S: </fee:cd> 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=3D"urn:ietf:params:xml:ns:fee-0.5" type=3D"BBB+"> S: <fee:name>example.com</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 description=3D"Early Access Fee">2500.00</fee:fee> S: <fee:fee description=3D"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 protected]> wrote: > 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 domain= s > 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 > 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. Otherwis= e > 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=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 > 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 a > business model, where the registration fee for premium domains matches th= e > standard fee for that TLD, but those premium domains have a higher renewa= l > price. Requiring the attribute (that indicates a premium domain) for thos= e > 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-regist= ering-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 protected]> 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 c= an > 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 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=C3=B1oz" <[email protected]> wrote: >> > >> > >> > On May 1, 2014, at 11:03 AM, Pat Moroney <[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] >> > https://www.ietf.org/mailman/listinfo/provreg >> >> > > > -- > -Pat Moroney > SVP of Accounting / Sr. Software Engineer > Name.com > http://www.youtube.com/watch?v=3DV1GKGXXF12c > 720-663-0025 > > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg > > > > > _______________________________________________ > provreg mailing [email protected]://www.ietf.org/mailman/listinfo= /provreg > > > > -- > 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=C3=BCcken, VAT-ID: DE-1= 38316882 > 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 disseminati= on is strictly prohibited. If you have received this email in error, please= notify the sender immediately and permanently delete this email with any f= iles that may be attached. > > > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg > > --=20 -Pat Moroney SVP of Accounting / Sr. Software Engineer Name.com http://www.youtube.com/watch?v=3DV1GKGXXF12c 720-663-0025 --001a11c26a424f55b304f8e5ac6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Jens,<div><br></div><div>I like the optional type attri= bute being added to the <fee:cd> as well as required on the <fee:c= reate> if it was set.</div><div>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.</div> <div><br></div><div>He had the following example:</div><div><span style=3D"= font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2=A0 =C2=A0 =C2=A0= <fee:cd</span><br style=3D"font-family:arial,sans-serif;font-size:13px"= ><span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:</span><span sty= le=3D"font-family:arial,sans-serif;font-size:13px">xml:ns:fee-0.5">= </span><br style=3D"font-family:arial,sans-serif;font-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di= v><div><span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Application= Fee">5.00</fee:fee></span><br style=3D"font-family:arial,san= s-serif;font-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Registration Fee&q= uot;>5.00</fee:fee></span><br style=3D"font-family:arial,sans-seri= f;font-size:13px"><span style=3D"font-family:arial,sans-serif;font-size:13p= x">S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd></span><br> </div><div><br></div><div>That, combined with the type attribute, allows a = lot of flexability for registries.</div><div>For example, Donuts, if they u= sed this extension, could then return the following for a premium domain du= ring their Early Access Period day 2:</div> <div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span= ></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">S: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd</span><br style=3D"font-family:arial= ,sans-serif;font-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:</span><span sty= le=3D"font-family:arial,sans-serif;font-size:13px">xml:ns:fee-0.5" typ= e=3D"BBB+"></span><br style=3D"font-family:arial,sans-serif;fo= nt-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:name></span><a href=3D"http://example.c= om/" target=3D"_blank" style=3D"font-family:arial,sans-serif;font-size:13px= ">example.com</a><span style=3D"font-family:arial,sans-serif;font-size:13px= "></fee:</span><span style=3D"font-family:arial,sans-serif;font-size:13p= x">name></span><br style=3D"font-family:arial,sans-serif;font-size:13px"= > <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>USD</fee:</span><span style= =3D"font-family:arial,sans-serif;font-size:13px">currency></span><br sty= le=3D"font-family:arial,sans-serif;font-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>create</fee:</span><span sty= le=3D"font-family:arial,sans-serif;font-size:13px">command></span><br st= yle=3D"font-family:arial,sans-serif;font-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y">1</fee:p= eriod></span><br style=3D"font-family:arial,sans-serif;font-size:13px"><= span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Early Access Fee"= ;>2500.00</fee:fee></span><br style=3D"font-family:arial,sans-seri= f;font-size:13px"> <span style=3D"font-family:arial,sans-serif;font-size:13px">S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Registration Fee&q= uot;>66.00</fee:fee></span><br style=3D"font-family:arial,sans-ser= if;font-size:13px"><span style=3D"font-family:arial,sans-serif;font-size:13= px">S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd></span><br> </div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>= </span></div><div><font face=3D"arial, sans-serif">That allows a registrar = to recognize that the domain is a premium as well as there being added fees= , and=C2=A0differentiating=C2=A0what those fees=C2=A0are for.</font></div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,= May 8, 2014 at 9:19 AM, Jens Wagner <span dir=3D"ltr"><<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>></span>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =20 =20 =20 <div bgcolor=3D"#FFFFFF" text=3D"#000000"> <div>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:c= d ... <b>type=3D"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>=C2=A0 =C2=A0 REGISTRY -> REGISTRAR (-> RESELLER)* -> CU= STOMER</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:=C2=A0 <fee:cd xmlns:fee=3D"urn:ietf:params:xml:ns:fee-= 0.5" <b>type=3D"AAA+"</b>></tt><tt><br> </tt><tt>S:=C2=A0=C2=A0=C2=A0 <fee:name>somepremium.tld</fee= :name></tt><div class=3D""><tt><br> </tt><tt>S:=C2=A0=C2=A0=C2=A0 <fee:currency>USD</fee:currenc= y></tt><tt><br> </tt></div><tt>S:=C2=A0=C2=A0=C2=A0 <fee:command>create</fee= :command></tt><div class=3D""><tt><br> </tt><tt>S:=C2=A0=C2=A0=C2=A0 <fee:period unit=3D"y">= 1</fee:period></tt><tt><br> </tt></div><tt>S:=C2=A0=C2=A0=C2=A0 <fee:fee>1234.00</fee:fe= e></tt><tt><br> </tt><tt>S:=C2=A0 </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:=C2=A0 <fee:create xmlns:fee=3D"urn:ietf:params:xml:ns:= fee-0.4" <b>type=3D"AAA+"</b>></tt><div class=3D""><tt><br> </tt><tt>C:=C2=A0=C2=A0=C2=A0 <fee:currency>USD</fee:currenc= y></tt><tt><br> </tt></div><tt>C:=C2=A0=C2=A0=C2=A0 <fee:fee>12.00</fee:fee&= gt;</tt><tt><br> </tt><tt>C:=C2=A0 </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><div><div class=3D"h5"> <blockquote type=3D"cite"> =20 <div><br> </div> Recent events showed there is a need for a reliable way of knowing it.=C2=A0 <div><a href=3D"http://domainincite.com/16534-guy-hit-with-1600-bill-= a-month-after-registering-premium-name-for-12-99" target=3D"_blank">http://= domainincite.com/16534-guy-hit-with-1600-bill-a-month-after-registering-pre= mium-name-for-12-99</a></div> <div><a href=3D"http://domainincite.com/16555-101domain-shifts-blame-= to-google-as-premium-buyers-offered-50-discount" target=3D"_blank">http://d= omainincite.com/16555-101domain-shifts-blame-to-google-as-premium-buyers-of= fered-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 href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:</div> <br> <blockquote type=3D"cite"> <div dir=3D"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.=C2=A0 <div> <br> </div> <div>A type attribute could work for that nicely.</div> </div> <div class=3D"gmail_extra"><br> <br> <div class=3D"gmail_quote">On Thu, May 1, 2014 at 12:38 PM, Seth Goldman <span dir=3D"ltr"><<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> <p dir=3D"ltr">I have heard from at least one registrar that they'd like premium domain names delineated from non-premium. I'd suggest adding a= n optional "type" attribute that can be exten= ded for custom types.</p> <div><br> </div> <div> <div>On May 1, 2014 2:35 PM, "Luis Mu=C3=B1oz" <<a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a>> wrote:<br> ><br> ><br> > On May 1, 2014, at 11:03 AM, Pat Moroney <<a href=3D"mailto:[email protected]" target=3D"= _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 su= spect you intent to convey some other meaning into the transaction.<br> ><br> > Perhaps you're thinking about a promotiona= l price that can be valid only during a certain period?<br> ><br> > Best regards<br> ><br> > -lem<br> ><br> </div> </div> <div> > _______________________________________________<br> > provreg mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo= /provreg" target=3D"_blank">https://www.ietf.org/mailman/listinfo/provreg</= a><br> </div> <div><br> </div> </blockquote> </div> <br> <br clear=3D"all"> <div><br> </div> -- <br> <div dir=3D"ltr"> <div>-Pat Moroney</div> <div>SVP of Accounting / Sr. Software Engineer</div> <div><a href=3D"http://Name.com" target=3D"_blank">Name.c= om</a></div> <div><a href=3D"http://www.youtube.com/watch?v=3DV1GKGXXF= 12c" target=3D"_blank">http://www.youtube.com/watch?v=3DV1GKGXXF12c</a><br> </div> <div>720-663-0025</div> <div><br> </div> </div> </div> _______________________________________________<br> provreg mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">provreg= @ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/provreg" tar= get=3D"_blank">https://www.ietf.org/mailman/listinfo/provreg</a><br> </blockquote> </div> <br> </div> </div> <br> <fieldset></fieldset> <br> <pre>_______________________________________________ provreg mailing list <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a> <a href=3D"https://www.ietf.org/mailman/listinfo/provreg" target=3D"_blank"= >https://www.ietf.org/mailman/listinfo/provreg</a> </pre> </blockquote> <br> <br> </div></div><pre cols=3D"72">--=20 Jens Wagner Chief Executive Officer HEXONET GmbH T: +49 6841 69 84 0 F: +49 6841 69 84 199 E: <a href=3D"mailto:[email protected]" target=3D"_blank">jwagner@hexonet= .net</a> W: <a href=3D"http://www.hexonet.net" target=3D"_blank">http://www.hexonet.= net</a> HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany. CEO & General Man= ager: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbr=C3=BCcken, VAT-ID: DE= -138316882 HEXONET Services Inc., #104 - 7455 132nd Street, Surrey, B.C., V3W 1J8, Can= ada. 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, an= y use, copying, transmission, distribution, or other forms of dissemination= is strictly prohibited. If you have received this email in error, please n= otify the sender immediately and permanently delete this email with any fil= es that may be attached. </pre> </div> <br>_______________________________________________<br> provreg mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/provreg" target=3D"_blank"= >https://www.ietf.org/mailman/listinfo/provreg</a><br> <br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div dir= =3D"ltr"><div>-Pat Moroney</div><div>SVP of Accounting / Sr. Software Engin= eer</div><div>Name.com</div><div><div><a href=3D"http://www.youtube.com/wat= ch?v=3DV1GKGXXF12c" target=3D"_blank">http://www.youtube.com/watch?v=3DV1GK= GXXF12c</a><br> </div></div><div>720-663-0025</div><div><br></div></div> </div> --001a11c26a424f55b304f8e5ac6b-- --===============0402083228678737583== 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 --===============0402083228678737583==--