From nobody Thu May 1 10:12:32 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA201A6F78 for ; Thu, 1 May 2014 10:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdx1hC6A216R for ; Thu, 1 May 2014 10:12:28 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id 188D71A6FA9 for ; Thu, 1 May 2014 10:12:27 -0700 (PDT) Received: from [192.168.43.58] (unknown [31.68.74.148]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 4053A45C04; Thu, 1 May 2014 17:12:24 +0000 (UTC) Message-ID: <53628077.8070402@centralnic.com> Date: Thu, 01 May 2014 18:12:23 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Gould, James" , Klaus Malorny , "provreg@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4mKsfG7MMLaS9qggucPauwx5jJj8sjnu8" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/7gjvC2ihkfYgJSlP5CM7ZldEyvs Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 17:12:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4mKsfG7MMLaS9qggucPauwx5jJj8sjnu8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks to all for the feedback. I am working on a revised draft that will use a single element in commands and a single element in responses. Here are some example commands and responses: let me know what you think.= Thanks, C: C: C: C: C: C: example.com C: example.net C: example.org C: C: C: C: C: C: example.com C: USD C: create C: 1 C: C: C: example.net C: EUR C: C: create C: 2 C: C: C: example.org C: EUR C: transfer C: C: C: example.xyz C: restore C: 1 C: C: C: C: ABC-12345 C: C: S: S: S: S: S: Command completed successfully S: S: S: S: S: example.com S: S: S: example.net S: In use S: S: S: example.org S: In use S: S: S: S: S: S: S: example.com S: USD S: create S: 1 S: 5.00 S: 5.00 S: S: S: example.net S: EUR S: S: create S: 2 S: 5.00 S: S: S: example.org S: EUR S: transfer S: 2 S: 2.50 S: 10.00 S: S: S: example.xyz S: GBP S: restore S: 1 S: 25 S: 5.00 S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: --=20 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. --4mKsfG7MMLaS9qggucPauwx5jJj8sjnu8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNigHcACgkQ6H45IPkjtM63sQCfSQk3Uknr56sbYCMBELLcMKOA 4eIAnRjvDOXUKpAWGqF+ZT+nnA04OE0X =wn/o -----END PGP SIGNATURE----- --4mKsfG7MMLaS9qggucPauwx5jJj8sjnu8-- From nobody Thu May 1 11:04:03 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30D11A700F for ; Thu, 1 May 2014 11:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGxplJYUfwIQ for ; Thu, 1 May 2014 11:03:58 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF51A700C for ; Thu, 1 May 2014 11:03:57 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so1153640wiw.3 for ; Thu, 01 May 2014 11:03:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GqkHcOBCzjtc4Ho4mk5tjcrbpEDW/Kti5t8pIpFp2OU=; b=eSZJVcXh6xDjjQAQY07kg5iZeOX0DipeJh3Igqr0pM2ryQhSej72aoJ15iO8NUgEvo alARVg2Tc2X1FhJFvXgeLEEtF9Hp295uYOiIgAcFs5MDujoee1b2PJgHWwCRrxd9Nylf ydFJSU1EhGT2R9aOwCEowBGtDzQAoDpcn4Tzi2P2rzBra70NXyFqjCG495qJ/b4FKaHu Yq1Qk1RJrRe6C71uICHh5EJ7Yi6Yy3Xvab/hpRxmBbzTyjJoE2aR4TlUC0eyUsYbnWzc 9Mx+/68Bauf9hpGQzpZCH2GPoSEl5h6TxaRMuonBIi2iBYTwuctZ9WpsIJBkm28ix/FC EkVw== X-Gm-Message-State: ALoCoQnmO+ecK+QHTLChUq8xG1ew0rROfoaL9LmISonZ4SQmTopqsAudbaEQewKwpuVPbGMAo4U6 MIME-Version: 1.0 X-Received: by 10.194.205.161 with SMTP id lh1mr9928978wjc.40.1398967435242; Thu, 01 May 2014 11:03:55 -0700 (PDT) Received: by 10.194.22.9 with HTTP; Thu, 1 May 2014 11:03:55 -0700 (PDT) In-Reply-To: <53628077.8070402@centralnic.com> References: <53628077.8070402@centralnic.com> Date: Thu, 1 May 2014 12:03:55 -0600 Message-ID: From: Pat Moroney To: Gavin Brown Content-Type: multipart/alternative; boundary=047d7b6d950207bca204f85a7d9c Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/MdMUK-8dkSZlTfVeoI4DlC7qPfM Cc: "provreg@ietf.org" Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:04:01 -0000 --047d7b6d950207bca204f85a7d9c Content-Type: text/plain; charset=UTF-8 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": 5.00 or 5.00 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 wrote: > Thanks to all for the feedback. I am working on a revised draft that > will use a single element in commands and a single > element in responses. > > Here are some example commands and responses: let me know what you think. > > Thanks, > > C: > C: > C: > C: > C: C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > C: example.com > C: example.net > C: example.org > C: > C: > C: > C: C: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > C: > C: example.com > C: USD > C: create > C: 1 > C: > C: > C: example.net > C: EUR > C: > C: create > C: 2 > C: > C: > C: example.org > C: EUR > C: transfer > C: > C: > C: example.xyz > C: restore > C: 1 > C: > C: > C: > C: ABC-12345 > C: > C: > > S: > S: > S: > S: > S: Command completed successfully > S: > S: > S: S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > S: > S: example.com > S: > S: > S: example.net > S: In use > S: > S: > S: example.org > S: In use > S: > S: > S: > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.com > S: USD > S: create > S: 1 > S: 5.00 > S: 5.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.net > S: EUR > S: > S: create > S: 2 > S: 5.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.org > S: EUR > S: transfer > S: 2 > S: 2.50 > S: 10.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.xyz > S: GBP > S: restore > S: 1 > S: 25 > S: 5.00 > S: > S: > S: > S: > S: ABC-12345 > S: 54322-XYZ > S: > S: > S: > > -- > 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. > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > 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 --047d7b6d950207bca204f85a7d9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.<= div>A good example of this would be where a certain tld has different prici= ng for 2 character domains then the normal base price.
This would be particularly useful if we have to account for those diff= erently or perform additional checks in those cases.

I feel that the best place for such a flag would be as an attribute to t= he 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=3D"Renewal Fee" special=3D"0&qu= ot;>5.00</fee:fee>
or
<fee:fee descript= ion=3D"Renewal Fee" special=3D"1">5.00</fee:fee&g= t;
And omission of that attribute would imply that the value is 0.
<= div>
Another option is that if the base fee is always one of = the listed fees and they are differentiated by their descriptions. The prob= lem I see with that is it could get messy with different registries utilizi= ng 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 di= scern 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 thi= s list.



On Thu, May 1, 2014 at 11:12 AM, Gavin Brown <gavin.brown@centra= lnic.com> wrote:
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=3D"1.0" encoding=3D"utf-8" standalo= ne=3D"no"?>
C: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
C: =C2=A0 <command>
C: =C2=A0 =C2=A0 <check>
C: =C2=A0 =C2=A0 =C2=A0 <domain:check
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:domain=3D"urn:ietf:params:xml:ns:= domain-1.0">
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:name>example.com</domain:name>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:name>example.net</domain:name>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:name>example.org</domain:name>
C: =C2=A0 =C2=A0 =C2=A0 </domain:check>
C: =C2=A0 =C2=A0 </check>
C: =C2=A0 =C2=A0 <extension>
C: =C2=A0 =C2=A0 =C2=A0 <fee:check
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml:ns:fee= -0.5">
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.com</fee:name>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>USD</fee:curre= ncy>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command phase=3D"sunrise= ">create</fee:command>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;1</fee:period>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.net</fee:name>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>EUR</fee:curre= ncy>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command phase=3D"claims&= quot; subphase=3D"landrush">
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 create</fee:command>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;2</fee:name>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.org</fee:name>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>EUR</fee:curre= ncy>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>transfer</fee:c= ommand>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.xyz</fee:n= ame>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>restore</fee:co= mmand>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;1</fee:period>
C: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:domain>
C: =C2=A0 =C2=A0 =C2=A0 </fee:check>
C: =C2=A0 =C2=A0 </extension>
C: =C2=A0 =C2=A0 <clTRID>ABC-12345</clTRID>
C: =C2=A0 </command>
C: </epp>

S: <?xml version=3D"1.0" encoding=3D"utf-8" standalo= ne=3D"no"?>
S: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
S: =C2=A0 <response>
S: =C2=A0 =C2=A0 <result code=3D"1000">
S: =C2=A0 =C2=A0 =C2=A0 <msg>Command completed successfully</msg&g= t;
S: =C2=A0 =C2=A0 </result>
S: =C2=A0 =C2=A0 <resData>
S: =C2=A0 =C2=A0 =C2=A0 <domain:chkData
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:domain=3D"urn:ietf:params:xml:ns:= domain-1.0">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:name avail=3D"1"= >example.com</do= main:name>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </domain:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:name avail=3D"0"= >example.net</do= main:name>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:reason>In use</domai= n:reason>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </domain:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:name avail=3D"0"= >example.org</do= main:name>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <domain:reason>In use</domai= n:reason>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </domain:cd>
S: =C2=A0 =C2=A0 =C2=A0 </domain:chkData>
S: =C2=A0 =C2=A0 </resData>
S: =C2=A0 =C2=A0 <extension>
S: =C2=A0 =C2=A0 =C2=A0 <fee:chkData
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml:ns:fee= -0.5">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml= :ns:fee-0.5">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.com</fee:name>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>USD</fee:curre= ncy>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command phase=3D"sunrise= ">create</fee:command>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;1</fee:period>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Appli= cation Fee">5.00</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Regis= tration Fee">5.00</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml= :ns:fee-0.5">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.net</fee:name>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>EUR</fee:curre= ncy>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command phase=3D"claims&= quot; subphase=3D"landrush">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 create</fee:command>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;2</fee:period>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee>5.00</fee:fee> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml= :ns:fee-0.5">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.org</fee:name>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>EUR</fee:curre= ncy>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>transfer</fee:c= ommand>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;2</fee:period>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Trans= fer Fee">2.50</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Renew= al Fee">10.00</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml= :ns:fee-0.5">
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.xyz</fee:n= ame>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>GBP</fee:curre= ncy>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>restore</fee:co= mmand>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y"&g= t;1</fee:period>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Resto= re Fee">25</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Renew= al Fee">5.00</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>
S: =C2=A0 =C2=A0 =C2=A0 </fee:chkData>
S: =C2=A0 =C2=A0 </extension>
S: =C2=A0 =C2=A0 <trID>
S: =C2=A0 =C2=A0 =C2=A0 <clTRID>ABC-12345</clTRID>
S: =C2=A0 =C2=A0 =C2=A0 <svTRID>54322-XYZ</svTRID>
S: =C2=A0 =C2=A0 </trID>
S: =C2=A0 </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.centr= alnic.com/

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


_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg




--
-Pat Moroney
SVP of Accounting / Sr. Software Engin= eer
Name.com
720-663-0025

--047d7b6d950207bca204f85a7d9c-- From nobody Thu May 1 11:35:48 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF2E1A0919 for ; Thu, 1 May 2014 11:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8xMFuLto-uj for ; Thu, 1 May 2014 11:35:46 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 875D31A08B3 for ; Thu, 1 May 2014 11:35:46 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by mx.ams1.isc.org (Postfix) with ESMTP id 539252383F6; Thu, 1 May 2014 18:35:34 +0000 (UTC) (envelope-from lem@isc.org) Received: from macbookprolem.lem (ip68-101-126-84.oc.oc.cox.net [68.101.126.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 27255216C25; Thu, 1 May 2014 18:35:33 +0000 (UTC) (envelope-from lem@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Thu, 1 May 2014 11:35:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53628077.8070402@centralnic.com> To: Pat Moroney X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/84NIlgoKXo0fGR-ZxMkUk_Htsb0 Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:35:47 -0000 On May 1, 2014, at 11:03 AM, Pat Moroney 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 nobody Thu May 1 11:38:22 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362D41A7000 for ; Thu, 1 May 2014 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhsIjnCJ9Msq for ; Thu, 1 May 2014 11:38:20 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 20BB41A6F8C for ; Thu, 1 May 2014 11:38:20 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ik5so4281945vcb.4 for ; Thu, 01 May 2014 11:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lgb6ry9iBUjEV/OaK24NtZW7UUfP6EF8kUkbQDD22Ss=; b=p5D/nH3z3NMH3lvQNxDWHcswxPPs/Z9txEmnbVrpd/YLsGNtZkv/1EjNfeb7N/3xlG krZeMDEQLelVm96of3mSmCULkueeAx6Q/9iBjnaWNoSC5ZCA4gkszee2grARuSCLH6Hi Th3XJFiIH+kRPtjZ2u38mOAzfUXTEqJihXp5JlAjZ3ay8xrTATwG4ieyQBu28GQ3rbRb c6nfxdBeb32UTU/P6konlAZTCc5hqCd31wm/soQj+yDq2iPUSXgkLX7lovea8JjXfdIV V0kEoa+2x/cilDYwKgfxUUSflRVaZE5psiCQK59hsuuDL3Nwoa+5lx4iWFQWOYaslVZe gkAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Lgb6ry9iBUjEV/OaK24NtZW7UUfP6EF8kUkbQDD22Ss=; b=gYLgHA2bVWrT0VYR2bNzMD4j9UeVmrGOtaEGK0tlnP8eeBgFULWTj+Qa7pAjKVBjZX RUHcY2oyOQS4VM9RIEu+VMcqKW5sP7QAWJaFNgl+D1Mvsn3emcn5V2lINrdSSAWwTh1q tH5XkM/cVJIp54QPRthu7vz6K0v6oypqGdLK6hmJferzYLdGwDROY4i5fVLm+VNhi2A9 z4zYWAYItt/ghBcGQcV9qGv2AmX1kIVU1kmDxUJDgh1XHiyEau+l8OfU85mX8TaEckbv zRKS0cf1IDbuT3GQCwuCxHJB12pG7GyqlHbkT90Irl+Wn7jB4uHYXDZtRu8epCvpOTGb 7zlQ== X-Gm-Message-State: ALoCoQklwPG504Nq9lmdjZxlhJdutyghNmK0cQ94lu21Jo8eKVVhKhh6qw+fq1/G7TAgJ4utX5Bi MIME-Version: 1.0 X-Received: by 10.52.15.226 with SMTP id a2mr662004vdd.69.1398969497933; Thu, 01 May 2014 11:38:17 -0700 (PDT) Received: by 10.52.117.171 with HTTP; Thu, 1 May 2014 11:38:17 -0700 (PDT) Received: by 10.52.117.171 with HTTP; Thu, 1 May 2014 11:38:17 -0700 (PDT) In-Reply-To: References: <53628077.8070402@centralnic.com> Date: Thu, 1 May 2014 14:38:17 -0400 Message-ID: From: Seth Goldman To: =?ISO-8859-1?Q?Luis_Mu=F1oz?= Content-Type: multipart/alternative; boundary=20cf30334ad7fa018a04f85af728 Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/jlZldSEcmKekmVxkU9gPI2n-5AE Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:38:21 -0000 --20cf30334ad7fa018a04f85af728 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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" wrote: > > > On May 1, 2014, at 11:03 AM, Pat Moroney 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 > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --20cf30334ad7fa018a04f85af728 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

On May 1, 2014 2:35 PM, "Luis Mu=F1oz" <lem@isc.org> wrote:
>
>
> On May 1, 2014, at 11:03 AM, Pat Moroney <pmoroney@name.com> wrote:
>
> > Let me know if any of this makes sense or if there is a better ve= nue 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 "excep= tional" 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 vali= d only during a certain period?
>
> Best regards
>
> -lem
>
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.= ietf.org/mailman/listinfo/provreg

--20cf30334ad7fa018a04f85af728-- From nobody Thu May 1 11:42:42 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB521A091A for ; Thu, 1 May 2014 11:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkoJpn9g9tv7 for ; Thu, 1 May 2014 11:42:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6626E1A073F for ; Thu, 1 May 2014 11:42:40 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by mx.pao1.isc.org (Postfix) with ESMTP id 6A13C3493FE; Thu, 1 May 2014 18:42:38 +0000 (UTC) (envelope-from lem@isc.org) Received: from macbookprolem.lem (ip68-101-126-84.oc.oc.cox.net [68.101.126.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id BCD53216C25; Thu, 1 May 2014 18:42:37 +0000 (UTC) (envelope-from lem@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Thu, 1 May 2014 11:42:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39CF3A18-B8EC-4451-B12A-8A6FB84EB287@isc.org> References: <53628077.8070402@centralnic.com> To: Seth Goldman X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/7OXN4Zp4vDUSEHMhr2g1u65rOXI Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:42:41 -0000 On May 1, 2014, at 11:38 AM, Seth Goldman 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 nobody Thu May 1 11:52:20 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625871A0933 for ; Thu, 1 May 2014 11:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65MtAil7GYKb for ; Thu, 1 May 2014 11:52:13 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id 473D61A0919 for ; Thu, 1 May 2014 11:52:13 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id as1so3970925iec.39 for ; Thu, 01 May 2014 11:52:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qdgUm3zzjaFXTTobJZWN6kpxecc2IzPsNDwMbq7yWA4=; b=WFsejhcNI09hk69RaruUg/qHseQSIJzhklKafhlq+v28TWWUZmMa6o4W5XyvSfDs0j ZA+D+rc1KEIJjs1t/thUGatNfC/5yPVIfqqJioRyed86G5xI2DJQsMHzOGhTh22fb/6j NPxtL1KyYX9IIiMvgWH7vEx0uFD1TY0rNsW6kNEtyW8VJL8Zi6yKSxIwroGwc++EezzG 5VTFW/pfoRgNPUg56/7tVt6pdMDFgmkP4fdtPBIfC0HwkVJ1KGKMFe2mCMpxuJ52DF8f GrQAJyaoQ+NHug3OHII2bbAfmL5lmPyb5qs14nbIISf2y8Mv+UhRfh3EJ1Pe5OCK88zx uP5g== X-Gm-Message-State: ALoCoQmJrBFE5TD3Qvvrlgec7Swy2GmMn9zVt/IdeGsMtgyStQYKStRtelHWfg3S3PyFNQKrbZRm X-Received: by 10.50.40.103 with SMTP id w7mr5115801igk.33.1398970331304; Thu, 01 May 2014 11:52:11 -0700 (PDT) Received: from [172.16.1.16] (CPE7073cbb4404e-CM78cd8ece2635.cpe.net.cable.rogers.com. [174.119.38.58]) by mx.google.com with ESMTPSA id b8sm11282931igx.3.2014.05.01.11.52.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 May 2014 11:52:10 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_29080624-E8D6-405F-A2C9-50E8E2261B64" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: MICHAEL W YOUNG In-Reply-To: Date: Thu, 1 May 2014 14:52:08 -0400 Message-Id: References: <53628077.8070402@centralnic.com> To: Pat Moroney X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/PJThUveqs2IqddLX05uiycAByDs Cc: "provreg@ietf.org" Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 18:52:17 -0000 --Apple-Mail=_29080624-E8D6-405F-A2C9-50E8E2261B64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 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. >=20 > 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": > 5.00 > or > 5.00 > And omission of that attribute would imply that the value is 0. >=20 > 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. >=20 > 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. >=20 >=20 >=20 > On Thu, May 1, 2014 at 11:12 AM, Gavin Brown = wrote: > Thanks to all for the feedback. I am working on a revised draft that > will use a single element in commands and a single > element in responses. >=20 > Here are some example commands and responses: let me know what you = think. >=20 > Thanks, >=20 > C: > C: > C: > C: > C: C: xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"> > C: example.com > C: example.net > C: example.org > C: > C: > C: > C: C: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > C: > C: example.com > C: USD > C: create > C: 1 > C: > C: > C: example.net > C: EUR > C: > C: create > C: 2 > C: > C: > C: example.org > C: EUR > C: transfer > C: > C: > C: example.xyz > C: restore > C: 1 > C: > C: > C: > C: ABC-12345 > C: > C: >=20 > S: > S: > S: > S: > S: Command completed successfully > S: > S: > S: S: xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"> > S: > S: example.com > S: > S: > S: example.net > S: In use > S: > S: > S: example.org > S: In use > S: > S: > S: > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.com > S: USD > S: create > S: 1 > S: 5.00 > S: 5.00 > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.net > S: EUR > S: > S: create > S: 2 > S: 5.00 > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.org > S: EUR > S: transfer > S: 2 > S: 2.50 > S: 10.00 > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.xyz > S: GBP > S: restore > S: 1 > S: 25 > S: 5.00 > S: > S: > S: > S: > S: ABC-12345 > S: 54322-XYZ > S: > S: > S: >=20 > -- > 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/ >=20 > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: 35-39 Moorgate, London, > EC2R 6AR. >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 >=20 >=20 > --=20 > -Pat Moroney > SVP of Accounting / Sr. Software Engineer > Name.com > http://www.youtube.com/watch?v=3DV1GKGXXF12c > 720-663-0025 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL W YOUNG michael@mwyoung.ca --Apple-Mail=_29080624-E8D6-405F-A2C9-50E8E2261B64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
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 <pmoroney@name.com> = 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":
<fee:fee description=3D"Renewal Fee" = special=3D"0">5.00</fee:fee>
or
<fee:f= ee description=3D"Renewal Fee" special=3D"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 <gavin.brown@centralnic.com> = wrote:
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=3D"1.0" encoding=3D"utf-8" standalone=3D"no"?>
C: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
C:   <command>
C:     <check>
C:       <domain:check
C:         = xmlns:domain=3D"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=3D"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=3D"sunrise">create</fee:command>
C:           <fee:period = unit=3D"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=3D"claims" = subphase=3D"landrush">
C:           create</fee:command>
C:           <fee:period = unit=3D"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=3D"y">1</fee:period>
C:         </fee:domain>
C:       </fee:check>
C:     </extension>
C:     <clTRID>ABC-12345</clTRID>
C:   </command>
C: </epp>

S: <?xml version=3D"1.0" encoding=3D"utf-8" standalone=3D"no"?>
S: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
S:   <response>
S:     <result code=3D"1000">
S:       <msg>Command completed = successfully</msg>
S:     </result>
S:     <resData>
S:       <domain:chkData
S:         = xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:cd>
S:           <domain:name avail=3D"1">example.com</domain:name>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail=3D"0">example.net</domain:name>
S:           <domain:reason>In = use</domain:reason>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail=3D"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=3D"urn:ietf:params:xml:ns:fee-0.5">
S:         <fee:cd
S:           = xmlns:fee=3D"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=3D"sunrise">create</fee:command>
S:           <fee:period = unit=3D"y">1</fee:period>
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>
S:         <fee:cd
S:           = xmlns:fee=3D"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=3D"claims" = subphase=3D"landrush">
S:           create</fee:command>
S:           <fee:period = unit=3D"y">2</fee:period>
S:           = <fee:fee>5.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           = xmlns:fee=3D"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=3D"y">2</fee:period>
S:           <fee:fee description=3D"Transfer = Fee">2.50</fee:fee>
S:           <fee:fee description=3D"Renewal = Fee">10.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           = xmlns:fee=3D"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=3D"y">1</fee:period>
S:           <fee:fee description=3D"Restore = Fee">25</fee:fee>
S:           <fee:fee description=3D"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.


_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg




--
-Pat Moroney
SVP of Accounting / Sr. Software = Engineer
720-663-0025

_______________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.= org/mailman/listinfo/provreg


= --Apple-Mail=_29080624-E8D6-405F-A2C9-50E8E2261B64-- From nobody Thu May 1 12:05:55 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412781A6FD5 for ; Thu, 1 May 2014 12:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18M3hwyuzlDi for ; Thu, 1 May 2014 12:05:53 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 345051A6FCC for ; Thu, 1 May 2014 12:05:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by mx.ams1.isc.org (Postfix) with ESMTP id D0484238415; Thu, 1 May 2014 19:05:39 +0000 (UTC) (envelope-from lem@isc.org) Received: from macbookprolem.lem (ip68-101-126-84.oc.oc.cox.net [68.101.126.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id ADB99216C3D; Thu, 1 May 2014 19:05:38 +0000 (UTC) (envelope-from lem@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Thu, 1 May 2014 12:05:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <326D3600-7F74-4D00-8F2B-A346C2A721B1@isc.org> References: <53628077.8070402@centralnic.com> To: MICHAEL W YOUNG X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/2Q7dDfyAMxezlcFBCWCxcEH0aqA Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:05:54 -0000 On May 1, 2014, at 11:52 AM, MICHAEL W YOUNG 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 nobody Thu May 1 12:21:36 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B71A1A7021 for ; Thu, 1 May 2014 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOLQjP01eB9n for ; Thu, 1 May 2014 12:21:33 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 555071A6FC7 for ; Thu, 1 May 2014 12:21:33 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi5so365119wib.1 for ; Thu, 01 May 2014 12:21:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XM6zpby9D9oQX9qpQB/sNVDy2pfkHJqlhm71NnmLems=; b=f+M+2InJTTlheN3CKxZFbAvAYzviYa3zuBM+FdnG8deX88ZenK7Txsqreog6IZWSNe gchA86wguwIj4afRAPkxueteKmFgyXP0v2zgJIYuGRLkM3u9xmhn5PoY5oRD9aW9VY1B 1JRrxGL5E9SfEVWqBo1TqfQ6JgcMeKhCRO0OW/nSJWCloAPzGM8sPSrL33ptcRUcP6tR ouNvezfURB13csszd6apvkGrxnUzixLySkMwxVW4rLvaLANbG+iS2zoVr4Wvsbx/VhGi SRQTSEWF2jytbJGDNgHIU33d+IWXjxTdKdmkVtX5b4AP8Mn3yhkW5NRoP1zfx/Ff5gZ+ 0/Aw== X-Gm-Message-State: ALoCoQmF8aN0H66myzvIAYODlfaj9xTV4uJABioTbLhhmSKITmoEzRLAbZ+2SGacB7lz0wRLBe3M MIME-Version: 1.0 X-Received: by 10.180.210.238 with SMTP id mx14mr3310980wic.61.1398972090337; Thu, 01 May 2014 12:21:30 -0700 (PDT) Received: by 10.194.22.9 with HTTP; Thu, 1 May 2014 12:21:30 -0700 (PDT) In-Reply-To: References: <53628077.8070402@centralnic.com> Date: Thu, 1 May 2014 13:21:30 -0600 Message-ID: From: Pat Moroney To: Seth Goldman Content-Type: multipart/alternative; boundary=001a11c26a427ee6db04f85b9262 Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/PAuakjHOS_l6AQfPEnXy8TkN498 Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:21:35 -0000 --001a11c26a427ee6db04f85b9262 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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" wrote: > > > > > > On May 1, 2014, at 11:03 AM, Pat Moroney 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 onl= y > during a certain period? > > > > Best regards > > > > -lem > > > > _______________________________________________ > > provreg mailing list > > provreg@ietf.org > > 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 --001a11c26a427ee6db04f85b9262 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seth, you hit the nail on the head. We currently have to f= igure 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 in= formation in a standard way which is guaranteed to be up to date.=C2=A0
A type attribute could work for that nicely.


On Thu, May 1, 20= 14 at 12:38 PM, Seth Goldman <sethamin@google.com> wrote:<= br>

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

On May 1, 2014 2:35 PM, "Lui= s Mu=C3=B1oz" <lem= @isc.org> wrote:
>
>
> On May 1, 2014, at 11:03 AM, Pat Moroney <pmoroney@name.com> wrote:
>
> > Let me know if any of this makes sense or if there is a better ve= nue 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 "excep= tional" 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 vali= d only during a certain period?
>
> Best regards
>
> -lem
>
> _______________________________________________
> provreg mailing list
> provreg@ietf.org=
> https://www.ietf.org/mailman/listinfo/provreg




--
-Pat Moroney
SVP of Accounting / Sr. Software Engineer<= /div>
Name.com
720-663-0025

--001a11c26a427ee6db04f85b9262-- From nobody Thu May 1 12:41:36 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5A1A6FBC for ; Thu, 1 May 2014 12:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1GQ7rNSLDAX for ; Thu, 1 May 2014 12:41:34 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9B1A6F78 for ; Thu, 1 May 2014 12:41:33 -0700 (PDT) Received: from [192.168.0.11] (unknown [179.209.19.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 431632080188 for ; Thu, 1 May 2014 16:41:30 -0300 (BRT) From: Rubens Kuhl Content-Type: multipart/alternative; boundary="Apple-Mail=_E81D8D8B-627C-4651-AFD2-0E6FE34F0591" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Thu, 1 May 2014 16:41:28 -0300 References: <53628077.8070402@centralnic.com> To: "provreg@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/-dX5xSoFpT06l6UDTz7WQorcPd4 Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 19:41:35 -0000 --Apple-Mail=_E81D8D8B-627C-4651-AFD2-0E6FE34F0591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Recent events showed there is a need for a reliable way of knowing it.=20= = http://domainincite.com/16534-guy-hit-with-1600-bill-a-month-after-registe= ring-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 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.=20 >=20 > A type attribute could work for that nicely. >=20 >=20 > On Thu, May 1, 2014 at 12:38 PM, Seth Goldman = 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. >=20 >=20 > On May 1, 2014 2:35 PM, "Luis Mu=F1oz" wrote: > > > > > > On May 1, 2014, at 11:03 AM, Pat Moroney 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 > > provreg@ietf.org > > https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 >=20 >=20 > --=20 > -Pat Moroney > SVP of Accounting / Sr. Software Engineer > Name.com > http://www.youtube.com/watch?v=3DV1GKGXXF12c > 720-663-0025 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --Apple-Mail=_E81D8D8B-627C-4651-AFD2-0E6FE34F0591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Recent events showed there is a need = for a reliable way of knowing it. =


Rubens

O= n May 1, 2014, at 4:21 PM, Pat Moroney <pmoroney@name.com> = 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. 

A type attribute could work for that = nicely.


On Thu, May 1, 2014 at 12:38 PM, Seth Goldman = <sethamin@google.com> 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" <lem@isc.org> wrote:
>
>
> On May 1, 2014, at 11:03 AM, Pat Moroney <pmoroney@name.com> 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
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg




--
-Pat Moroney
SVP of Accounting / Sr. Software = Engineer
720-663-0025

_______________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.= org/mailman/listinfo/provreg

= = --Apple-Mail=_E81D8D8B-627C-4651-AFD2-0E6FE34F0591-- From nobody Fri May 2 09:26:22 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717751A084B for ; Fri, 2 May 2014 09:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72NnfXiXD1kC for ; Fri, 2 May 2014 09:26:17 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 78B1B1A08DA for ; Fri, 2 May 2014 09:26:17 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so5399738iec.37 for ; Fri, 02 May 2014 09:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U+OnKc6UwRUcy0lFIDLsGJw8Gp6uNX1M6lIvUfxT3Is=; b=M/XeEJOI4biSWsadN+6un4oJTf+tBwKIvSLAvZVin4483MBf6YWzl/OvnG/bCoGJ4q ZAC01Nx8M27l6s+nCQ20H3OTUjIf/UdMRt9xH+12a1zV2dWdCpdHgh1oamaagGJ3Vonq sVb8/ZHU60/LbFVnouoVVrDmoF8tHOJq+2fXaMo/WVI3dR24EIMg6T12wW6Ty+BvUz0O C+WEvJNfXdMDaVjPyffvgBB0EjxskYukFbW/xJg8EzZB8uNUQPvEyuVjonWhuAZLdadm Ni8BSopyPWicOGTCkQjB3sgQGhVzv8YpRFJnUcNgGdVyfQpmyL63PYtVb+GFx/shpvMZ cRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U+OnKc6UwRUcy0lFIDLsGJw8Gp6uNX1M6lIvUfxT3Is=; b=KKRJC784COANJgygzYZU6okQSWzS4o3VwBvvIo+EBYiwezxUbNUwAXipB2KLrMZid7 NGRhNLwlPFdF4DFNRXGhetI57qsBfoBApOO2wGIut2SKZjqcexofgbklQ/LxxlXp7ujU NaTtGDfvRvYQEMyoS2E/YFXgtjWRNo3IcPO50UoyfMQS4AMZPffR4zutMTSr+JyGyZr+ /Y4cQaczRsCaBoKsJbPdgLFmp7DL7sfEHhL9mRpMYjwSzAr8dVtKGRJZXw+5cJhawQRZ A07JIM/1VY1MWDdcml+7o/iaZiTUnFhXzZ0iwrPBruH+fq9UTM3pzuJmKvNyuG5nagqF glKg== X-Gm-Message-State: ALoCoQn7F14AoQaHw9lj1DHT2AIT9/tkyXaTUw9jg5zGif55Vu96lzYWMXGEVme4BGn9O9rnOIy+ MIME-Version: 1.0 X-Received: by 10.50.22.37 with SMTP id a5mr5654445igf.30.1399047975067; Fri, 02 May 2014 09:26:15 -0700 (PDT) Received: by 10.64.108.229 with HTTP; Fri, 2 May 2014 09:26:14 -0700 (PDT) In-Reply-To: <326D3600-7F74-4D00-8F2B-A346C2A721B1@isc.org> References: <53628077.8070402@centralnic.com> <326D3600-7F74-4D00-8F2B-A346C2A721B1@isc.org> Date: Fri, 2 May 2014 12:26:14 -0400 Message-ID: From: Seth Goldman To: =?ISO-8859-1?Q?Luis_Mu=F1oz?= Content-Type: multipart/alternative; boundary=047d7b10c99194037204f86d3dd7 Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/hVz2QRenDR_mEKZ7bjJNASMW_og Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 16:26:19 -0000 --047d7b10c99194037204f86d3dd7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=F1oz wrote: > > On May 1, 2014, at 11:52 AM, MICHAEL W YOUNG 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 fo= r > 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 ba= se > 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 assumptio= n > that server-side looking up the list of programs will also provide the > relevant pricing information with the same effort. > > Best regards > > -lem > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > --047d7b10c99194037204f86d3dd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think this could be modeled by having extensible custom = types on each "fee" element, or maybe on each "cd&= quot; element. I would be hesitant to embed too much application logic = into the protocol, and instead just make the schema flexible enough to mode= l different scenarios.


On Thu, May 1= , 2014 at 3:05 PM, Luis Mu=F1oz <lem@isc.org> wrote:

On May 1, 2014, at 11:52 AM, MICHAEL W YOUNG <michael@mwyoung.ca> wrote:

> It would be interesting to query a given domain for an answer on which= programs its applicable for. =A0Lets say I am a registrar that signed up f= or marketing programs (out of registry band) "A1" and program &qu= ot;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. =A0I can then do subsequent loo= kups 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 tra= nsaction? 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 rel= evant pricing information with the same effort.

Best regards

-lem

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg

--047d7b10c99194037204f86d3dd7-- From nobody Thu May 8 08:19:21 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E6E1A0057 for ; Thu, 8 May 2014 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axf564UmeM0M for ; Thu, 8 May 2014 08:19:14 -0700 (PDT) Received: from internal-mail-out2.ispapi.net (internal-mail-out2.ispapi.net [93.190.234.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3EB1A0053 for ; Thu, 8 May 2014 08:19:13 -0700 (PDT) Received: from internal-mail-relay1.sls.de.hexonet.net (mx.hexonet.net [10.190.234.71]) by internal-mail-out2.ispapi.net (Postfix) with ESMTP id 69AAB9D2097 for ; Thu, 8 May 2014 15:19:08 +0000 (UTC) Envelope-to: provreg@ietf.org Received: from dslb-188-097-247-027.pools.arcor-ip.net ([188.97.247.27]:37038 helo=[192.168.52.112]) by internal-mail-relay1.sls.de.hexonet.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WiQ6G-0004SG-2r for provreg@ietf.org; Thu, 08 May 2014 15:19:08 +0000 Message-ID: <536BA06C.4070004@hexonet.net> Date: Thu, 08 May 2014 17:19:08 +0200 From: Jens Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: provreg@ietf.org References: <53628077.8070402@centralnic.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070505060509090001000104" X-SA-Exim-Connect-IP: 188.97.247.27 X-SA-Exim-Mail-From: jwagner@hexonet.net Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/f7H8cPoTquTjjPxijojLpi1DriI Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 15:19:19 -0000 This is a multi-part message in MIME format. --------------070505060509090001000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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. *Tier1* or 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: S: somepremium.tld S: USD S: create S: 1 S: 1234.00 S: 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: C: USD C: 12.00 C: 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: > > 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 > 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. >> >> A type attribute could work for that nicely. >> >> >> On Thu, May 1, 2014 at 12:38 PM, Seth Goldman > > 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" > > wrote: >> > >> > >> > On May 1, 2014, at 11:03 AM, Pat Moroney > > 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 >> > provreg@ietf.org >> > 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 >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://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: jwagner@hexonet.net 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. --------------070505060509090001000104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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:

Recent events showed there is a need for a reliable way of knowing it. 



Rubens

On May 1, 2014, at 4:21 PM, Pat Moroney <pmoroney@name.com> 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. 

A type attribute could work for that nicely.


On Thu, May 1, 2014 at 12:38 PM, Seth Goldman <sethamin@google.com> 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" <lem@isc.org> wrote:
>
>
> On May 1, 2014, at 11:03 AM, Pat Moroney <pmoroney@name.com> 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
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg




--
-Pat Moroney
SVP of Accounting / Sr. Software Engineer
720-663-0025

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg



_______________________________________________
provreg mailing list
provreg@ietf.org
https://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: jwagner@hexonet.net
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.
--------------070505060509090001000104-- From nobody Thu May 8 08:42:25 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D547D1A00BE for ; Thu, 8 May 2014 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yWAOGE1Kthc for ; Thu, 8 May 2014 08:42:19 -0700 (PDT) Received: from internal-mail-out2.ispapi.net (internal-mail-out2.ispapi.net [93.190.234.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8AC1A00B9 for ; Thu, 8 May 2014 08:42:16 -0700 (PDT) Received: from internal-mail-relay2.sls.de.hexonet.net (unknown [10.190.234.72]) by internal-mail-out2.ispapi.net (Postfix) with ESMTP id B2B8D9D20BC for ; Thu, 8 May 2014 15:42:11 +0000 (UTC) Envelope-to: provreg@ietf.org Received: from dslb-188-097-247-027.pools.arcor-ip.net ([188.97.247.27]:37135 helo=[192.168.52.112]) by internal-mail-relay2.sls.de.hexonet.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WiQSZ-0003s3-Dl for provreg@ietf.org; Thu, 08 May 2014 15:42:11 +0000 Message-ID: <536BA5D2.9010205@hexonet.net> Date: Thu, 08 May 2014 17:42:10 +0200 From: Jens Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: provreg@ietf.org References: <53628077.8070402@centralnic.com> In-Reply-To: <53628077.8070402@centralnic.com> Content-Type: multipart/alternative; boundary="------------090109070106030207020408" X-SA-Exim-Connect-IP: 188.97.247.27 X-SA-Exim-Mail-From: jwagner@hexonet.net Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/hvosh0tNvHWE6_Kd645TigBTGY8 Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 15:42:22 -0000 This is a multi-part message in MIME format. --------------090109070106030207020408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thank you Gavin! Got a couple of questions regarding the fee extension: 1. Is there are reason, that a client provides the element when sending a query command, e.g. ? 2. Do the elements in need to match the elements in ? 3. May a element for a single domain get repeated in , e.g. for different periods? E.g. useful, when providing a [period => price] dropdown in a shoppingcart: C: C: example.com C: USD C: create C: 1 C: C: C: example.com C: USD C: create C: 2 C: ... C: C: example.com C: USD C: create C: 10 C: Btw, this would not be needed, if supporting price classes. 4. Some registries return an error on , if a different registrar manages the domain, so wouldn't get returned either, correct? Does have any advantage over ? 5. The EPP command example should use instead of ? Best, - jens Am 01.05.2014 19:12, schrieb Gavin Brown: > Thanks to all for the feedback. I am working on a revised draft that > will use a single element in commands and a single > element in responses. > > Here are some example commands and responses: let me know what you think. > > Thanks, > > C: > C: > C: > C: > C: C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > C: example.com > C: example.net > C: example.org > C: > C: > C: > C: C: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > C: > C: example.com > C: USD > C: create > C: 1 > C: > C: > C: example.net > C: EUR > C: > C: create > C: 2 > C: > C: > C: example.org > C: EUR > C: transfer > C: > C: > C: example.xyz > C: restore > C: 1 > C: > C: > C: > C: ABC-12345 > C: > C: > > S: > S: > S: > S: > S: Command completed successfully > S: > S: > S: S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > S: > S: example.com > S: > S: > S: example.net > S: In use > S: > S: > S: example.org > S: In use > S: > S: > S: > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.com > S: USD > S: create > S: 1 > S: 5.00 > S: 5.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.net > S: EUR > S: > S: create > S: 2 > S: 5.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.org > S: EUR > S: transfer > S: 2 > S: 2.50 > S: 10.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.xyz > S: GBP > S: restore > S: 1 > S: 25 > S: 5.00 > S: > S: > S: > S: > S: ABC-12345 > S: 54322-XYZ > S: > S: > S: > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --------------090109070106030207020408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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


Am 01.05.2014 19:12, schrieb Gavin Brown:
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>




_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg
--------------090109070106030207020408-- From nobody Thu May 8 08:55:02 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CB71A007B for ; Thu, 8 May 2014 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fsj2mPoYksiW for ; Thu, 8 May 2014 08:54:56 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0541A0079 for ; Thu, 8 May 2014 08:54:56 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db11so3478365veb.8 for ; Thu, 08 May 2014 08:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WQluNhx1j3XB/T34iPYuRFtGzE4BdWjybOS0mcggrXY=; b=Vk3CDf3iE0hHDMAsuSljrMvjcWKJG1WD7trhAFCIS+XYcl3HEdfKEniX42UHoLkMwa A/rZlWZnu3ZgokeRPkPSTiWg1Pv/MDuL9jkvFsf3PPDKC0xYUe1DCI6IAho8dzpmOwBx lq+s9rSUf/KnLZN6ZnkLK5kVayVYsGITBhgzK5yNDguC+RMWWdoD9c3S/9/MBYuw+Dw4 y1pUBVGe22BFMRxWgbCW0TjJFKv/2TF4IcAt/E0gB5COm/zRx8qHVgghWm55w1F8cDhp Junmd2NuabmkoJe+Vj0ZtB2uea7WRfoLXZJcMjZPEXkpwhYW1R4QsG0yFtau1vgJNnhh 6DFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WQluNhx1j3XB/T34iPYuRFtGzE4BdWjybOS0mcggrXY=; b=T4yOzPisoZ+H8UYt4ZuRHPkw5rxWJTnqESZ5pPWsf4sO0oSd9aRQJSOxKYYPXb8yJ2 ZFahr13puIyq6v69rryYTnw0QgUY8N8m/tFIPubR4SYg2QvJyCWIrrcOxDU7uxr0o0ZP /2jrEgbbfyUlVGjdRvlZVTR/SwCnRdnFnD5beKDKbz04zjvYliAPyf7nD+weNY1Ld+WA Ad91647Ig480BPMtqw0X2T3p1EBzgwS9pcN3XfNbZPcUBYuuN5B7qUbRkpJO1I1oUFn1 +7Xny3MITB5JT/MGz26rnLi68CgvQHKr2HyT+3D0eu+fT9/QGhHDRSVso9WH+JhVvP2K 9L9w== X-Gm-Message-State: ALoCoQnP9AseEaI1g4WUZNkp9U71ACc9MQyfowge3K8X1lCaIZvSn3F/8AmMna1eGkK0FmoisUcB MIME-Version: 1.0 X-Received: by 10.58.30.75 with SMTP id q11mr1953757veh.37.1399564491476; Thu, 08 May 2014 08:54:51 -0700 (PDT) Received: by 10.52.117.171 with HTTP; Thu, 8 May 2014 08:54:51 -0700 (PDT) In-Reply-To: <536BA5D2.9010205@hexonet.net> References: <53628077.8070402@centralnic.com> <536BA5D2.9010205@hexonet.net> Date: Thu, 8 May 2014 11:54:51 -0400 Message-ID: From: Seth Goldman To: Jens Wagner Content-Type: multipart/alternative; boundary=089e013a04fa5ae93d04f8e58006 Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/KOPHYL1uT4wDAMZTlj3gK3NcoZw Cc: EPP Provreg Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 15:55:00 -0000 --089e013a04fa5ae93d04f8e58006 Content-Type: text/plain; charset=ISO-8859-1 I think most/any of these scenarios are possible, depending on the registry's business logic. For example, perhaps the price returned on an is different price than on a 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 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 wrote: > Thank you Gavin! > > Got a couple of questions regarding the fee extension: > > 1. Is there are reason, that a client provides the element > when sending a query command, e.g. ? > > 2. Do the elements in need to match the > elements in ? > > 3. May a element for a single domain get repeated in > , e.g. for different periods? > E.g. useful, when providing a [period => price] dropdown in a shoppingcart: > > > C: > C: example.com > C: USD > C: create > > C: 1 > C: > C: > C: example.com > > C: USD > C: create > C: 2 > C: > ... > > C: > C: example.com > C: USD > C: create > C: 10 > C: > > Btw, this would not be needed, if supporting price classes. > > 4. Some registries return an error on , if a different > registrar manages the domain, so wouldn't get returned > either, correct? Does have any advantage over ? > > 5. The EPP command example should use instead of > ? > > Best, > - jens > > > Am 01.05.2014 19:12, schrieb Gavin Brown: > > Thanks to all for the feedback. I am working on a revised draft that > will use a single element in commands and a single > element in responses. > > Here are some example commands and responses: let me know what you think. > > Thanks, > > C: > C: > C: > C: > C: C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > C: example.com > C: example.net > C: example.org > C: > C: > C: > C: C: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > C: > C: example.com > C: USD > C: create > C: 1 > C: > C: > C: example.net > C: EUR > C: > C: create > C: 2 > C: > C: > C: example.org > C: EUR > C: transfer > C: > C: > C: example.xyz > C: restore > C: 1 > C: > C: > C: > C: ABC-12345 > C: > C: > > S: > S: > S: > S: > S: Command completed successfully > S: > S: > S: S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > S: > S: example.com > S: > S: > S: example.net > S: In use > S: > S: > S: example.org > S: In use > S: > S: > S: > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.com > S: USD > S: create > S: 1 > S: 5.00 > S: 5.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.net > S: EUR > S: > S: create > S: 2 > S: 5.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.org > S: EUR > S: transfer > S: 2 > S: 2.50 > S: 10.00 > S: > S: S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > S: example.xyz > S: GBP > S: restore > S: 1 > S: 25 > S: 5.00 > S: > S: > S: > S: > S: ABC-12345 > S: 54322-XYZ > S: > S: > S: > > > > > _______________________________________________ > provreg mailing listprovreg@ietf.orghttps://www.ietf.org/mailman/listinfo/provreg > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > --089e013a04fa5ae93d04f8e58006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think most/any of these scenarios are possible, dep= ending on the registry's business logic. For example, perhaps the price= returned on an <info> is different price than on a <check> bec= ause 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 flex= ible as possible for expressing the data (within reason), while leaving the= exact semantics of that data as "server policy". Otherwise you e= nd up embedding a lot of business logic into the protocol, which then force= s 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= <jwagner@hexonet.net> wrote:
=20 =20 =20
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 =3D> price] dropdown in a shoppingcart:


C:=A0=A0=A0=A0=A0=A0=A0=A0 <fee:domain>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:name>example.com</fee:name>=
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:currency>USD<= /fee:currency>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:command>create</fee:command>

C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:period unit=3D"y">1</fee:period>
C:=A0=A0=A0=A0=A0=A0=A0=A0 </fee:domain>
C:=A0=A0=A0=A0=A0=A0=A0=A0 <fee:domain>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:name>example.com</fee:name>= ;

C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:currency>USD<= /fee:currency>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:command>create</fee:command>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:period unit=3D"y">2</fee:period>
C:=A0=A0=A0=A0=A0=A0=A0=A0 </fee:domain>
...

C:=A0=A0=A0=A0=A0=A0=A0=A0 <fee:domain>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:name>example.com</fee:name>=
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:currency>USD<= /fee:currency>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:command>create</fee:command>
C:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <fee:period unit=3D"y">10</fee:period>
C:=A0=A0=A0=A0=A0=A0=A0=A0 </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


Am 01.05.2014 19:12, schrieb Gavin Brown:
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=3D"1.0" encoding=3D"utf-8" standalo=
ne=3D"no"?>
C: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
C:   <command>
C:     <check>
C:       <domain:check
C:         xmlns:domain=3D"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=3D"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=3D"sunrise">create</fee:=
command>
C:           <fee:period unit=3D"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=3D"claims" subphase=3D"la=
ndrush">
C:           create</fee:command>
C:           <fee:period unit=3D"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=3D"y">1</fee:period>
C:         </fee:domain>
C:       </fee:check>
C:     </extension>
C:     <clTRID>ABC-12345</clTRID>
C:   </command>
C: </epp>

S: <?xml version=3D"1.0" encoding=3D"utf-8" standalo=
ne=3D"no"?>
S: <epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
S:   <response>
S:     <result code=3D"1000">
S:       <msg>Command completed successfully</msg>
S:     </result>
S:     <resData>
S:       <domain:chkData
S:         xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:cd>
S:           <domain:name avail=3D"1">example.com</domain:name>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail=3D"0">example.net</domain:name>
S:           <domain:reason>In use</domain:reason>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail=3D"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=3D"urn:ietf:params:xml:ns:fee-0.5">
S:         <fee:cd
S:           xmlns:fee=3D"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=3D"sunrise">create</fee:=
command>
S:           <fee:period unit=3D"y">1</fee:period>
S:           <fee:fee description=3D"Application Fee">5.00&=
lt;/fee:fee>
S:           <fee:fee description=3D"Registration Fee">5.00=
</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           xmlns:fee=3D"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=3D"claims" subphase=3D"la=
ndrush">
S:           create</fee:command>
S:           <fee:period unit=3D"y">2</fee:period>
S:           <fee:fee>5.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           xmlns:fee=3D"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=3D"y">2</fee:period>
S:           <fee:fee description=3D"Transfer Fee">2.50<=
/fee:fee>
S:           <fee:fee description=3D"Renewal Fee">10.00<=
/fee:fee>
S:         </fee:cd>
S:         <fee:cd
S:           xmlns:fee=3D"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=3D"y">1</fee:period>
S:           <fee:fee description=3D"Restore Fee">25</fe=
e:fee>
S:           <fee:fee description=3D"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>




_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
provreg@ietf.org<= br> https://www.ietf.org/mailman/listinfo/provreg


--089e013a04fa5ae93d04f8e58006-- From nobody Thu May 8 09:07:21 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284EF1A005E for ; Thu, 8 May 2014 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLV73r4egFU2 for ; Thu, 8 May 2014 09:07:14 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id ED57A1A005A for ; Thu, 8 May 2014 09:07:13 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id t61so2762046wes.11 for ; Thu, 08 May 2014 09:07:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v4D3v90EH2ZF53YzhK4VghQUfx2GTRTVRs4HzIYAEAk=; b=LV7PkQgSfYGHvI2X1MnG3ZsAx9491QaHVW/5OhLy3Sf1AkVkMXqQZxyg3tf2S42FHq ikMQ2pzeWko0qeEfOP8noyxWHozFw3cuU+2C/0Oe02ayuo8jLDWJSZw9zKJ11y0QNNgt l//BfVCcPnZWZCJP1y9R1f3OOfTgpZFi51ezP/mrMzZ8k7nvwRRYhRsGIB9cyVUUdV8M ED8NmsVgeFnw9sRVULeJxu7tyWPZMoPRQIteCXVpORXEBAOJQlir5yAz4ivNdfGtfV7K BPXIXKwGnbxbCSf7wLoCUTyX3h2dkGy9jtckRGj6tGNE4/XenY1xHjym+oKitzSapWeN YFiQ== X-Gm-Message-State: ALoCoQmAZg1Swfwhn28OeAOAlgURMB2kEJKbcFy+aTV4bvYwfoZCPgs9tNIfcw44BgzUCgyZkuv4 MIME-Version: 1.0 X-Received: by 10.180.210.238 with SMTP id mx14mr13520538wic.61.1399565228915; Thu, 08 May 2014 09:07:08 -0700 (PDT) Received: by 10.194.22.9 with HTTP; Thu, 8 May 2014 09:07:08 -0700 (PDT) In-Reply-To: <536BA06C.4070004@hexonet.net> References: <53628077.8070402@centralnic.com> <536BA06C.4070004@hexonet.net> Date: Thu, 8 May 2014 10:07:08 -0600 Message-ID: From: Pat Moroney To: Jens Wagner Content-Type: multipart/alternative; boundary=001a11c26a424f55b304f8e5ac6b Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/VaZL-rNrojB0r7u8sTJ9HZhCXCc Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 16:07:18 -0000 --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 as well as required on the if it was set. Especially if that optional description attribute is added to the element as well, which was hinted at in Gavin's email about the new draft. He had the following example: S: S: 5.00 S: 5.00 S: 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: S: example.com S: USD S: create S: 1 S: 2500.00 S: 66.00 S: 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 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. > > *Tier1* or > > 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: > S: somepremium.tld > > S: USD > S: create > > S: 1 > S: 1234.00 > S: > > 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: > > C: USD > C: 12.00 > C: > > > 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 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 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" wrote: >> > >> > >> > On May 1, 2014, at 11:03 AM, Pat Moroney 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 >> > provreg@ietf.org >> > 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 > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > > > > _______________________________________________ > provreg mailing listprovreg@ietf.orghttps://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: jwagner@hexonet.net > 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 > provreg@ietf.org > 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
Hi Jens,

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.
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: =C2=A0 =C2=A0 =C2=A0 =C2=A0= <fee:cd
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5">=

S: =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Application= Fee">5.00</fee:fee>
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Registration Fee&q= uot;>5.00</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>

That, combined with the type attribute, allows a = lot of flexability for registries.
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:

S: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5" typ= e=3D"BBB+">
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.com</fee:name>
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>USD</fee:currency>
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>create</fee:command>
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y">1</fee:p= eriod>
<= 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>
S: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"Registration Fee&q= uot;>66.00</fee:fee>
S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>

=
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.


On Thu,= May 8, 2014 at 9:19 AM, Jens Wagner <jwagner@hexonet.net>= wrote:
=20 =20 =20
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:c= d ... 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:

=C2=A0 =C2=A0 REGISTRY -> REGISTRAR (-> RESELLER)* -> CU= STOMER

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:=C2=A0 <fee:cd xmlns:fee=3D"urn:ietf:params:xml:ns:fee-= 0.5" type=3D"AAA+">
S:=C2=A0=C2=A0=C2=A0 <fee:name>somepremium.tld</fee= :name>

S:=C2=A0=C2=A0=C2=A0 <fee:currency>USD</fee:currenc= y>
S:=C2=A0=C2=A0=C2=A0 <fee:command>create</fee= :command>

S:=C2=A0=C2=A0=C2=A0 <fee:period unit=3D"y">= 1</fee:period>
S:=C2=A0=C2=A0=C2=A0 <fee:fee>1234.00</fee:fe= e>
S:=C2=A0 </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:=C2=A0 <fee:create xmlns:fee=3D"urn:ietf:params:xml:ns:= fee-0.4" type=3D"AAA+">

C:=C2=A0=C2=A0=C2=A0 <fee:currency>USD</fee:currenc= y>
C:=C2=A0=C2=A0=C2=A0 <fee:fee>12.00</fee:fee&= gt;
C:=C2=A0 </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:
=20

Recent events showed there is a need for a reliable way of knowing it.=C2=A0



Rubens

On May 1, 2014, at 4:21 PM, Pat Moroney <pmoroney@name.com> 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.=C2=A0

A type attribute could work for that nicely.


On Thu, May 1, 2014 at 12:38 PM, Seth Goldman <sethamin@google.com> wrote:

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.


On May 1, 2014 2:35 PM, "Luis Mu=C3=B1oz" <lem@isc.org> wrote:
>
>
> On May 1, 2014, at 11:03 AM, Pat Moroney <pmoroney@name.com> 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 su= spect you intent to convey some other meaning into the transaction.
>
> Perhaps you're thinking about a promotiona= l price that can be valid only during a certain period?
>
> Best regards
>
> -lem
>
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg




--
_______________________________________________
provreg mailing list
provreg= @ietf.org
https://www.ietf.org/mailman/listinfo/provreg



_______________________________________________
provreg mailing list
provreg@ietf.org
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: jwagner@hexonet=
.net
W: http://www.hexonet.=
net

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.

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg




--
-Pat Moroney
SVP of Accounting / Sr. Software Engin= eer
Name.com
720-663-0025

--001a11c26a424f55b304f8e5ac6b-- From nobody Thu May 8 10:05:49 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1044D1A0075 for ; Thu, 8 May 2014 10:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eogUgbesBsyr for ; Thu, 8 May 2014 10:05:45 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id 1840F1A0079 for ; Thu, 8 May 2014 10:05:45 -0700 (PDT) Received: from [192.168.43.58] (unknown [31.68.128.99]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 4B4419EBA; Thu, 8 May 2014 17:05:38 +0000 (UTC) Message-ID: <536BB92A.6000706@centralnic.com> Date: Thu, 08 May 2014 18:04:42 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Gould, James" , Klaus Malorny , "provreg@ietf.org" References: <53628077.8070402@centralnic.com> In-Reply-To: <53628077.8070402@centralnic.com> X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2uLV5D5slmTbB4wGjtEqShhBxWJvlUDo4" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/8oY_FgJ8cEcCRYMITwgWX58f7CU Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:05:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2uLV5D5slmTbB4wGjtEqShhBxWJvlUDo4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. On 01/05/2014 18:12, Gavin Brown wrote: > Thanks to all for the feedback. I am working on a revised draft that > will use a single element in commands and a single > element in responses. >=20 > Here are some example commands and responses: let me know what you thin= k. >=20 > Thanks, >=20 > C: > C: > C: > C: > C: C: xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"> > C: example.com > C: example.net > C: example.org > C: > C: > C: > C: C: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > C: > C: example.com > C: USD > C: create > C: 1 > C: > C: > C: example.net > C: EUR > C: > C: create > C: 2 > C: > C: > C: example.org > C: EUR > C: transfer > C: > C: > C: example.xyz > C: restore > C: 1 > C: > C: > C: > C: ABC-12345 > C: > C: >=20 > S: > S: > S: > S: > S: Command completed successfully > S: > S: > S: S: xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0"> > S: > S: example.com > S: > S: > S: example.net > S: In use > S: > S: > S: example.org > S: In use > S: > S: > S: > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.com > S: USD > S: create > S: 1 > S: 5.00 > S: 5.00 > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.net > S: EUR > S: > S: create > S: 2 > S: 5.00 > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.org > S: EUR > S: transfer > S: 2 > S: 2.50 > S: 10.00 > S: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> > S: example.xyz > S: GBP > S: restore > S: 1 > S: 25 > S: 5.00 > S: > S: > S: > S: > S: ABC-12345 > S: 54322-XYZ > S: > S: > S: >=20 --=20 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. --2uLV5D5slmTbB4wGjtEqShhBxWJvlUDo4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNruSoACgkQ6H45IPkjtM54uQCfYiOzwtpW1uV3iUQY4ovlF2ni 9CsAniiTzCuXfd8d20aBqnBjffxXnCp1 =SL5S -----END PGP SIGNATURE----- --2uLV5D5slmTbB4wGjtEqShhBxWJvlUDo4-- From nobody Thu May 8 10:06:59 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3371A006A for ; Thu, 8 May 2014 10:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEPzEaYiPRE2 for ; Thu, 8 May 2014 10:06:54 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1B1A004E for ; Thu, 8 May 2014 10:06:54 -0700 (PDT) Received: from [192.168.43.58] (unknown [31.68.128.99]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 41D8D9EBA; Thu, 8 May 2014 17:06:48 +0000 (UTC) Message-ID: <536BB9A1.1070504@centralnic.com> Date: Thu, 08 May 2014 18:06:41 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Gould, James" , Klaus Malorny , "provreg@ietf.org" References: <53628077.8070402@centralnic.com> <536BB92A.6000706@centralnic.com> In-Reply-To: <536BB92A.6000706@centralnic.com> X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhR0WP4gDTNDD5mK7L70SWbGboMgwCIaN" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/RbzrO8py-BhYN1DZqhJtGsU2E_o Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:06:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AhR0WP4gDTNDD5mK7L70SWbGboMgwCIaN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, that URL is: https://github.com/centralnic/epp-fee-extension On 08/05/2014 18:04, Gavin Brown wrote: > 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. --=20 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. --AhR0WP4gDTNDD5mK7L70SWbGboMgwCIaN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNruaEACgkQ6H45IPkjtM7KIQCgiwK1vmfXAnzpUbs/tafTXKwN 1/MAn0T3l+h0mbevPgfwoL0DFaeEWsdg =2Gkn -----END PGP SIGNATURE----- --AhR0WP4gDTNDD5mK7L70SWbGboMgwCIaN-- From nobody Thu May 8 10:31:59 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974051A00D7 for ; Thu, 8 May 2014 10:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ksbKNvURLao for ; Thu, 8 May 2014 10:31:55 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id 15D091A00B3 for ; Thu, 8 May 2014 10:31:55 -0700 (PDT) Received: from [192.168.43.58] (unknown [31.68.128.99]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 70F109EBA; Thu, 8 May 2014 17:31:49 +0000 (UTC) Message-ID: <536BBF84.8040706@centralnic.com> Date: Thu, 08 May 2014 18:31:48 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jens Wagner , provreg@ietf.org References: <53628077.8070402@centralnic.com> <536BA5D2.9010205@hexonet.net> In-Reply-To: <536BA5D2.9010205@hexonet.net> X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="83ofe0sDvV0f4cJQ7Vh2gnagUVAAGtp7N" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/foHm9QUkrgSJ136QN0YcP0WoEiA Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:31:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --83ofe0sDvV0f4cJQ7Vh2gnagUVAAGtp7N Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/05/2014 16:42, Jens Wagner wrote: > Thank you Gavin! >=20 > Got a couple of questions regarding the fee extension: >=20 > 1. Is there are reason, that a client provides the > element when sending a query command, e.g. ? This is now optional in commands but is still mandatory in responses. > 2. Do the elements in need to match the > elements in ? No: this is implicit in the text but could be made implicit. > 3. May a element for a single domain get repeated in > , e.g. for different periods? > E.g. useful, when providing a [period =3D> price] dropdown in a shoppin= gcart: Yes. each element will be completely independent of the othe= rs. > 4. Some registries return an error on , if a different > registrar manages the domain, so wouldn't get returned > either, correct? Does have any advantage over ? That's a matter of server policy. > 5. The EPP command example should use instead of > ? Yes - that's probably a typo :-) G. --=20 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. --83ofe0sDvV0f4cJQ7Vh2gnagUVAAGtp7N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNrv4QACgkQ6H45IPkjtM5LGQCfd3QuGvc6M5OUdHQ59Nd3r8am zroAmwTm8QCZEy2Mj0ko90HSAIWs+4O3 =GAgN -----END PGP SIGNATURE----- --83ofe0sDvV0f4cJQ7Vh2gnagUVAAGtp7N-- From nobody Thu May 8 10:35:45 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575361A00D8 for ; Thu, 8 May 2014 10:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozDl7eKe8fUt for ; Thu, 8 May 2014 10:35:40 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id A4F311A00CB for ; Thu, 8 May 2014 10:35:40 -0700 (PDT) Received: from [192.168.43.58] (unknown [31.68.128.99]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 052F19EBA; Thu, 8 May 2014 17:35:34 +0000 (UTC) Message-ID: <536BC065.7060900@centralnic.com> Date: Thu, 08 May 2014 18:35:33 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Seth Goldman , Jens Wagner References: <53628077.8070402@centralnic.com> <536BA5D2.9010205@hexonet.net> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q2d5Cheqi327GPg4lB5i05eOu1olLrL4A" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/mUaI7N9kPEbmlrQNprSuTYxJRP4 Cc: EPP Provreg Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:35:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q2d5Cheqi327GPg4lB5i05eOu1olLrL4A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/05/2014 16:54, Seth Goldman wrote: > In general, I'd advocate for making the protocol as flexible as possibl= e > 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 cas= e > 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. --=20 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. --q2d5Cheqi327GPg4lB5i05eOu1olLrL4A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNrwGUACgkQ6H45IPkjtM6QnQCeJy9+N6pU9lUXk4z88zY4TzKO +REAn1CVKCRaflZ6mjYUe7xZXXhM6l2Y =TZEI -----END PGP SIGNATURE----- --q2d5Cheqi327GPg4lB5i05eOu1olLrL4A-- From nobody Thu May 8 10:55:47 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8308D1A00C6 for ; Thu, 8 May 2014 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-PfWS9OpyD0 for ; Thu, 8 May 2014 10:55:43 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id DF63A1A00B4 for ; Thu, 8 May 2014 10:55:42 -0700 (PDT) Received: from [192.168.43.58] (unknown [31.68.128.99]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 2F95F9EBA; Thu, 8 May 2014 17:55:37 +0000 (UTC) Message-ID: <536BC518.4050400@centralnic.com> Date: Thu, 08 May 2014 18:55:36 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pat Moroney , Jens Wagner References: <53628077.8070402@centralnic.com> <536BA06C.4070004@hexonet.net> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pMWe5Lwg8w824cwn9B8qAlWTKTdhrdgXe" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/5fncO501h5m_u_xvmW41Sgfl_xI Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 17:55:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pMWe5Lwg8w824cwn9B8qAlWTKTdhrdgXe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/05/2014 17:07, Pat Moroney wrote: > Hi Jens, >=20 > I like the optional type attribute being added to the as well > as required on the if it was set. > Especially if that optional description attribute is added to the > element as well, which was hinted at in Gavin's email about > the new draft. >=20 > He had the following example: > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5"> >=20 > S: 5.00 > S: 5.00 > S: >=20 > 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: >=20 > S: S: xmlns:fee=3D"urn:ietf:params:xml:ns:fee-0.5" type=3D"BBB+"= > > S: example.com > S: USD > S: create > S: 1 > S: 2500.00 > S: 66.00 > S: >=20 > 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 elements. If we're going to add additional syntax to describe the domain itself, then I think that syntax should be added to the element, like so: S: S: example.com S: USD S: create S: 1 S: 2500.00 S: 66.00 S: 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? --=20 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. --pMWe5Lwg8w824cwn9B8qAlWTKTdhrdgXe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNrxRgACgkQ6H45IPkjtM4DkgCfagNZl2evUFfmUWIO8iERXgnr ZHIAoIzaE/FnSxL3X5elFbfOGQuIWEYV =/9uU -----END PGP SIGNATURE----- --pMWe5Lwg8w824cwn9B8qAlWTKTdhrdgXe-- From nobody Thu May 8 11:14:00 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D321A00AE for ; Thu, 8 May 2014 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7w4h6MKRLUG for ; Thu, 8 May 2014 11:13:53 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2C71A0087 for ; Thu, 8 May 2014 11:13:53 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so2841528wes.6 for ; Thu, 08 May 2014 11:13:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=15gPl16HXdXXWUF/fUS0qOK1H5HRAnTUejwENzHyCXI=; b=Z7fnF2n8tha/OpXzwb/VNCFnqOC0KHmC7wS3EmdweDrq6dQcZffea9gHIrQFSMhx2H CKonhr6ve4wlbr13I6SLTH9RlttEgrz7lyY5hnd1nlZyfWUMsOMAQvjREZRLGA3/i3ho F0ThTx2jdHtVmaYfjCmCYE3jvbt00gwfXBEBYE4W9OzCd9T139HG70xox2kGemDxdUDZ c0pgAphzb3y89d6PyJprm/4gn8+N6bHz+1SNMk/BlBf2qKUXT5Y+3EANmBeYjgU4gBZI TmonWbaYLjpYOvXRKMJyjZjtYV9OtlDO+Zn27FgdUi/6rL7uwO+doZztsjmUMhIEUwjm KqoQ== X-Gm-Message-State: ALoCoQkV3Z2NWBpRazBjS9Qx7KuA2zea8Hp3b9185/g2sf+kLZJ+iQVTkdlmfvnGbUc/lZYsDrYb MIME-Version: 1.0 X-Received: by 10.180.218.197 with SMTP id pi5mr4667828wic.21.1399572828075; Thu, 08 May 2014 11:13:48 -0700 (PDT) Received: by 10.194.22.9 with HTTP; Thu, 8 May 2014 11:13:47 -0700 (PDT) In-Reply-To: <536BC518.4050400@centralnic.com> References: <53628077.8070402@centralnic.com> <536BA06C.4070004@hexonet.net> <536BC518.4050400@centralnic.com> Date: Thu, 8 May 2014 12:13:47 -0600 Message-ID: From: Pat Moroney To: Gavin Brown Content-Type: multipart/alternative; boundary=001a1134d6d441532504f8e77166 Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/oANh0Xp96SkETMcq3PZsA913H1c Cc: "provreg@ietf.org" Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 18:13:56 -0000 --001a1134d6d441532504f8e77166 Content-Type: text/plain; charset=UTF-8 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 wrote: > On 08/05/2014 17:07, Pat Moroney wrote: > > Hi Jens, > > > > I like the optional type attribute being added to the as well > > as required on the if it was set. > > Especially if that optional description attribute is added to the > > element as well, which was hinted at in Gavin's email about > > the new draft. > > > > He had the following example: > > S: > S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > > > > S: 5.00 > > S: 5.00 > > S: > > > > 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: > S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5" type="BBB+"> > > S: example.com > > S: USD > > S: create > > S: 1 > > S: 2500.00 > > S: 66.00 > > S: > > > > 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 > elements. If we're going to add additional syntax to describe > the domain itself, then I think that syntax should be added to the > element, like so: > > S: > S: example.com > S: USD > S: create > S: 1 > S: 2500.00 > S: 66.00 > S: > > 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? > > -- > 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. > > -- -Pat Moroney SVP of Accounting / Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025 --001a1134d6d441532504f8e77166 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gavin,

That works for me. I am indif= ferent in the terminology: class vs type vs category.

<= div>Thanks,


On Thu, May 8, 2014 at 11:55 AM, Gavin Brown <gavin.brown@centra= lnic.com> wrote:
On 08/05/2014 17:07, Pat Moroney wr= ote:
> Hi Jens,
>
> I like the optional type attribute being added to the <fee:cd> a= s 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 em= ail about
> the new draft.
>
> He had the following example:
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:param= s:xml:ns:fee-0.5">
>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"= Application Fee">5.00</fee:fee>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"= Registration Fee">5.00</fee:fee>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </fee:cd>
>
> That, combined with the type attribute, allows a lot of flexability fo= r
> registries.
> For example, Donuts, if they used this extension, could then return th= e
> following for a premium domain during their Early Access Period day 2:=
>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:cd
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:fee=3D"urn:ietf:param= s:xml:ns:fee-0.5" type=3D"BBB+">
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:name>example.com</fee:name>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:currency>USD</fee:= currency>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:command>create</fe= e:command>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:period unit=3D"y&qu= ot;>1</fee:period>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"= Early Access Fee">2500.00</fee:fee>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <fee:fee description=3D"= Registration Fee">66.00</fee:fee>
> S: =C2=A0 =C2=A0 =C2=A0 =C2=A0 </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 ar= e for.

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

S: =C2=A0<fee:cd>
S: =C2=A0 =C2=A0<fee:name class=3D"premium">example.com</fee:name>
S: =C2=A0 =C2=A0<fee:currency>USD</fee:currency>= ;
S: =C2=A0 =C2=A0<fee:command>create</fee:command>
S: =C2=A0 =C2=A0<fee:period unit=3D"y">1</fee:period>=
S: =C2=A0 =C2=A0<fee:fee description=3D"Early Access Fee">2= 500.00</fee:fee>
S: =C2=A0 =C2=A0<fee:fee description=3D"Registration Fee">6= 6.00</fee:fee>
S: =C2=A0</fee:cd>

The above example uses "class" as the attribute name, but i= t 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?

--
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.centr= alnic.com/

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




--
=
-Pat Moroney
SVP of Accounting / Sr. Softwa= re Engineer
Name.com
720-663-0025

--001a1134d6d441532504f8e77166-- From nobody Thu May 8 14:20:09 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD91A016D for ; Thu, 8 May 2014 14:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmzVQIEqCqtZ for ; Thu, 8 May 2014 14:20:03 -0700 (PDT) Received: from internal-mail-out2.ispapi.net (internal-mail-out2.ispapi.net [93.190.234.75]) by ietfa.amsl.com (Postfix) with ESMTP id B23831A0161 for ; Thu, 8 May 2014 14:20:02 -0700 (PDT) Received: from internal-mail-relay2.sls.de.hexonet.net (unknown [10.190.234.72]) by internal-mail-out2.ispapi.net (Postfix) with ESMTP id 568B69D2089 for ; Thu, 8 May 2014 21:19:57 +0000 (UTC) Envelope-to: provreg@ietf.org Received: from p5dd446be.dip0.t-ipconnect.de ([93.212.70.190]:39677 helo=[192.168.2.120]) by internal-mail-relay2.sls.de.hexonet.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WiVjR-00035n-1D for provreg@ietf.org; Thu, 08 May 2014 21:19:57 +0000 Message-ID: <536BF4FB.9070709@hexonet.net> Date: Thu, 08 May 2014 23:19:55 +0200 From: Jens Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "provreg@ietf.org" References: <53628077.8070402@centralnic.com> <536BA06C.4070004@hexonet.net> <536BC518.4050400@centralnic.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030301030902050101060403" X-SA-Exim-Connect-IP: 93.212.70.190 X-SA-Exim-Mail-From: jwagner@hexonet.net Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/L2ALVE2RLjqM5bW1Lj-DW8kdtA8 Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:20:06 -0000 This is a multi-part message in MIME format. --------------030301030902050101060403 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit +1 That would work, but according to the draft, EPP clients provide the element on requests only. Would also need the attribute for , renew, transfer and so on. Maybe we could use an element e.g. , instead of an attribute? Or also assign the attribute to the , ... 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 > > wrote: > > On 08/05/2014 17:07, Pat Moroney wrote: > > Hi Jens, > > > > I like the optional type attribute being added to the > as well > > as required on the if it was set. > > Especially if that optional description attribute is added to the > > element as well, which was hinted at in Gavin's email > about > > the new draft. > > > > He had the following example: > > S: > S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5"> > > > > S: 5.00 > > S: 5.00 > > S: > > > > 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: > S: xmlns:fee="urn:ietf:params:xml:ns:fee-0.5" type="BBB+"> > > S: example.com > > S: USD > > S: create > > S: 1 > > S: 2500.00 > > S: 66.00 > > S: > > > > 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 > elements. If we're going to add additional syntax to > describe > the domain itself, then I think that syntax should be added to the > element, like so: > > S: > S: example.com > > S: USD > S: create > S: 1 > S: 2500.00 > S: 66.00 > S: > > 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? > > -- > 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. > > > > > -- > -Pat Moroney > SVP of Accounting / Sr. Software Engineer > Name.com > http://www.youtube.com/watch?v=V1GKGXXF12c > 720-663-0025 > --------------030301030902050101060403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
+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 <gavin.brown@centralnic.com> wrote:
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.
>
> He had the following example:
> S:         <fee:cd
> S:           xmlns:fee="urn:ietf:params:xml:ns:fee-0.5">
>
> S:           <fee:fee description="Application Fee">5.00</fee:fee>
> S:           <fee:fee description="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="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.

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>
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>

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?

--
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.




--
-Pat Moroney
SVP of Accounting / Sr. Software Engineer
Name.com
720-663-0025


--------------030301030902050101060403-- From nobody Thu May 8 14:34:12 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62B1A017A for ; Thu, 8 May 2014 14:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03O-Dj2LLQX9 for ; Thu, 8 May 2014 14:34:10 -0700 (PDT) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) by ietfa.amsl.com (Postfix) with ESMTP id 889561A0178 for ; Thu, 8 May 2014 14:34:10 -0700 (PDT) Received: from [192.168.0.7] (unknown [90.202.47.251]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 432B3A1D9; Thu, 8 May 2014 21:34:05 +0000 (UTC) Message-ID: <536BF84C.6030302@centralnic.com> Date: Thu, 08 May 2014 22:34:04 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jens Wagner , "provreg@ietf.org" References: <53628077.8070402@centralnic.com> <536BA06C.4070004@hexonet.net> <536BC518.4050400@centralnic.com> <536BF4FB.9070709@hexonet.net> In-Reply-To: <536BF4FB.9070709@hexonet.net> X-Enigmail-Version: 1.6 OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6VKP5UVjTFUV2kAtlsjdXJaFLQaBJ4Lh3" Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/QdbE8ZHsGz-eFZy7dOYOAZDfAbs Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:34:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6VKP5UVjTFUV2kAtlsjdXJaFLQaBJ4Lh3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/05/2014 22:19, Jens Wagner wrote: > +1 > That would work, but according to the draft, EPP clients provide the > element on requests only. > Would also need the attribute for , renew, transfer and > so on. > Maybe we could use an element e.g. , instead of an attribute? Or= > also assign the attribute to the , ... elements= ? Yes, I realised that shortly after I sent the email. It needs to be an element rather than an attribute. perhaps? G. --=20 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. --6VKP5UVjTFUV2kAtlsjdXJaFLQaBJ4Lh3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNr+EwACgkQ6H45IPkjtM795wCfRBBizrHR2/1Up5W/I1fOQ5Qt KwoAoIF/Wn6aDodgTmzW/E6Sxoi/NRhJ =YboH -----END PGP SIGNATURE----- --6VKP5UVjTFUV2kAtlsjdXJaFLQaBJ4Lh3-- From nobody Thu May 8 14:43:37 2014 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FA01A0162 for ; Thu, 8 May 2014 14:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6dtZuYvyL7p for ; Thu, 8 May 2014 14:43:34 -0700 (PDT) Received: from internal-mail-out1.ispapi.net (internal-mail-out1.ispapi.net [93.190.234.74]) by ietfa.amsl.com (Postfix) with ESMTP id A30E21A0160 for ; Thu, 8 May 2014 14:43:34 -0700 (PDT) Received: from internal-mail-relay2.sls.de.hexonet.net (unknown [10.190.234.72]) by internal-mail-out1.ispapi.net (Postfix) with ESMTP id 9D8F810401A0; Thu, 8 May 2014 21:43:29 +0000 (UTC) Envelope-to: gavin.brown@centralnic.com, provreg@ietf.org Received: from p5dd446be.dip0.t-ipconnect.de ([93.212.70.190]:39825 helo=[192.168.2.120]) by internal-mail-relay2.sls.de.hexonet.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WiW6D-000484-Bp; Thu, 08 May 2014 21:43:29 +0000 Message-ID: <536BFA7F.8040300@hexonet.net> Date: Thu, 08 May 2014 23:43:27 +0200 From: Jens Wagner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Gavin Brown , "provreg@ietf.org" References: <53628077.8070402@centralnic.com> <536BA06C.4070004@hexonet.net> <536BC518.4050400@centralnic.com> <536BF4FB.9070709@hexonet.net> <536BF84C.6030302@centralnic.com> In-Reply-To: <536BF84C.6030302@centralnic.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 93.212.70.190 X-SA-Exim-Mail-From: jwagner@hexonet.net Archived-At: http://mailarchive.ietf.org/arch/msg/provreg/Xx6R1D-0HONyExEck5ackq7JI1s Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:43:36 -0000 Yes, or , I don't have any favorites. Thank you, - jens Am 08.05.2014 23:34, schrieb Gavin Brown: > On 08/05/2014 22:19, Jens Wagner wrote: >> +1 >> That would work, but according to the draft, EPP clients provide the >> element on requests only. >> Would also need the attribute for , renew, transfer and >> so on. >> Maybe we could use an element e.g. , instead of an attribute? Or >> also assign the attribute to the , ... elements? > Yes, I realised that shortly after I sent the email. It needs to be an > element rather than an attribute. > > perhaps? > > G. >