From gavin.brown@centralnic.com Fri Nov 1 03:12:24 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E78B11E81BF for ; Fri, 1 Nov 2013 03:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8inAxFTRrTUI for ; Fri, 1 Nov 2013 03:12:20 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id E250D11E8113 for ; Fri, 1 Nov 2013 03:12:19 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 0608A720565; Fri, 1 Nov 2013 10:12:17 +0000 (UTC) Message-ID: <52737E77.1080206@centralnic.com> Date: Fri, 01 Nov 2013 10:12:07 +0000 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.1.0 MIME-Version: 1.0 To: "Gould, James" , "provreg@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:12:24 -0000 Hi Jim, > 1. Why extend the check instead of info (e.g. fee info)? Because if the object doesn't exist, the server would have to return a response with a 2303 error, and an element. While this is permitted, my guess is that most EPP client libraries would see the error first, and therefore would require a special case in order to provide the extension data to the consuming application. Also, by extending the command, you avoid multiple round-trips: the client can query availability and the fee for a in a single command. > 2. How about supporting the use of the extension with the billable > commands themselves as well, where the client can ask for the fee > information and the server can return the information in the > response upon successful execution? That's potentially useful, but my belief was that clients would generally prefer to know the cost of a transaction *before* submitting it, rather than after it had been received by the server. It would still be desirable to include the fee information in the response however, to cover the edge case where the fee had changed since it was last checked. > 3. It would be good to support a more flexible set of commands, like we > support the concept of sync (consolidate extension) that is also > billable. There might be other billable commands. This could be achieved by changing the to allow any token, dictated by server policy. > 4. The fee could have an optional breakdown as well, where some > billable commands include a fixed fee plus another variable fee > (e.g. based on period extended). The total fee should obviously be > a total of the more detailed fees. The type of fees might need to > be flexible as well to support various billing models. The > Registrar might only be interested in the resulting fee, but having > the breakdown could be useful. > > 5. The client might be interested in any variable pricing based on > periods. The extension isn't designed to allow clients to enumerate the server's fee structure, just to determine the fee associated with a given transaction: this is in line with EPP's status as a provisioning protocol rather than a general purpose information-sharing system. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From gavin.brown@centralnic.com Fri Nov 1 03:18:15 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D738421E80A1 for ; Fri, 1 Nov 2013 03:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB-OW+L8dkqU for ; Fri, 1 Nov 2013 03:18:11 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26D11E8141 for ; Fri, 1 Nov 2013 03:18:07 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 99503720565; Fri, 1 Nov 2013 10:18:06 +0000 (UTC) Message-ID: <52737FD5.4060100@centralnic.com> Date: Fri, 01 Nov 2013 10:17:57 +0000 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.1.0 MIME-Version: 1.0 To: =?UTF-8?B?THVpcyBNdcOxb3o=?= , "Gould, James" References: <06FD9596-08BC-4D42-936E-01885F880601@isc.org> In-Reply-To: <06FD9596-08BC-4D42-936E-01885F880601@isc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:18:16 -0000 On 31/10/2013 18:52, Luis Muñoz wrote: > > On Oct 31, 2013, at 1:31 PM, Gould, James wrote: > >> • It would be good to support a more flexible set of commands, like we support the concept of sync (consolidate extension) that is also billable. There might be other billable commands. > > I agree to this. Creating launch applications, for example, could be something to add as well. Wouldn't the fee for the launch application simply be the fee? I suppose an optional "phase" attribute could be added to the element, e.g.: create create > While responding in an ISO 4217 currency works well, there should also be support to respond in opaque or internal value representations. It is conceivable that an EPP server is currency agnostic, instead working with internal currency units. ISO 4217 includes the special purpose "XXX" code for non-currency transactions. I think this would suffice for this purpose, but the draft could be updated to specifically refer to it. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From michael@mwyoung.ca Fri Nov 1 06:35:50 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49921E8450 for ; Fri, 1 Nov 2013 06:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVbMYMa7FQrr for ; Fri, 1 Nov 2013 06:35:40 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id E728B11E83BA for ; Fri, 1 Nov 2013 06:29:07 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b4so2542792qen.34 for ; Fri, 01 Nov 2013 06:29:07 -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=iA6UUPyoxMP1tOLncHWZcFbI/tBvwQZS9N/DifYFwiY=; b=RmFu2qUc/WkKDsr9G6kFWzqK8ajtsIdw9Ma9rm6x05vJS+LANqaVXFSHCyxa2hsU2M 9h0bxM/DWl/MyIt9C0ZHBe/gMivRPl+oviToQCjuPytAVZ4i+9Kx3i0KC/5vGquT1Jeb 1phgL9adIuiXFOp+rg+vaXF/mTJjpUNg/tIPH/W1UOubUrqIM91ZFlGmhfL3J2sD4e0d XxCq3IgYL0WPQegTkgMnJ6GIrsXbpSv9oD+ualI5dnP0EPsWn1d+mXbm1tXJH1TM68SZ DxLZaU5fKc9Bs+lTds6quFDnc+AQJNPo/QyadEfCrof2QpreFpgcFuYIp1iO0tFG1iux VubA== X-Gm-Message-State: ALoCoQk+s85GKQ/QPWA02ObylW1raNqlW+Mj6EHTA/MxtDnGWkHEW32EF45vqsSaojFRLRIsmuM/ X-Received: by 10.49.62.137 with SMTP id y9mr3837493qer.59.1383312546950; Fri, 01 Nov 2013 06:29:06 -0700 (PDT) Received: from [172.16.1.44] (CPE74d02b4255c8-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.3.13]) by mx.google.com with ESMTPSA id x1sm20981688qai.6.2013.11.01.06.29.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 06:29:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_619F725B-05A9-4B54-9B3A-CE62A5C209DB" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: MICHAEL W YOUNG In-Reply-To: <52737E77.1080206@centralnic.com> Date: Fri, 1 Nov 2013 09:29:03 -0400 Message-Id: <27CC8E58-8AC8-4875-A12D-55A6A7A1B31C@mwyoung.ca> References: <52737E77.1080206@centralnic.com> To: Gavin Brown X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 13:35:51 -0000 --Apple-Mail=_619F725B-05A9-4B54-9B3A-CE62A5C209DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Gavin, I'd rather leverage the extension off of the info command and expect the = sequence used would be check the info to see if a domain is = available and then check its price. Why? The principle of the check command originally was to keep a very cheap = command just to verify availability. In those registries that drop their domains in sequence (versus all at = once), the check command is a cheap command that allows registrars = competing for a dropped name to verify availability before they trigger = a create. (much better than add storms) Now I know we are talking about an optional extension, but if you want = to not have this spiral, then I think you put the extension elsewhere. We are talking about retrieving clarifying information and it just makes = sense that goes under domaininfo (although I totally understand your = efficiency argument Gavin, but I think that particular optimization is = at the expense of organization) All Best Michael Young On 2013-11-01, at 6:12 AM, Gavin Brown = wrote: > Hi Jim, >=20 >> 1. Why extend the check instead of info (e.g. fee info)? =20 >=20 > Because if the object doesn't exist, the server would have to return a > response with a 2303 error, and an element. While this is > permitted, my guess is that most EPP client libraries would see the > error first, and therefore would require a special case in order to > provide the extension data to the consuming application. >=20 > Also, by extending the command, you avoid multiple = round-trips: > the client can query availability and the fee for a in a = single > command. >=20 >> 2. How about supporting the use of the extension with the billable >> commands themselves as well, where the client can ask for the fee >> information and the server can return the information in the >> response upon successful execution? =20 >=20 > That's potentially useful, but my belief was that clients would > generally prefer to know the cost of a transaction *before* submitting > it, rather than after it had been received by the server. It would = still > be desirable to include the fee information in the response however, = to > cover the edge case where the fee had changed since it was last = checked. >=20 >> 3. It would be good to support a more flexible set of commands, like = we >> support the concept of sync (consolidate extension) that is also >> billable. There might be other billable commands. >=20 > This could be achieved by changing the to allow any = token, > dictated by server policy. >=20 >> 4. The fee could have an optional breakdown as well, where some >> billable commands include a fixed fee plus another variable fee >> (e.g. based on period extended). The total fee should obviously = be >> a total of the more detailed fees. The type of fees might need to >> be flexible as well to support various billing models. The >> Registrar might only be interested in the resulting fee, but = having >> the breakdown could be useful.=20 >>=20 >> 5. The client might be interested in any variable pricing based on >> periods. >=20 > The extension isn't designed to allow clients to enumerate the = server's > fee structure, just to determine the fee associated with a given > transaction: this is in line with EPP's status as a provisioning > protocol rather than a general purpose information-sharing system. >=20 > G. >=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/ >=20 > 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 MICHAEL W YOUNG michael@mwyoung.ca --Apple-Mail=_619F725B-05A9-4B54-9B3A-CE62A5C209DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii gavin.brown@centralnic.com&= gt; wrote:
Hi Jim,

1. Why extend = the check instead of info (e.g. fee info)? =  

Because if the object doesn't exist, the = server would have to return a
response with a 2303 error, and an = <extension> element. While this is
permitted, my guess is that = most EPP client libraries would see the
error first, and therefore = would require a special case in order to
provide the extension data = to the consuming application.

Also, by extending the = <check> command, you avoid multiple round-trips:
the client can = query availability and the fee for a <create> in a = single
command.

2. How about = supporting the use of the extension with the billable
=    commands themselves as well, where the client can ask = for the fee
   information and the server can return = the information in the
   response upon successful = execution?  

That's potentially useful, but my = belief was that clients would
generally prefer to know the cost of a = transaction *before* submitting
it, rather than after it had been = received by the server. It would still
be desirable to include the = fee information in the response however, to
cover the edge case where = the fee had changed since it was last checked.

3. It would be good to support a more flexible set of = commands, like we
   support the concept of sync = (consolidate extension) that is also
   billable. =  There might be other billable commands.

This = could be achieved by changing the <fee:action> to allow any = token,
dictated by server policy.

= 4. The fee could have an optional breakdown as well, where some
=    billable commands include a fixed fee plus another = variable fee
   (e.g. based on period extended). =  The total fee should obviously be
   a total of = the more detailed fees.  The type of fees might need to
=    be flexible as well to support various billing models. =  The
   Registrar might only be interested in = the resulting fee, but having
   the breakdown could = be useful.

5. The client might be interested in any variable = pricing based on
   periods.

The = extension isn't designed to allow clients to enumerate the = server's
fee structure, just to determine the fee associated with a = given
transaction: this is in line with EPP's status as a = provisioning
protocol rather than a general purpose = information-sharing system.

G.

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



MICHAEL W YOUNG



= --Apple-Mail=_619F725B-05A9-4B54-9B3A-CE62A5C209DB-- From gavin.brown@centralnic.com Fri Nov 1 08:37:30 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC0621E80D8 for ; Fri, 1 Nov 2013 08:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWWIocGic-qh for ; Fri, 1 Nov 2013 08:37:25 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC5B21E80CC for ; Fri, 1 Nov 2013 08:37:24 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 5048272070F for ; Fri, 1 Nov 2013 15:37:23 +0000 (UTC) Message-ID: <5273CAA9.7000107@centralnic.com> Date: Fri, 01 Nov 2013 15:37:13 +0000 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.1.0 MIME-Version: 1.0 To: provreg@ietf.org References: <52728A9C.40506@centralnic.com> In-Reply-To: <52728A9C.40506@centralnic.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:37:30 -0000 I've just updated the draft with feedback from Jim and Luis: https://raw.github.com/centralnic/epp-fee-extension/cecb02a/draft-brown-epp-fees.txt Changes: 1. Added note about the use of the "XXX" code for non-currency transactions. 2. Added phase attribute to the element. and normative reference to draft-tan-epp-launchphase. 3. Added description of extension to transform (create, renew, update, transfer request) and transfer query commands. 4. Added Acknowledgements and Change History sections. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From lem@isc.org Fri Nov 1 09:09:38 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44C711E8210 for ; Fri, 1 Nov 2013 09:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYorWLOGFOez for ; Fri, 1 Nov 2013 09:09:38 -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 183D421E8441 for ; Fri, 1 Nov 2013 09:09:36 -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 8AABB2383F2; Fri, 1 Nov 2013 16:09:23 +0000 (UTC) (envelope-from lem@isc.org) Received: from [192.168.0.148] (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0B358216C1E; Fri, 1 Nov 2013 16:08:39 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: <52737FD5.4060100@centralnic.com> Date: Fri, 1 Nov 2013 12:08:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06FD9596-08BC-4D42-936E-01885F880601@isc.org> <52737FD5.4060100@centralnic.com> To: Gavin Brown X-Mailer: Apple Mail (2.1283) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:09:38 -0000 On Nov 1, 2013, at 6:17 AM, Gavin Brown wrote: > Wouldn't the fee for the launch application simply be the = fee? > I suppose an optional "phase" attribute could be added to the > element, e.g.: >=20 > create > create Yes, but the sub-phase should be added as well. Perhaps create The subphase attribute could be made optional as perhaps the most common = use cases won't require it. >> While responding in an ISO 4217 currency works well, there should = also be support to respond in opaque or internal value representations. = It is conceivable that an EPP server is currency agnostic, instead = working with internal currency units. >=20 > ISO 4217 includes the special purpose "XXX" code for non-currency > transactions. I think this would suffice for this purpose, but the = draft > could be updated to specifically refer to it. Ah, excellent. Yes, I think this is a good mechanism to convey this = information. Best regards -lem From gavin.brown@centralnic.com Fri Nov 1 09:31:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F9211E8221 for ; Fri, 1 Nov 2013 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeytS9GoGWIq for ; Fri, 1 Nov 2013 09:31:30 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 08BD221E8092 for ; Fri, 1 Nov 2013 09:31:21 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id E3D4272070C; Fri, 1 Nov 2013 16:31:18 +0000 (UTC) Message-ID: <5273D74C.2080205@centralnic.com> Date: Fri, 01 Nov 2013 16:31:08 +0000 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.1.0 MIME-Version: 1.0 To: =?UTF-8?B?THVpcyBNdcOxb3o=?= References: <06FD9596-08BC-4D42-936E-01885F880601@isc.org> <52737FD5.4060100@centralnic.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:31:35 -0000 On 01/11/2013 16:08, Luis Muñoz wrote: > > On Nov 1, 2013, at 6:17 AM, Gavin Brown wrote: > >> Wouldn't the fee for the launch application simply be the fee? >> I suppose an optional "phase" attribute could be added to the >> element, e.g.: >> >> create >> create > > Yes, but the sub-phase should be added as well. Perhaps > > create > > The subphase attribute could be made optional as perhaps the most common use cases won't require it. I'll add this to the next version. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From JGould@verisign.com Fri Nov 1 12:10:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23E611E8146 for ; Fri, 1 Nov 2013 12:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgJwsw0dWJLv for ; Fri, 1 Nov 2013 12:10:30 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF411E8169 for ; Fri, 1 Nov 2013 12:10:28 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUnP8oyXY01Xa8rrCfoIYdlneipEEByYO@postini.com; Fri, 01 Nov 2013 12:10:30 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rA1JAR7j022221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 15:10:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 1 Nov 2013 15:10:26 -0400 From: "Gould, James" To: Gavin Brown , "provreg@ietf.org" Thread-Topic: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: AQHO1l8URhS6Vf344UipPTXcIskg7ZoQa/OAgABTSoA= Date: Fri, 1 Nov 2013 19:10:26 +0000 Message-ID: In-Reply-To: <52737E77.1080206@centralnic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:10:35 -0000 Gavin, My feedback is below. --=20 =20 JG =20 =20 James Gould Principal Software Engineer jgould@verisign.com =20 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 11/1/13 6:12 AM, "Gavin Brown" wrote: >Hi Jim, > >> 1. Why extend the check instead of info (e.g. fee info)? > >Because if the object doesn't exist, the server would have to return a >response with a 2303 error, and an element. While this is >permitted, my guess is that most EPP client libraries would see the >error first, and therefore would require a special case in order to >provide the extension data to the consuming application. > >Also, by extending the command, you avoid multiple round-trips: >the client can query availability and the fee for a in a single >command. I see this a fee info and not either a domain info or a fee check. A domain info with the fee extension could be defined as a fee info command and return the EPP response (not the domain info response) with just the fee extension similar to the claims check command and response in draft-tan-epp-launchphase. I don't recommend merging commands to reduce round trips, but to create commands for specific well defined purposes. The extension of an existing verb to define a new verb (e.g. update extension for restore or check extension for claims check) has been used in the past and I believe can be used here. > >> 2. How about supporting the use of the extension with the billable >> commands themselves as well, where the client can ask for the fee >> information and the server can return the information in the >> response upon successful execution? > >That's potentially useful, but my belief was that clients would >generally prefer to know the cost of a transaction *before* submitting >it, rather than after it had been received by the server. It would still >be desirable to include the fee information in the response however, to >cover the edge case where the fee had changed since it was last checked. Yes I see both cases, since the price might be a factor prior to sending the billable command, while returning what the fee was in the billable command response would help ensure that the right price was charged. > >> 3. It would be good to support a more flexible set of commands, like we >> support the concept of sync (consolidate extension) that is also >> billable. There might be other billable commands. > >This could be achieved by changing the to allow any token, >dictated by server policy. Yes, that is a good idea. > >> 4. The fee could have an optional breakdown as well, where some >> billable commands include a fixed fee plus another variable fee >> (e.g. based on period extended). The total fee should obviously be >> a total of the more detailed fees. The type of fees might need to >> be flexible as well to support various billing models. The >> Registrar might only be interested in the resulting fee, but having >> the breakdown could be useful. >> >> 5. The client might be interested in any variable pricing based on >> periods. > >The extension isn't designed to allow clients to enumerate the server's >fee structure, just to determine the fee associated with a given >transaction: this is in line with EPP's status as a provisioning >protocol rather than a general purpose information-sharing system. I see this as a real grey area, since you could have a targeted info command for the fee for a specific period or you could have a info command for the fee information of an individual billable command. Knowing whether or not there are different fees based on a range of periods may be useful as well. I don't imagine that the ranges will be that many, where most will consist of a single range (e.g. Fee X per year from 1 to 10 year periods). The default could be all periods, but supporting multiple variable fees with optional period range values and an optional fixed fee value could be supported. > >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. From gavin.brown@centralnic.com Mon Nov 4 05:16:43 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656ED11E81CC for ; Mon, 4 Nov 2013 05:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdT1Kbr1YE2L for ; Mon, 4 Nov 2013 05:16:37 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 1009811E81D2 for ; Mon, 4 Nov 2013 05:16:34 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 6E65672073A; Mon, 4 Nov 2013 13:16:30 +0000 (UTC) Message-ID: <52779E1E.7070209@centralnic.com> Date: Mon, 04 Nov 2013 13:16:14 +0000 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.1.0 MIME-Version: 1.0 To: "Gould, James" , "provreg@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:16:43 -0000 On 01/11/2013 19:10, Gould, James wrote: >>> 1. Why extend the check instead of info (e.g. fee info)? >> >> Because if the object doesn't exist, the server would have to return a >> response with a 2303 error, and an element. While this is >> permitted, my guess is that most EPP client libraries would see the >> error first, and therefore would require a special case in order to >> provide the extension data to the consuming application. >> >> Also, by extending the command, you avoid multiple round-trips: >> the client can query availability and the fee for a in a single >> command. > > I see this a fee info and not either a domain info or a fee check. [snip] I am now agnostic on whether to use or for this extension (having previously been in favour of ). When I originally wrote the predecessor to this extension back in 2011, I did have some reservations about which command to use, and spoke to Patrick Mevzek who (at the time) agreed with my decision to use . If anyone else has thoughts about the choice of command to extend, please speak now! > Yes I see both cases, since the price might be a factor prior to sending > the billable command, while returning what the fee was in the billable > command response would help ensure that the right price was charged. The latest version adds elements to the responses for , , and . >>> 3. It would be good to support a more flexible set of commands, like we >>> support the concept of sync (consolidate extension) that is also >>> billable. There might be other billable commands. >> >> This could be achieved by changing the to allow any token, >> dictated by server policy. > > Yes, that is a good idea. I have an update in the pipe which changes to a token. The text of the draft requires servers to support the basic EPP command set as a minimum, plus "restore" if RFC3915 is implemented. >> The extension isn't designed to allow clients to enumerate the server's >> fee structure, just to determine the fee associated with a given >> transaction: this is in line with EPP's status as a provisioning >> protocol rather than a general purpose information-sharing system. > > I see this as a real grey area, since you could have a targeted info > command for the fee for a specific period or you could have a info command > for the fee information of an individual billable command. Knowing > whether or not there are different fees based on a range of periods may be > useful as well. I don't imagine that the ranges will be that many, where > most will consist of a single range (e.g. Fee X per year from 1 to 10 year > periods). The default could be all periods, but supporting multiple > variable fees with optional period range values and an optional fixed fee > value could be supported. I suppose the element could be allowed to have multiple occurences, each with a description. For example: S: S: example.com S: EUR S: create S: 3 S: 2.50 S: 10.00 S: -2.50 S: The client would determine the final fee by totalling the value of each element. Servers would be under no obligation to send more than a single element, but could do so if desired. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From michael@mwyoung.ca Mon Nov 4 06:39:41 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E9B21E8197 for ; Mon, 4 Nov 2013 06:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gdnfgj2EDqRg for ; Mon, 4 Nov 2013 06:39:04 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC511E81DF for ; Mon, 4 Nov 2013 06:38:44 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id ar20so12006967iec.26 for ; Mon, 04 Nov 2013 06:38:24 -0800 (PST) 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:content-transfer-encoding:message-id:references :to; bh=tymGQxdO/z9zSE/DQH4EKXm9YfLvQTWe2OtgJCjaj3U=; b=e/YyAGUZ3UJJHUfelQv6DYLYjvYvGQAyAuyGR+BsASvCb7ffQh51+Q+sUL9XM7uiqk NjlUYQjto8mbtQRxE2rj0iPkGUH4oA0fuhoY85JRFGu0YgOiGqUWAbHQPJOqoHedul9L x6dpb2FPoNMwqqsEHtw4Wy+cb0LU9anbWq5uWCSrog5zTXXffq4ZwH5LXXyVG8+XD24K vxiXR1Xhs3S2ZygvEy/Csz5PGef1tjO9zAU3WSEJbn17pRmcguZaH0jbkBkI2yG1vjh7 lenir6ShcY8nhogcWQ25j1lqVfs3nJvnhnEv8NGkkDbM8wzBIzW/SQLEwDc2Pr/f+DeE M/7w== X-Gm-Message-State: ALoCoQlA8kFnrAWwwvLY131zsdKnhV6+x5MwUuhGzzLe5YNscboEwI2Y0C24KRlbx8u5Q5GnO8fm X-Received: by 10.50.8.102 with SMTP id q6mr7233879iga.57.1383575904438; Mon, 04 Nov 2013 06:38:24 -0800 (PST) Received: from [172.16.1.44] (CPE74d02b4255c8-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.3.13]) by mx.google.com with ESMTPSA id k6sm2254392igx.8.2013.11.04.06.38.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 06:38:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: MICHAEL W YOUNG In-Reply-To: <52779E1E.7070209@centralnic.com> Date: Mon, 4 Nov 2013 09:38:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52779E1E.7070209@centralnic.com> To: Gavin Brown X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 14:39:47 -0000 I weighed in earlier but it might have been lost in the noise > I am now agnostic on whether to use or for this = extension > (having previously been in favour of ). When I originally wrote > the predecessor to this extension back in 2011, I did have some > reservations about which command to use, and spoke to Patrick Mevzek = who > (at the time) agreed with my decision to use . >=20 > If anyone else has thoughts about the choice of command to extend, > please speak now! I like the principle of extending , it's in keeping with the = concept of retrieving clarifying information, whereas was meant = to be cheap, fast, light-weight. There are significant cases of implementations where the underlying = assumption is that is a cheap query. Some of which I was = directly involved with :-) -Michael Young= From lem@isc.org Mon Nov 4 07:22:53 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A6B21E81D1 for ; Mon, 4 Nov 2013 07:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiBnN6zJYVHv for ; Mon, 4 Nov 2013 07:22:52 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7C56121E81D3 for ; Mon, 4 Nov 2013 07:22:51 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by mx.ams1.isc.org (Postfix) with ESMTP id 537F42383DF; Mon, 4 Nov 2013 15:22:40 +0000 (UTC) (envelope-from lem@isc.org) Received: from [192.168.43.198] (me95536d0.tmodns.net [208.54.85.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 99D8F216C1E; Mon, 4 Nov 2013 15:21:56 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Mon, 4 Nov 2013 10:15:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> References: <52779E1E.7070209@centralnic.com> To: MICHAEL W YOUNG X-Mailer: Apple Mail (2.1283) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:22:53 -0000 On Nov 4, 2013, at 9:38 AM, MICHAEL W YOUNG wrote: > I like the principle of extending , it's in keeping with the = concept of retrieving clarifying information, whereas was meant = to be cheap, fast, light-weight. >=20 > There are significant cases of implementations where the underlying = assumption is that is a cheap query. Some of which I was = directly involved with :-) ++ -lem From gavin.brown@centralnic.com Mon Nov 4 08:32:53 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C733411E8270 for ; Mon, 4 Nov 2013 08:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnee8Y+2+-IK for ; Mon, 4 Nov 2013 08:32:48 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id EF63121E8171 for ; Mon, 4 Nov 2013 08:32:45 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 3CFBE72070A for ; Mon, 4 Nov 2013 16:32:44 +0000 (UTC) Message-ID: <5277CC1C.3000004@centralnic.com> Date: Mon, 04 Nov 2013 16:32:28 +0000 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.1.0 MIME-Version: 1.0 To: provreg@ietf.org References: <20131104162912.10152.86563.idtracker@ietfa.amsl.com> In-Reply-To: <20131104162912.10152.86563.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131104162912.10152.86563.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-00.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 16:32:53 -0000 Changes since the version I posted last week: 1. Added the subphase attribute to the element. 2. Removed the enumeration for the element so any token may be used. 3. Moved the fee lookup command from to . 4. Added an extension to the command to return credit information. 5. Changed MUSTs to MAYs so that the response extension elements can be omitted where no fee is applicable. 6. Update of introductory text. -------- Original Message -------- Subject: New Version Notification for draft-brown-epp-fees-00.txt Date: Mon, 04 Nov 2013 08:29:12 -0800 From: internet-drafts@ietf.org To: Gavin Brown A new version of I-D, draft-brown-epp-fees-00.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Filename: draft-brown-epp-fees Revision: 00 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Creation date: 2013-11-04 Group: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-00.txt Status: http://datatracker.ietf.org/doc/draft-brown-epp-fees Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-00 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for registry fees. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From jan@irial.com Mon Nov 4 09:55:32 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DFF11E821D for ; Mon, 4 Nov 2013 09:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQKC6AcQXWSS for ; Mon, 4 Nov 2013 09:55:22 -0800 (PST) Received: from assp.oa5.com (unknown [IPv6:2a01:c0:2:6:225:90ff:fed2:2b47]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA2411E8147 for ; Mon, 4 Nov 2013 09:54:39 -0800 (PST) Received: from [192.168.224.2] (localhost.localdomain [127.0.0.1]) jan@assp.knots.net (authenticated bits=0) by assp.oa5.com (8.14.4/8.12.11) with ESMTP id rA4HsXRQ018589 sender jan@irial.com for ; Mon, 4 Nov 2013 17:54:34 GMT Received: from [192.168.224.2] ([80.217.51.175] helo=[192.168.224.2]) by ASSP.OA5.COM with SMTP (2.3.3); 4 Nov 2013 17:54:33 +0000 Message-ID: <5277DF59.9030404@irial.com> Date: Mon, 04 Nov 2013 18:54:33 +0100 From: Jan Saell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: provreg@ietf.org References: <52779E1E.7070209@centralnic.com> <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> In-Reply-To: <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Assp-Version: 2.3.3(13276) on ASSP.OA5.COM X-Assp-ID: ASSP.OA5.COM X-Assp-Session: 7F842C33F548 (mail 1) X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:55:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have also a lot of implementations where you do a check before you do any other command so check should be as light and cheap as possible. So ++ here also. Best regards jan On 11/04/2013 04:15 PM, Luis Muñoz wrote: > > On Nov 4, 2013, at 9:38 AM, MICHAEL W YOUNG wrote: > >> I like the principle of extending , it's in keeping with the concept of retrieving clarifying information, whereas was meant to be cheap, fast, light-weight. >> >> There are significant cases of implementations where the underlying assumption is that is a cheap query. Some of which I was directly involved with :-) > > ++ > > -lem > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: jan@irial.com ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ331kACgkQQEpdoflEoIu/rQCeKQAcxS88O3YixdgXmE5062Q2 agEAoLkMuvpxhwjyRhnANyHv0Etl4k9W =S8JW -----END PGP SIGNATURE----- From gavin.brown@centralnic.com Mon Nov 4 12:28:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFB621E8109 for ; Mon, 4 Nov 2013 12:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5E6ceBkcSyP for ; Mon, 4 Nov 2013 12:28:23 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32A21E80FB for ; Mon, 4 Nov 2013 12:28:23 -0800 (PST) Received: from CNIC-MBP-200117.local (unknown [2.124.81.143]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id AAC3D720718; Mon, 4 Nov 2013 20:28:21 +0000 (UTC) Message-ID: <52780367.8070603@centralnic.com> Date: Mon, 04 Nov 2013 20:28:23 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Jan Saell , provreg@ietf.org References: <52779E1E.7070209@centralnic.com> <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> <5277DF59.9030404@irial.com> In-Reply-To: <5277DF59.9030404@irial.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 20:28:28 -0000 Hi Jan, As of version 0.3 (the 00 version I submitted to the IETF) the extension extends the command rather than the command. G. On 04/11/2013 17:54, Jan Saell wrote: > We have also a lot of implementations where you do a check before you do > any other command so check should be as light and cheap as possible. > > So ++ here also. > > Best regards > jan > > On 11/04/2013 04:15 PM, Luis Muñoz wrote: > >> On Nov 4, 2013, at 9:38 AM, MICHAEL W YOUNG wrote: > >>> I like the principle of extending , it's in keeping with the concept of retrieving clarifying information, whereas was meant to be cheap, fast, light-weight. >>> >>> There are significant cases of implementations where the underlying assumption is that is a cheap query. Some of which I was directly involved with :-) > >> ++ > >> -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 > -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From Patrick.Mevzek@afnic.fr Mon Nov 4 14:18:09 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CB121E823B for ; Mon, 4 Nov 2013 14:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOM3JF6XfE4j for ; Mon, 4 Nov 2013 14:18:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id EF61C21E817A for ; Mon, 4 Nov 2013 14:17:44 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6ED122801BE for ; Mon, 4 Nov 2013 23:17:11 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 6AE542801AC for ; Mon, 4 Nov 2013 23:17:11 +0100 (CET) Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:2219:7::86:96]) by relay1.nic.fr (Postfix) with ESMTP id 4454A4C007C; Mon, 4 Nov 2013 23:16:41 +0100 (CET) Message-ID: <1383603400.7757.12.camel@citrine-mobile> From: Patrick Mevzek To: provreg@ietf.org Date: Mon, 04 Nov 2013 23:16:40 +0100 In-Reply-To: References: <52779E1E.7070209@centralnic.com> Organization: AFNIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:18:09 -0000 Le lundi 04 novembre 2013 à 09:38 -0500, MICHAEL W YOUNG a écrit : > > I am now agnostic on whether to use or for this extension > > (having previously been in favour of ). When I originally wrote > > the predecessor to this extension back in 2011, I did have some > > reservations about which command to use, and spoke to Patrick Mevzek who > > (at the time) agreed with my decision to use . > > > > If anyone else has thoughts about the choice of command to extend, > > please speak now! > > > > I like the principle of extending , it's in keeping with the concept of retrieving clarifying information, whereas was meant to be cheap, fast, light-weight. The check can remain as light as it is today… since the fee structure is returned only if the fee extension is added in check command, so it is totally up to the registrar to see if they want it or not and if they want the super fast check without it or the heavier one with it. I have no strong opinion either way (and did not have time to extensively read the new extension proposal), but I still slightly prefer the check for this reason: my reading of the spirit of EPP is that "info" is to query data about an existing object in the registry database. In that way, a fee is not an object, and neither a property of a domain (it is a property of a transaction, not of a live object of a registry database) Hence, the need to do a domain:info on a *non-existing* yet domain name to find the cost of this creation is troublesome for me. While §2.9.2.2. of RFC530 can be read in many ways, I'm assessing it as "resData is there only in case of success" (and hence also ). I do also read exactly in the text: The EPP command is used to retrieve information associated with an existing object. So domain:info prior to a creation seem counter-nature to me -- Patrick Mevzek From sethamin@google.com Mon Nov 4 14:29:55 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABC111E822B for ; Mon, 4 Nov 2013 14:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcEr0RZ2IKpx for ; Mon, 4 Nov 2013 14:29:54 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9F63411E816D for ; Mon, 4 Nov 2013 14:29:32 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id w5so1819189vbf.38 for ; Mon, 04 Nov 2013 14:29:32 -0800 (PST) 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=6zufmp574BKl8C2d5eqcEl6mwWYKTtEQYDPZB2LMf7g=; b=dABffueeuL7ngsItWjGH9DU/IQL5uY7d27H/PeOru3pZgsiVdKdzh8CsHbxr0wTfEe k/q0CXLQoMlAJCxhvervxoxySSyEMkdPeilNtFdObu6eJgU+Fkl42ccqbYilQ6989zZg VQq/rvrxj2nvegAk/7AL9wErL8dOFL3cTGH7HIGSpCRG0KnrJSM4XB+KuJmlOTd/f0vR oT4HDTjUNKBUjXiJm32zZkx1NUzyzKeVH42aOEYKAeMHGDDfnv2FOsHY1384+LcN7rQO Vgg/1+Lh+Hmws7HZ6NURMNInnrQWY+zVrF2CEVAJcBOWqtK8Q920Ca/01k22wS3OTd1T wvlg== 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=6zufmp574BKl8C2d5eqcEl6mwWYKTtEQYDPZB2LMf7g=; b=Tghm2mnBbD6go9Q5XLIGN0yS6PYvXsrlCgLuAm6zDyZTOa7LRH4GGLHfBWsZaFGFMA KlnHUQy3itNmw3VXio5dGBr4ZL2ohgbDpFJEoWcgWS7DmDkJN0XM/CT7VZjO/kRLECDQ XVWYJojQ8chCRfqQSzys9ukvtv4PBFbg17prWN4qdq7y5E9+cM/ImGCoYS+tHBBdyqOM ctbrBm+45Zncs+qC4UY696uCBfQfVEvd6XlYan1LaGyuqPb/joclFjeBfCgychXDQLDS pPGxJOTWFnEKdWTf7q5e11Cb448VBhDqQeZ7cMFrqutv/tBJOeiElzsGvO+YZTcFYxfH VvPg== X-Gm-Message-State: ALoCoQmc1LsWn3YyJv2TWZd7KUub7kEZj8uzjuR5eurFw6qPVIc5z6236oBWFM0RHJYjIs/Txejkv/SmRr30xeDhXz/NZg2r5KHpZeLhvsKS+hgGYFISaTUWKygi5QJnDc8BdKPM312vM7elVk72Qc7GTL1zaxoyrnicmbtCF0Ugtg/DcyMDy9H40umiiBG2u0M6W2NTR6IG MIME-Version: 1.0 X-Received: by 10.52.157.232 with SMTP id wp8mr10989782vdb.4.1383604172026; Mon, 04 Nov 2013 14:29:32 -0800 (PST) Received: by 10.52.111.230 with HTTP; Mon, 4 Nov 2013 14:29:31 -0800 (PST) In-Reply-To: <52780367.8070603@centralnic.com> References: <52779E1E.7070209@centralnic.com> <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> <5277DF59.9030404@irial.com> <52780367.8070603@centralnic.com> Date: Mon, 4 Nov 2013 17:29:31 -0500 Message-ID: From: Seth Goldman To: Gavin Brown Content-Type: multipart/alternative; boundary=089e016339ee2f1c8804ea6173d4 Cc: EPP Provreg Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:29:55 -0000 --089e016339ee2f1c8804ea6173d4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with James' suggestion that the extension should be orthogonal to the billable command, and it should return the fee associated with that command. The advantage there is that you can retrieve the pricing to any EPP command, even ones that you haven't anticipated. Otherwise you have to model every possible variable to address the range of billable EPP commands (via fee:action, fee:period, the phase attribute, etc.), and you'll undoubtedly miss some. For example, some registries might want to charge a fee for changing the registrant; or updating the info of a contact object; or maybe an extra fee for adding more than N nameservers. I could imagine creative uses of a variable pricing to incentivize or deincentivize all sorts of different behaviors. Rather than trying to enumerate all possible cases, why not just use the existing modeling of these EPP commands? Even better would be to have two possible modes of the extension: the first would be a "dry-run" mode that would return the fee associated with the command, and the second would let the registrar to pass the fee with the command and have the registry fail if the fee doesn't match the actual billable amount. That way there can be no confusion as to what amount the registrar is getting charged. On Mon, Nov 4, 2013 at 3:28 PM, Gavin Brown wro= te: > Hi Jan, > > As of version 0.3 (the 00 version I submitted to the IETF) the extension > extends the command rather than the command. > > G. > > On 04/11/2013 17:54, Jan Saell wrote: > > We have also a lot of implementations where you do a check before you d= o > > any other command so check should be as light and cheap as possible. > > > > So ++ here also. > > > > Best regards > > jan > > > > On 11/04/2013 04:15 PM, Luis Mu=F1oz wrote: > > > >> On Nov 4, 2013, at 9:38 AM, MICHAEL W YOUNG wrote: > > > >>> I like the principle of extending , it's in keeping with the > concept of retrieving clarifying information, whereas was meant t= o > be cheap, fast, light-weight. > >>> > >>> There are significant cases of implementations where the underlying > assumption is that is a cheap query. Some of which I was directl= y > involved with :-) > > > >> ++ > > > >> -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 > > > > -- > 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 > --089e016339ee2f1c8804ea6173d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with James' suggestion that the extension shou= ld be orthogonal to the billable command, and it should return the fee asso= ciated with that command. The advantage there is that you can retrieve the = pricing to any EPP command, even ones that you haven't anticipated. Oth= erwise you have to model every possible variable to address the range of bi= llable EPP commands (via fee:action, fee:period, the phase attribute, etc.)= , and you'll undoubtedly miss some. For example, some registries might = want to charge a fee for changing the registrant; or updating the info of a= contact object; or maybe an extra fee for adding more than N nameservers. = I could imagine creative uses of a variable pricing to incentivize or deinc= entivize all sorts of different behaviors. Rather than trying to enumerate = all possible cases, why not just use the existing modeling of these EPP com= mands?

Even better would be to have two possible modes of the = extension: the first would be a "dry-run" mode that would return = the fee associated with the command, and the second would let the registrar= to pass the fee with the command and have the registry fail if the fee doe= sn't match the actual billable amount. That way there can be no confusi= on as to what amount the registrar is getting charged.


O= n Mon, Nov 4, 2013 at 3:28 PM, Gavin Brown <gavin.brown@centralni= c.com> wrote:
Hi Jan,

As of version 0.3 (the 00 version I submitted to the IETF) the extension extends the <info> command rather than the <check> command.

G.

On 04/11/2013 17:54, Jan Saell wrote:
> We have also a lot of implementations where you do a check before you = do
> any other command so check should be as light and cheap as possible. >
> So ++ here also.
>
> Best regards
> jan
>
> On 11/04/2013 04:15 PM, Luis Mu=F1oz wrote:
>
>> On Nov 4, 2013, at 9:38 AM, MICHAEL W YOUNG wrote:
>
>>> I like the principle of extending <info>, it's in ke= eping with the concept of retrieving clarifying information, whereas <ch= eck> was meant to be cheap, fast, light-weight.
>>>
>>> There are significant cases of implementations where the under= lying assumption is that <check> is a cheap query. =A0Some of which I= was directly involved with :-)
>
>> ++
>
>> -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
>

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

--089e016339ee2f1c8804ea6173d4-- From michael@mwyoung.ca Mon Nov 4 14:33:33 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A09811E816D for ; Mon, 4 Nov 2013 14:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arkqfOoLc06h for ; Mon, 4 Nov 2013 14:33:27 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by ietfa.amsl.com (Postfix) with ESMTP id B27FB11E8185 for ; Mon, 4 Nov 2013 14:33:23 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so13740561iec.27 for ; Mon, 04 Nov 2013 14:33:23 -0800 (PST) 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=Z8oQiGTEKrwlteCSIZdoqTojrtiuIpaV6KesD242p4k=; b=DJNNYTMZmGPHPSkLTlclPnr+yM7BzkROUmvm0am+lEMOvf0kvljjssSzc4sn4RM3Tg brDVoq3fa7B8PhfGoMGhUHoQVClRUJ4PY8gKkNsNymcnVX4k6dC19McwPNE+XHmVUVJ2 T7mHLcLCRyL9ubduvhqpgq7q4rBhDITUapMyuFY42+LadH8HxLVHxsUPbSR6pc3mwMiI MnINbfrHJGujtreyz9YkGmaDgMk6h8vSlEfQTQm8scoeyT2c6XHcK9I+vEs9ZY2bnmiV Ft/20SBB4d1rEhjiy316o3yIQfqz6p5bNMAL7lCgtP7iNI4agZbcBn7W6YfTmwsfnqA4 fM4Q== X-Gm-Message-State: ALoCoQl3NRIwth+DujB2pGRjk5Tx3JuLs6CDQgbrc3cNoSRO/Kjvz68f8LxQE6My4esNVvaJyvQB X-Received: by 10.50.11.11 with SMTP id m11mr13597097igb.47.1383604403240; Mon, 04 Nov 2013 14:33:23 -0800 (PST) Received: from [172.16.1.44] (CPE74d02b4255c8-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.3.13]) by mx.google.com with ESMTPSA id i11sm4779589igh.0.2013.11.04.14.33.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 14:33:22 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D9F9EFF-3B1C-48FD-BCB6-7C4B82FF8F71" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: MICHAEL W YOUNG In-Reply-To: <1383603400.7757.12.camel@citrine-mobile> Date: Mon, 4 Nov 2013 17:33:20 -0500 Message-Id: <50BA5417-0506-4976-A61E-8C7D26186D01@mwyoung.ca> References: <52779E1E.7070209@centralnic.com> <1383603400.7757.12.camel@citrine-mobile> To: Patrick Mevzek X-Mailer: Apple Mail (2.1510) Cc: provreg@ietf.org Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 22:33:33 -0000 --Apple-Mail=_3D9F9EFF-3B1C-48FD-BCB6-7C4B82FF8F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > So domain:info prior to a creation seem counter-nature to me >=20 Interesting point, however, Same principle applies with , if the domain doesn't exist in the = registry and you send back pricing information it's a query for = information about a non-existent domain object. Both and are referring to a domain object if it exists = and returning information (pricing) regardless if the domain object = doesn't exist. So, really, if anything, that supports the argument for new = commands,........and new objects (a pricing object) - now watch everyone = groan on the list. -M > --=20 > Patrick Mevzek >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL W YOUNG michael@mwyoung.ca --Apple-Mail=_3D9F9EFF-3B1C-48FD-BCB6-7C4B82FF8F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
So = domain:info prior to a creation seem counter-nature to = me



Interesting = point, however,

Same principle applies with = <check> , if the domain doesn't exist in the registry and you send = back pricing information it's a query for information about a = non-existent domain object.

Both <check> = and <info> are referring to a domain object if it exists and = returning information (pricing) regardless if the domain object doesn't = exist.

So, really, if anything, that supports = the argument for new commands,........and new objects (a pricing object) = - now watch everyone groan on the = list.

-M

-- =
Patrick = Mevzek


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



MICHAEL W YOUNG



= --Apple-Mail=_3D9F9EFF-3B1C-48FD-BCB6-7C4B82FF8F71-- From Patrick.Mevzek@afnic.fr Mon Nov 4 15:22:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2E921E8287 for ; Mon, 4 Nov 2013 15:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1cuHz-q9yJR for ; Mon, 4 Nov 2013 15:22:28 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id A308721E827A for ; Mon, 4 Nov 2013 15:21:54 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 169272801BE; Tue, 5 Nov 2013 00:21:22 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 12263280129; Tue, 5 Nov 2013 00:21:22 +0100 (CET) Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:2219:7::86:96]) by relay1.nic.fr (Postfix) with ESMTP id DE4234C007C; Tue, 5 Nov 2013 00:20:51 +0100 (CET) Message-ID: <1383607251.7757.18.camel@citrine-mobile> From: Patrick Mevzek To: MICHAEL W YOUNG Date: Tue, 05 Nov 2013 00:20:51 +0100 In-Reply-To: <50BA5417-0506-4976-A61E-8C7D26186D01@mwyoung.ca> References: <52779E1E.7070209@centralnic.com> <1383603400.7757.12.camel@citrine-mobile> <50BA5417-0506-4976-A61E-8C7D26186D01@mwyoung.ca> Organization: AFNIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: provreg@ietf.org Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:22:34 -0000 Le lundi 04 novembre 2013 à 17:33 -0500, MICHAEL W YOUNG a écrit : > > So domain:info prior to a creation seem counter-nature to me > > > Interesting point, however, > > > Same principle applies with , if the domain doesn't exist in > the registry and you send back pricing information it's a query for > information about a non-existent domain object. > Yes, but domain:check is tailored to operate on both existing and non-existing domain names per definition, while for me domain:info is not. Same problem with the launchphase extension during claims phase. > So, really, if anything, that supports the argument for new > commands,........and new objects (a pricing object) - now watch > everyone groan on the list. I was in fact about to suggest a "fee" object, but I sense it to be not worth the hassle, and have no time to work on that. I will implement the currently discussed draft both in the check or in the info command, I have no strong enough opinion. -- Patrick Mevzek From gavin.brown@centralnic.com Wed Nov 6 04:38:17 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C0E11E8104 for ; Wed, 6 Nov 2013 04:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtkErEgKAghQ for ; Wed, 6 Nov 2013 04:38:13 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2911E80F1 for ; Wed, 6 Nov 2013 04:38:12 -0800 (PST) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 557BC7204BD; Wed, 6 Nov 2013 12:38:10 +0000 (UTC) Message-ID: <527A381D.4010008@centralnic.com> Date: Wed, 06 Nov 2013 12:37:49 +0000 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.1.0 MIME-Version: 1.0 To: Seth Goldman References: <52779E1E.7070209@centralnic.com> <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> <5277DF59.9030404@irial.com> <52780367.8070603@centralnic.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: EPP Provreg Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 12:38:17 -0000 On 04/11/2013 22:29, Seth Goldman wrote: > I agree with James' suggestion that the extension should be orthogonal > to the billable command, and it should return the fee associated with > that command. The latest version does this - see Section 2.2 of the draft published on the IETF website. > Even better would be to have two possible modes of the extension: the > first would be a "dry-run" mode that would return the fee associated > with the command, and the second would let the registrar to pass the fee > with the command and have the registry fail if the fee doesn't match the > actual billable amount. That way there can be no confusion as to what > amount the registrar is getting charged. I was contacted off-list by another registry who have implemented an extension very similar to mine. Their extension provides a mechanism whereby the client includes the expected fee (previously obtained by performing a lookup) in the command. The server can then reject the command if the fee submitted does not match what it calculates it to be. This ensures that both client and server agree what the fee for the transaction is, before it takes place. I very much like this idea and am planning on incorporating it into the next version of my draft. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From maarten.bosteels@dns.be Wed Nov 6 04:55:16 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659F911E8197 for ; Wed, 6 Nov 2013 04:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzp9K4miXvxd for ; Wed, 6 Nov 2013 04:55:12 -0800 (PST) Received: from mta01.nug.nucleus.be (mta01.nug.nucleus.be [77.73.97.132]) by ietfa.amsl.com (Postfix) with ESMTP id E2C2D11E8195 for ; Wed, 6 Nov 2013 04:55:11 -0800 (PST) Received: from localhost (localhost6.localdomain6 [127.0.0.1]) by mta01.nug.nucleus.be (Postfix) with ESMTP id 8E2CB1212CD; Wed, 6 Nov 2013 13:55:09 +0100 (CET) Received: from mta01.nug.nucleus.be ([127.0.0.1]) by localhost (mta01.nug.nucleus.be [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QeZK1lX_PGD4; Wed, 6 Nov 2013 13:55:08 +0100 (CET) Received: from localhost (localhost6.localdomain6 [127.0.0.1]) by mta01.nug.nucleus.be (Postfix) with ESMTP id 2E97E121C67; Wed, 6 Nov 2013 13:55:08 +0100 (CET) X-Virus-Scanned: amavisd-new at mta01.nug.nucleus.be Received: from mta01.nug.nucleus.be ([127.0.0.1]) by localhost (mta01.nug.nucleus.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8JzszVKvIN4i; Wed, 6 Nov 2013 13:55:08 +0100 (CET) Received: from nug.nucleus.be (old.nug.nucleus.be [77.73.97.156]) by mta01.nug.nucleus.be (Postfix) with ESMTP id 067E91212CD; Wed, 6 Nov 2013 13:55:08 +0100 (CET) Date: Wed, 6 Nov 2013 13:55:07 +0100 (CET) From: Maarten Bosteels To: Gavin Brown Message-ID: <1889282799.7884880.1383742507913.JavaMail.zimbra@staff.dns.be> In-Reply-To: <527A381D.4010008@centralnic.com> References: <52779E1E.7070209@centralnic.com> <20636CAF-8C45-467D-B72D-0D15D076E0AD@isc.org> <5277DF59.9030404@irial.com> <52780367.8070603@centralnic.com> <527A381D.4010008@centralnic.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7884879_998531951.1383742507909" X-Originating-IP: [77.67.63.234] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC30 (Mac)/8.0.4_GA_5737) Thread-Topic: Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: rFK59SwR2u0Q+j/iZQoXkHQL5ETpYw== X-Mailman-Approved-At: Wed, 06 Nov 2013 12:39:56 -0800 Cc: EPP Provreg Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 12:55:16 -0000 ------=_Part_7884879_998531951.1383742507909 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit See also the EPP extension by ARI: http://ausregistry.github.io/doc/price-1.0/price-1.0.html which is also mentioned here: http://ariservices.com/registrars/ari-registry_implementation.pdf Maarten ----- Original Message ----- | From: "Gavin Brown" | To: "Seth Goldman" | Cc: "EPP Provreg" | Sent: Wednesday, 6 November, 2013 1:37:49 PM | Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning | Protocol | On 04/11/2013 22:29, Seth Goldman wrote: | > I agree with James' suggestion that the extension should be orthogonal | > to the billable command, and it should return the fee associated with | > that command. | The latest version does this - see Section 2.2 of the draft published on | the IETF website. | > Even better would be to have two possible modes of the extension: the | > first would be a "dry-run" mode that would return the fee associated | > with the command, and the second would let the registrar to pass the fee | > with the command and have the registry fail if the fee doesn't match the | > actual billable amount. That way there can be no confusion as to what | > amount the registrar is getting charged. | I was contacted off-list by another registry who have implemented an | extension very similar to mine. Their extension provides a mechanism | whereby the client includes the expected fee (previously obtained by | performing a lookup) in the command. The server can then reject the | command if the fee submitted does not match what it calculates it to be. | This ensures that both client and server agree what the fee for the | transaction is, before it takes place. | I very much like this idea and am planning on incorporating it into the | next version of my draft. | G. | -- | 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 ------=_Part_7884879_998531951.1383742507909 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
which is also mentioned here:  http://ariservices.com/registrars/a= ri-registry_implementation.pdf

Maarten=

From: "Gavin Brown" <gavin.brown@centralnic= .com>
To: "Seth Goldman" <sethamin@google.com>
Cc:= "EPP Provreg" <provreg@ietf.org>
Sent: Wednesday, 6 No= vember, 2013 1:37:49 PM
Subject: Re: [provreg] Registry Fee Exten= sion for the Extensible Provisioning Protocol

On 04/11/20= 13 22:29, Seth Goldman wrote:
> I agree with James' suggestion that t= he extension should be orthogonal
> to the billable command, and it s= hould return the fee associated with
> that command.

The latest version does this - see Section 2.2 of the draft published on<= br>the IETF website.

> Even better would be to have tw= o possible modes of the extension: the
> first would be a "dry-run" m= ode that would return the fee associated
> with the command, and the = second would let the registrar to pass the fee
> with the command and= have the registry fail if the fee doesn't match the
> actual billabl= e amount. That way there can be no confusion as to what
> amount the = registrar is getting charged.

I was contacted off-list by= another registry who have implemented an
extension very similar to mine= . Their extension provides a mechanism
whereby the client includes the e= xpected fee (previously obtained by
performing a lookup) in the command.= The server can then reject the
command if the fee submitted does not ma= tch what it calculates it to be.

This ensures that both c= lient and server agree what the fee for the
transaction is, before it ta= kes place.

I very much like this idea and am planning on = incorporating it into the
next version of my draft.

G.=

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

CentralNic Group plc is a company registe= red in England and Wales with
company number 8576358. Registered Offices= : 35-39 Moorgate, London,
EC2R 6AR.
_________________________________= ______________
provreg mailing list
provreg@ietf.org
https://www.i= etf.org/mailman/listinfo/provreg

------=_Part_7884879_998531951.1383742507909-- From keith@blacknight.com Thu Nov 7 08:04:29 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714AB21E81C3 for ; Thu, 7 Nov 2013 08:04:29 -0800 (PST) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mvDe9gi19vr for ; Thu, 7 Nov 2013 08:04:25 -0800 (PST) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB3C21E8116 for ; Thu, 7 Nov 2013 08:04:21 -0800 (PST) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id A55681B0002; Thu, 7 Nov 2013 16:04:20 +0000 (GMT) Date: Thu, 7 Nov 2013 16:04:20 +0000 From: Keith Gaughan To: provreg@ietf.org Message-ID: <20131107160420.GO1663@nineve.blacknight.ie> References: <20131031165212.58C7A5A400F@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131031165212.58C7A5A400F@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:04:29 -0000 On Thu, Oct 31, 2013 at 04:51:40PM +0000, Gavin Brown wrote: > Dear colleagues, > > As the I-D submission window is closed, I am unable to submit this to > the IETF, but I plan to do so once the submissions re-open. > > https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp-fees.txt > > I would like to request that this be considered for adoption by the > eppext group. One this I believe would be a worthwhile addition would be a mechanism for allowing registrars to be informed of their current balance on the message queue once is drops below a certain lower limit. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From JGould@verisign.com Thu Nov 7 09:08:53 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F346421E81F2 for ; Thu, 7 Nov 2013 09:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1lbu0072Unf for ; Thu, 7 Nov 2013 09:08:39 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 20C2821F9DBD for ; Thu, 7 Nov 2013 09:08:25 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUnvJCRVA1rmgDrMGRUlVYy0Xz9KRU9h8@postini.com; Thu, 07 Nov 2013 09:08:26 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rA7H8OGi013692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 12:08:24 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 7 Nov 2013 12:08:23 -0500 From: "Gould, James" To: Keith Gaughan , "provreg@ietf.org" Thread-Topic: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: AQHO29MEBri4q8qBCEi/slpqii0ZMJoZ73cA Date: Thu, 7 Nov 2013 17:08:22 +0000 Message-ID: In-Reply-To: <20131107160420.GO1663@nineve.blacknight.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CEA132085155Cjgouldverisigncom_" MIME-Version: 1.0 Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:08:53 -0000 X-List-Received-Date: Thu, 07 Nov 2013 17:08:53 -0000 --_000_CEA132085155Cjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Keith, We have two custom mappings that support balance and credit limit informati= on: 1. Low Balance Mapping - http://www.verisigninc.com/assets/low-balance-m= apping.pdf =96 This provides a poll message when the balance or credit limi= t gets below a specific threshold. 2. Balance Mapping - http://www.verisigninc.com/assets/epp-balance-mappi= ng.pdf =96 This gives the ability to query for the current balance and cred= it limit information. These might or might not fit into the Fee Extension, but might be of genera= l interest. Thanks, -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 11/7/13 11:04 AM, "Keith Gaughan" > wrote: On Thu, Oct 31, 2013 at 04:51:40PM +0000, Gavin Brown wrote: Dear colleagues, As the I-D submission window is closed, I am unable to submit this to the IETF, but I plan to do so once the submissions re-open. https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp-= fees.txt I would like to request that this be considered for adoption by the eppext group. One this I believe would be a worthwhile addition would be a mechanism for allowing registrars to be informed of their current balance on the message queue once is drops below a certain lower limit. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --_000_CEA132085155Cjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9EEA9EA1C8224B48A6A165F4374ACE6E@verisign.com> Content-Transfer-Encoding: quoted-printable
Keith,

We have two custom mappings that sup= port balance and credit limit information:
  1. Low Balance Mapping - http://w= ww.verisigninc.com/assets/low-balance-mapping.pdf =96 This provide= s a poll message when the balance or credit limit gets below a specific threshold.
  2. Balance Mapping - http://www.veri= signinc.com/assets/epp-balance-mapping.pdf =96 This gives the abil= ity to query for the current balance and credit limit information.  
These might or might not fit into the Fee Extension, but might be of g= eneral interest.  

Thanks,

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



On 11/7/= 13 11:04 AM, "Keith Gaughan" <keith@blacknight.com> wrote:

On Thu, Oct 31, 2013 at 04:51:40PM +0000, Gavin Brown wrote:
Dear colleagues,
As the I-D submission window is closed, I am unable to submit this to<= /div>
the IETF, but I plan to do so once the submissions re-open.
I would like to request that this be considered for adoption by the
eppext group.

One this I believe would be a worthwhile addition would be a mechanism=
for allowing registrars to be informed of their current balance on the=
message queue once is drops below a certain lower limit.

K.

--
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list

--_000_CEA132085155Cjgouldverisigncom_-- From wil@cloudregistry.net Tue Nov 12 23:56:39 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231B821F9DAA for ; Tue, 12 Nov 2013 23:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny03efA0SnZQ for ; Tue, 12 Nov 2013 23:56:32 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 102E021F9ECA for ; Tue, 12 Nov 2013 23:56:28 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id a1so40387wgh.12 for ; Tue, 12 Nov 2013 23:56:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=ug44y2FJh39HZH460tcD9pHDvCzLji02rle3gbmP61Y=; b=bKzY8FxdBinz7TIygyPLOYN/i2KrhEKfHa8ftBmJ0gVjKHsZf4qgetMRp1/tzq9pQJ YlVIl98tUiGKOxdP5oZpYh4nNyJYFrl9GWB6ENwVOEad8aO2Jx+1oFK00FEk/zVV91w3 LHADM7bVhuX1q/DVFZu4Sdjkj4bJHPZCwYBGzBPKb8zYr/7XuJeqwBg6cMuv4JPiWZcx EoAU9gCi8gDR0bcOsDn5FA3rUWhhSna8dd8+OCBcrbY8/ImpLYsd2uOKqNRrbJ0E3gSO gMDVGfueyi4eEZQZQCNtgySqE+WTl/ZW5Oz3MmbNVPpvwDciH5pYRknVuMw1jkPNporF gLuA== X-Gm-Message-State: ALoCoQm2xMaMpMboKnso4lLC2fhpDEh+1kvHlJvIUWNKauj5foSowjKHTZ7KZQZwXql2vfuyEW8n X-Received: by 10.180.188.48 with SMTP id fx16mr11354588wic.61.1384329387662; Tue, 12 Nov 2013 23:56:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.141 with HTTP; Tue, 12 Nov 2013 23:55:47 -0800 (PST) From: Wil Tan Date: Wed, 13 Nov 2013 18:55:47 +1100 Message-ID: To: "tmch-tech@icann.org" , "provreg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3889667791604eb0a4d53 Subject: [provreg] Launch Phase EPP Extension Version 12 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 07:56:39 -0000 --001a11c3889667791604eb0a4d53 Content-Type: text/plain; charset=UTF-8 Dear colleagues, James Gould, Gavin Brown and I have posted version 12 of the Launch Phase Mapping for EPP based on feedback from several members of the community. The specific changes from the previous version are: 1. Added support for multiple validator identifiers for claims notices and marks based on a request and text provided by Mike O'Connell. 2. Removed domain:exDate element from example in section 3.3.5 based on a request from Seth Goldman on the provreg list. 3. Added clarifying text for clients not passing the launch extension on update and delete commands to servers that do not support launch applications based on a request from Sharon Wodjenski on the provreg list. You can find the draft at http://www.ietf.org/id/draft-tan-epp-launchphase-12.txt Kind regards, .wil --001a11c3889667791604eb0a4d53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear colleagues,

James Gould= , Gavin Brown and I have posted version 12 of the Launch Phase Mapping for = EPP based on feedback from several members of the community. The specific c= hanges from the previous version are:

1. =C2=A0Added support for multiple validator identifie= rs for claims notices and marks based on a request and text provided by Mik= e O'Connell.

2. =C2=A0Removed domain:exDate el= ement from example in section 3.3.5 based on a request from Seth Goldman on= the provreg list.

3. =C2=A0Added clarifying text for clients not passing = the launch extension on update and delete commands to servers that do not s= upport launch applications based on a request from Sharon Wodjenski on the = provreg list.



Kind regard= s,

.wil
--001a11c3889667791604eb0a4d53-- From Klaus.Malorny@knipp.de Thu Nov 14 07:38:43 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3683011E8164 for ; Thu, 14 Nov 2013 07:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YZlJaHwGKlU for ; Thu, 14 Nov 2013 07:38:36 -0800 (PST) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id F11D421F9D8B for ; Thu, 14 Nov 2013 07:36:51 -0800 (PST) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 4198448; Thu, 14 Nov 2013 16:36:50 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id RMlpmNCr7pgx; Thu, 14 Nov 2013 16:36:42 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 0327D49; Thu, 14 Nov 2013 16:36:42 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id rAEFafBH003387; Thu, 14 Nov 2013 16:36:41 +0100 (MEZ) Message-ID: <5284EE10.5020809@knipp.de> Date: Thu, 14 Nov 2013 16:36:48 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Thunderbird/28.0a1 MIME-Version: 1.0 To: IETF Provreg Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [provreg] RFC 5733: street changes with contact:update X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:38:43 -0000 Hi all, a user of our registrar services discovered a strange behaviour with contact updates. Tracking down the problem, I determined that the respective registry is handling the differently to they way I expected and to the way we implemented this in our own registry software. Unfortunately, RFC 5733 does not specify the update in that depth, so I would like to know what was originally intended or is regarded as best practice. The problem refers to the streets in the contact. As you know, you can specify up to three line withing the address block. If one the request creates a contact with two lines, e.g. C20131114-01 John Doe ACME Solutions 100 Centre St second line Townsville County Derry Z1Z 1Z1 CA ... and later issues an update a with only one line, e.g. C20131114-01 John Doe ACME Solutions 200 Centre St Townsville County Derry Z1Z 1Z1 CA ... what shall be the outcome? The registry in question only replaces the first street line, retaining the second line: John Doe ACME Solutions 200 Centre St second line Townsville County Derry Z1Z 1Z1 CA However, I expected the old streets to be fully replaced. Or to be more clear, that the whole address block is replaced if given, meaning that if some of the data within is not given (e.g. ), it is implicitly cleared. So what is correct and what is wrong, what is the smallest unit that can individually be replaced while leaving other data unchanged? Thanks for any input. Regards, Klaus From shollenbeck@verisign.com Thu Nov 14 09:01:09 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4BA21E80E3 for ; Thu, 14 Nov 2013 09:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8nNWD1RkyvG for ; Thu, 14 Nov 2013 09:01:04 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id F01CC11E815B for ; Thu, 14 Nov 2013 09:01:00 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUoUBy9KndbdMA+7YCpspZKvCLfUkdQHn@postini.com; Thu, 14 Nov 2013 09:01:02 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAEH0xJ6010160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 12:00:59 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Nov 2013 12:00:58 -0500 From: "Hollenbeck, Scott" To: Klaus Malorny Thread-Topic: [provreg] RFC 5733: street changes with contact:update Thread-Index: AQHO4U+hsqdvOPg/FUSJFbOtlkz9Bpok844/ Date: Thu, 14 Nov 2013 17:00:58 +0000 Message-ID: References: <5284EE10.5020809@knipp.de> In-Reply-To: <5284EE10.5020809@knipp.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Provreg Mailing List Subject: Re: [provreg] RFC 5733: street changes with contact:update X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:01:09 -0000 A change implies "replace all", Klaus. Scott > On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" wr= ote: >=20 >=20 > Hi all, >=20 > a user of our registrar services discovered a strange behaviour with cont= act updates. Tracking down the problem, I determined that the respective re= gistry is handling the differently to they way I expected = and to the way we implemented this in our own registry software. Unfortunat= ely, RFC 5733 does not specify the update in that depth, so I would like to= know what was originally intended or is regarded as best practice. >=20 > The problem refers to the streets in the contact. As you know, you can sp= ecify up to three line withing the address block. >=20 > If one the request creates a contact with two lines, e.g= . >=20 > > C20131114-01 > > John Doe > ACME Solutions > > 100 Centre St > second line > Townsville > County Derry > Z1Z 1Z1 > CA > > > ... >=20 > and later issues an update a with only one line, e.g. >=20 > > C20131114-01 > > > John Doe > ACME Solutions > > 200 Centre St > Townsville > County Derry > Z1Z 1Z1 > CA > > > ... >=20 > what shall be the outcome? The registry in question only replaces the fir= st street line, retaining the second line: >=20 > > John Doe > ACME Solutions > > 200 Centre St > second line > Townsville > County Derry > Z1Z 1Z1 > CA > > >=20 > However, I expected the old streets to be fully replaced. Or to be more c= lear, that the whole address block is replaced if given, meaning that if so= me of the data within is not given (e.g. ), it is implicitly cleared. >=20 > So what is correct and what is wrong, what is the smallest unit that can = individually be replaced while leaving other data unchanged? >=20 > Thanks for any input. >=20 > Regards, >=20 > Klaus >=20 >=20 >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From sethamin@google.com Thu Nov 14 09:22:26 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B697A21E8098 for ; Thu, 14 Nov 2013 09:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c5CypGsp+ij for ; Thu, 14 Nov 2013 09:22:26 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C19A921E80F1 for ; Thu, 14 Nov 2013 09:22:25 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id cz12so2102212veb.2 for ; Thu, 14 Nov 2013 09:22:25 -0800 (PST) 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=VTLXD5blFj23fdA7iuzbe11nPUGazX219WaDT87KGDQ=; b=ffELokXr+PhmycLrWK4eJFUovOpO/9R6teluihRVgv5KtEI7DIngYXIv/XQlGUG1n2 1C3YHPocD6UHyo6VQNiTAihxwlrjpdvHfdl7bFEmwa/4qb+gondJXQF83Z+GgAbQJ0K6 hCRbEckBTKhkS4tcD0+hhGrwf44XLAM3VOwEuXyRUjLWAjsnFbgY1weNvjk0hvERlTOS 9oWUenuJ/UcIq4W1e8Ctb2xDQ3xUG8dwbKKGgfTiTLJg5NSxQs4nPXPbs7kP4J6/FMat +A8m7TUS9SmbgrB3JXEG1Pg9ab6aNjndpptfl+L5RHR2EXwop6OP2TKHt5EqojpbNOUy Qz4A== 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=VTLXD5blFj23fdA7iuzbe11nPUGazX219WaDT87KGDQ=; b=WbLmMu+IY7LZubA8PAqLwG1q+qspWEsJ6rz1hax8q52WMP+FJZQZeDwBRmSaEqy+Hf XeYtACsuebXYCl7rWb+/HGbnI5D6xvxcUL/Uxb0JuBiZK5wtQij3+jb2vu958PUNA7/T qtAvbQvYjljNz4JVqc0de1uJ3P/gL/aKnw7cgqJDTxzIqAH9Rd/224/529YNMJ/6RLva evt0LRsGts3zM1xzqx7zXy/ptib5Kumom8XYVpNtFRhNEls8L9G4bI9Lp7b774jKlI48 wFwimLgE9FSuxnzyZ3xdXXwdoAyUleYw50C8iGnc1BryFbyGEw1TaOHViL+vGCdwniTA bQBg== X-Gm-Message-State: ALoCoQlj13nyES/WoplZk6gfntELxIFf2TAVQC1MZVg+NXDY1kBiHLHrwW5///PP4vIl1pQIdQW8OGjHtAdflEYTrd+wm5dmtqw+elrnhP701jlHMh9YduOiGaOjJEYUtur7NggJ33A8dh7OcFdU8DqKxi46ZQu27iagW6v2bmFiHS7HntH3N5UCez5AF27hnPdvLpHX/MUe MIME-Version: 1.0 X-Received: by 10.220.42.212 with SMTP id t20mr352402vce.45.1384449744940; Thu, 14 Nov 2013 09:22:24 -0800 (PST) Received: by 10.52.111.230 with HTTP; Thu, 14 Nov 2013 09:22:24 -0800 (PST) In-Reply-To: References: <5284EE10.5020809@knipp.de> Date: Thu, 14 Nov 2013 12:22:24 -0500 Message-ID: From: Seth Goldman To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=047d7b3a886041cdea04eb2653e3 Cc: IETF Provreg Mailing List Subject: Re: [provreg] RFC 5733: street changes with contact:update X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:22:26 -0000 --047d7b3a886041cdea04eb2653e3 Content-Type: text/plain; charset=ISO-8859-1 Agreed, but at what level? The spec is unclear on this point. We have interpreted the replace semantics to act on the "postalInfo" element, but you could plausibly make an argument for replacing at lower level elements (e.g. "addr" or "name" elements). Regardless, I don't think the semantics you are seeing make any sense. It might be technically spec compliant, but it's not very useful. On Thu, Nov 14, 2013 at 12:00 PM, Hollenbeck, Scott < shollenbeck@verisign.com> wrote: > A change implies "replace all", Klaus. > > Scott > > > On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" > wrote: > > > > > > Hi all, > > > > a user of our registrar services discovered a strange behaviour with > contact updates. Tracking down the problem, I determined that the > respective registry is handling the differently to they > way I expected and to the way we implemented this in our own registry > software. Unfortunately, RFC 5733 does not specify the update in that > depth, so I would like to know what was originally intended or is regarded > as best practice. > > > > The problem refers to the streets in the contact. As you know, you can > specify up to three line withing the address block. > > > > If one the request creates a contact with two lines, > e.g. > > > > > > C20131114-01 > > > > John Doe > > ACME Solutions > > > > 100 Centre St > > second line > > Townsville > > County Derry > > Z1Z 1Z1 > > CA > > > > > > ... > > > > and later issues an update a with only one line, e.g. > > > > > > C20131114-01 > > > > > > John Doe > > ACME Solutions > > > > 200 Centre St > > Townsville > > County Derry > > Z1Z 1Z1 > > CA > > > > > > ... > > > > what shall be the outcome? The registry in question only replaces the > first street line, retaining the second line: > > > > > > John Doe > > ACME Solutions > > > > 200 Centre St > > second line > > Townsville > > County Derry > > Z1Z 1Z1 > > CA > > > > > > > > However, I expected the old streets to be fully replaced. Or to be more > clear, that the whole address block is replaced if given, meaning that if > some of the data within is not given (e.g. ), it is implicitly cleared. > > > > So what is correct and what is wrong, what is the smallest unit that can > individually be replaced while leaving other data unchanged? > > > > Thanks for any input. > > > > Regards, > > > > Klaus > > > > > > > > > > _______________________________________________ > > 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 > --047d7b3a886041cdea04eb2653e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agreed, but at what level? The spec is unclear on this poi= nt. We have interpreted the replace semantics to act on the "postalInf= o" element, but you could plausibly make an argument for replacing at = lower level elements (e.g. "addr" or "name" elements).<= div>
Regardless, I don't think the semantics you are seeing m= ake any sense. It might be technically spec compliant, but it's not ver= y useful.


On Thu, Nov 14, 2013 at 12:00 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com" target=3D"_blank">shollenbeck@ve= risign.com> wrote:
A change implies "replace all", Klaus.

Scott

> On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de> wrote:
>
>
> Hi all,
>
> a user of our registrar services discovered a strange behaviour with c= ontact updates. Tracking down the problem, I determined that the respective= registry is handling the <contact:update> differently to they way I = expected and to the way we implemented this in our own registry software. U= nfortunately, RFC 5733 does not specify the update in that depth, so I woul= d like to know what was originally intended or is regarded as best practice= .
>
> The problem refers to the streets in the contact. As you know, you can= specify up to three line withing the address block.
>
> If one the <contact:create> request creates a contact with two l= ines, e.g.
>
> <contact:create xmlns:contact=3D"urn:ietf:params:xml:ns:contac= t-1.0">
> =A0<contact:id>C20131114-01</contact:id>
> =A0<contact:postalInfo type=3D"int">
> =A0 =A0<contact:name>John Doe</contact:name>
> =A0 =A0<contact:org>ACME Solutions</contact:org>
> =A0 =A0<contact:addr>
> =A0 =A0 =A0<contact:street>100 Centre St</contact:street><= br> > =A0 =A0 =A0<contact:street>second line</contact:street> > =A0 =A0 =A0<contact:city>Townsville</contact:city>
> =A0 =A0 =A0<contact:sp>County Derry</contact:sp>
> =A0 =A0 =A0<contact:pc>Z1Z 1Z1</contact:pc>
> =A0 =A0 =A0<contact:cc>CA</contact:cc>
> =A0 =A0</contact:addr>
> =A0</contact:postalInfo>
> =A0...
>
> and later issues an update a <contact:update> with only one line= , e.g.
>
> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac= t-1.0">
> =A0<contact:id>C20131114-01</contact:id>
> =A0<contact:chg>
> =A0 =A0<contact:postalInfo type=3D"int">
> =A0 =A0 =A0<contact:name>John Doe</contact:name>
> =A0 =A0 =A0<contact:org>ACME Solutions</contact:org>
> =A0 =A0 =A0<contact:addr>
> =A0 =A0 =A0 =A0<contact:street>200 Centre St</contact:street&= gt;
> =A0 =A0 =A0 =A0<contact:city>Townsville</contact:city>
> =A0 =A0 =A0 =A0<contact:sp>County Derry</contact:sp>
> =A0 =A0 =A0 =A0<contact:pc>Z1Z 1Z1</contact:pc>
> =A0 =A0 =A0 =A0<contact:cc>CA</contact:cc>
> =A0 =A0 =A0</contact:addr>
> =A0 =A0</contact:postalInfo>
> =A0 =A0...
>
> what shall be the outcome? The registry in question only replaces the = first street line, retaining the second line:
>
> <contact:postalInfo type=3D'int'>
> =A0<contact:name>John Doe</contact:name>
> =A0<contact:org>ACME Solutions</contact:org>
> =A0<contact:addr>
> =A0 =A0<contact:street>200 Centre St</contact:street>
> =A0 =A0<contact:street>second line</contact:street>
> =A0 =A0<contact:city>Townsville</contact:city>
> =A0 =A0<contact:sp>County Derry</contact:sp>
> =A0 =A0<contact:pc>Z1Z 1Z1</contact:pc>
> =A0 =A0<contact:cc>CA</contact:cc>
> =A0</contact:addr>
> </contact:postalInfo>
>
> However, I expected the old streets to be fully replaced. Or to be mor= e clear, that the whole address block is replaced if given, meaning that if= some of the data within is not given (e.g. <sp>), it is implicitly c= leared.
>
> So what is correct and what is wrong, what is the smallest unit that c= an individually be replaced while leaving other data unchanged?
>
> Thanks for any input.
>
> Regards,
>
> Klaus
>
>
>
>
> _______________________________________________
> 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

--047d7b3a886041cdea04eb2653e3-- From shollenbeck@verisign.com Thu Nov 14 10:49:18 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA21521E811B for ; Thu, 14 Nov 2013 10:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdrmjkDlIFCD for ; Thu, 14 Nov 2013 10:49:13 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 21D5B21E8115 for ; Thu, 14 Nov 2013 10:48:50 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUoUbEoJ8b80M8hYQdz4N4nMzKhnrb/hm@postini.com; Thu, 14 Nov 2013 10:49:11 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAEImnSk013675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 13:48:49 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Nov 2013 13:48:49 -0500 From: "Hollenbeck, Scott" To: Seth Goldman Thread-Topic: [provreg] RFC 5733: street changes with contact:update Thread-Index: AQHO4U+hsqdvOPg/FUSJFbOtlkz9Bpok844/gABZzgD//8D6AA== Date: Thu, 14 Nov 2013 18:48:48 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <5284EE10.5020809@knipp.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F492D517EBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: IETF Provreg Mailing List Subject: Re: [provreg] RFC 5733: street changes with contact:update X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 18:49:18 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F492D517EBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't know how one can make a case that sub-element replacement is accept= able. Section 3.2.5 of RFC 5733 says this (emphasis mine): "The EPP command provides a transform operation that allows a clie= nt to modify the attributes of a contact _object_." and this: "An OPTIONAL element that contains _object attribute values t= o be changed_." The is thus focused on _changing_ the attributes of the _object_. = In the example Klaus provided, the command received is "replace the existin= g attribute with a new instance of ". The server failed to replace the two elements with the single = element provided in the . It shouldn't work that way. Scott From: Seth Goldman [mailto:sethamin@google.com] Sent: Thursday, November 14, 2013 12:22 PM To: Hollenbeck, Scott Cc: Klaus Malorny; IETF Provreg Mailing List Subject: Re: [provreg] RFC 5733: street changes with contact:update Agreed, but at what level? The spec is unclear on this point. We have inter= preted the replace semantics to act on the "postalInfo" element, but you co= uld plausibly make an argument for replacing at lower level elements (e.g. = "addr" or "name" elements). Regardless, I don't think the semantics you are seeing make any sense. It m= ight be technically spec compliant, but it's not very useful. On Thu, Nov 14, 2013 at 12:00 PM, Hollenbeck, Scott > wrote: A change implies "replace all", Klaus. Scott > On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" > wrote: > > > Hi all, > > a user of our registrar services discovered a strange behaviour with cont= act updates. Tracking down the problem, I determined that the respective re= gistry is handling the differently to they way I expected = and to the way we implemented this in our own registry software. Unfortunat= ely, RFC 5733 does not specify the update in that depth, so I would like to= know what was originally intended or is regarded as best practice. > > The problem refers to the streets in the contact. As you know, you can sp= ecify up to three line withing the address block. > > If one the request creates a contact with two lines, e.g= . > > > C20131114-01 > > John Doe > ACME Solutions > > 100 Centre St > second line > Townsville > County Derry > Z1Z 1Z1 > CA > > > ... > > and later issues an update a with only one line, e.g. > > > C20131114-01 > > > John Doe > ACME Solutions > > 200 Centre St > Townsville > County Derry > Z1Z 1Z1 > CA > > > ... > > what shall be the outcome? The registry in question only replaces the fir= st street line, retaining the second line: > > > John Doe > ACME Solutions > > 200 Centre St > second line > Townsville > County Derry > Z1Z 1Z1 > CA > > > > However, I expected the old streets to be fully replaced. Or to be more c= lear, that the whole address block is replaced if given, meaning that if so= me of the data within is not given (e.g. ), it is implicitly cleared. > > So what is correct and what is wrong, what is the smallest unit that can = individually be replaced while leaving other data unchanged? > > Thanks for any input. > > Regards, > > Klaus > > > > > _______________________________________________ > 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 --_000_831693C2CDA2E849A7D7A712B24E257F492D517EBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t know how one can make a case= that sub-element replacement is acceptable. Section 3.2.5 of RFC 5733 says= this (emphasis mine):

 

“The EPP <update> command prov= ides a transform operation that allows a client to modify the attributes of= a contact _object_.”

 

and this:

 

“An OPTIONAL <contact:chg> ele= ment that contains _object attribute values to be changed_.”

 

The <update> is thus focused on _= changing_ the attributes of the _object_. In the example Klaus p= rovided, the command received is “replace the existing <contact:po= stalInfo> attribute with a new instance of <contact:postalInfo>”. The se= rver failed to replace the two <street> elements with the single elem= ent provided in the <update>. It shouldn’t work that way.<= /o:p>

 

Scott

 

From: Seth Gol= dman [mailto:sethamin@google.com]
Sent: Thursday, November 14, 2013 12:22 PM
To: Hollenbeck, Scott
Cc: Klaus Malorny; IETF Provreg Mailing List
Subject: Re: [provreg] RFC 5733: street changes with contact:update<= o:p>

 

Agreed, but at what level? The spec is unclear on th= is point. We have interpreted the replace semantics to act on the "pos= talInfo" element, but you could plausibly make an argument for replaci= ng at lower level elements (e.g. "addr" or "name" elements).

 

Regardless, I don't think the semantics you are seei= ng make any sense. It might be technically spec compliant, but it's not ver= y useful.

 

On Thu, Nov 14, 2013 at 12:00 PM, Hollenbeck, Scott = <shollenbe= ck@verisign.com> wrote:

A change implies "replace all", Klaus.

Scott


> On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de> wrote:
>
>
> Hi all,
>
> a user of our registrar services discovered a strange behaviour with c= ontact updates. Tracking down the problem, I determined that the respective= registry is handling the <contact:update> differently to they way I = expected and to the way we implemented this in our own registry software. Unfortunately, RFC 5733 does not specify the= update in that depth, so I would like to know what was originally intended= or is regarded as best practice.
>
> The problem refers to the streets in the contact. As you know, you can= specify up to three line withing the address block.
>
> If one the <contact:create> request creates a contact with two l= ines, e.g.
>
> <contact:create xmlns:contact=3D"urn:ietf:params:xml:ns:contac= t-1.0">
>  <contact:id>C20131114-01</contact:id>
>  <contact:postalInfo type=3D"int">
>    <contact:name>John Doe</contact:name>
>    <contact:org>ACME Solutions</contact:org>
>    <contact:addr>
>      <contact:street>100 Centre St</contact:st= reet>
>      <contact:street>second line</contact:stre= et>
>      <contact:city>Townsville</contact:city>= ;
>      <contact:sp>County Derry</contact:sp><= br> >      <contact:pc>Z1Z 1Z1</contact:pc>
>      <contact:cc>CA</contact:cc>
>    </contact:addr>
>  </contact:postalInfo>
>  ...
>
> and later issues an update a <contact:update> with only one line= , e.g.
>
> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac= t-1.0">
>  <contact:id>C20131114-01</contact:id>
>  <contact:chg>
>    <contact:postalInfo type=3D"int">
>      <contact:name>John Doe</contact:name><= br> >      <contact:org>ACME Solutions</contact:org&= gt;
>      <contact:addr>
>        <contact:street>200 Centre St</con= tact:street>
>        <contact:city>Townsville</contact:= city>
>        <contact:sp>County Derry</contact:= sp>
>        <contact:pc>Z1Z 1Z1</contact:pc>= ;
>        <contact:cc>CA</contact:cc>
>      </contact:addr>
>    </contact:postalInfo>
>    ...
>
> what shall be the outcome? The registry in question only replaces the = first street line, retaining the second line:
>
> <contact:postalInfo type=3D'int'>
>  <contact:name>John Doe</contact:name>
>  <contact:org>ACME Solutions</contact:org>
>  <contact:addr>
>    <contact:street>200 Centre St</contact:street>= ;
>    <contact:street>second line</contact:street><= br> >    <contact:city>Townsville</contact:city>
>    <contact:sp>County Derry</contact:sp>
>    <contact:pc>Z1Z 1Z1</contact:pc>
>    <contact:cc>CA</contact:cc>
>  </contact:addr>
> </contact:postalInfo>
>
> However, I expected the old streets to be fully replaced. Or to be mor= e clear, that the whole address block is replaced if given, meaning that if= some of the data within is not given (e.g. <sp>), it is implicitly c= leared.
>
> So what is correct and what is wrong, what is the smallest unit that c= an individually be replaced while leaving other data unchanged?
>
> Thanks for any input.
>
> Regards,
>
> Klaus
>
>
>
>
> _______________________________________________
> 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

 

--_000_831693C2CDA2E849A7D7A712B24E257F492D517EBRN1WNEXMBX01vc_-- From qichao@cnnic.cn Thu Nov 14 21:33:53 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8611E8119 for ; Thu, 14 Nov 2013 21:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.5 X-Spam-Level: X-Spam-Status: No, score=-93.5 tagged_above=-999 required=5 tests=[AWL=1.431, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oxa7OIufbMw for ; Thu, 14 Nov 2013 21:33:48 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 9751A11E8127 for ; Thu, 14 Nov 2013 21:33:45 -0800 (PST) X-EYOUMAIL-SMTPAUTH: qichao@cnnic.cn Received: from unknown218.241.111.100 (HELO qichao) (218.241.111.100) by 218.241.118.7 with SMTP; Fri, 15 Nov 2013 13:33:42 +0800 Date: Fri, 15 Nov 2013 13:33:44 +0800 Organization: CNNIC From: =?GB2312?B?xuuzrA==?= To: "provreg@ietf.org" , "Klaus Malorny" References: <5284EE10.5020809@knipp.de> X-Priority: 3 X-Mailer: Foxmail 7.0.1.76[cn] Mime-Version: 1.0 Message-ID: <20131115133344234416115@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart523775815062_=----" Subject: Re: [provreg] RFC 5733: street changes with contact:update X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 05:33:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart523775815062_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sIEtsYXVzLA0KDQpJIHRoaW5rIGl0IGlzIG5lY2Vzc2FyeSB0byBjb21lIHRvIGEgY29u Y2x1c2lvbiB3aGF0IGlzIG1lYW5pbmcgb2YgIGxhYmVsIDxjb250YWN0OnN0cmVldD4gOg0KMSwg ICB0d28gPHN0cmVldD4gaXMgYWx0ZXJuYXRpdmUsICBlLmcuDQogICBDOiAgICAgICAgICAgIDxj b250YWN0OnN0cmVldD5vbmUgYWRkcmVzczwvY29udGFjdDpzdHJlZXQ+DQogICBDOiAgICAgICAg ICAgIDxjb250YWN0OnN0cmVldD5hbm90aGVyIGFkZHJlc3M8L2NvbnRhY3Q6c3RyZWV0Pg0KICAg QzogICAgICAgICAgICA8Y29udGFjdDpjaXR5PkR1bGxlczwvY29udGFjdDpjaXR5Pg0KICAgQzog ICAgICAgICAgICA8Y29udGFjdDpzcD5WQTwvY29udGFjdDpzcD4NCiAgIEM6ICAgICAgICAgICAg PGNvbnRhY3Q6cGM+MjAxNjYtNjUwMzwvY29udGFjdDpwYz4NCiAgIEM6ICAgICAgICAgICAgPGNv bnRhY3Q6Y2M+VVM8L2NvbnRhY3Q6Y2M+ICANCjIsICAgdHdvIDxzdHJlZXQ+ICBpcyBzdXBwb3Nl ZCB0byBiZSBjb21wb3NlZCB0byBhIGNvbXBsZXRlIGFkZHJlc3MsIGUuZy4NCiAgIEM6ICAgICAg ICAgICAgPGNvbnRhY3Q6c3RyZWV0PmhpZ2ggbGV2ZWwgb2YgYWRkcmVzczwvY29udGFjdDpzdHJl ZXQ+DQogICBDOiAgICAgICAgICAgIDxjb250YWN0OnN0cmVldD5sb3cgbGV2ZWwgb2YgYWRkcmVz czwvY29udGFjdDpzdHJlZXQ+DQogICBDOiAgICAgICAgICAgIDxjb250YWN0OmNpdHk+RHVsbGVz PC9jb250YWN0OmNpdHk+DQogICBDOiAgICAgICAgICAgIDxjb250YWN0OnNwPlZBPC9jb250YWN0 OnNwPg0KICAgQzogICAgICAgICAgICA8Y29udGFjdDpwYz4yMDE2Ni02NTAzPC9jb250YWN0OnBj Pg0KICAgQzogICAgICAgICAgICA8Y29udGFjdDpjYz5VUzwvY29udGFjdDpjYz4NCg0KZm9yIDEs IHJlcGxhY2luZyBvbmUgaXMgYWNjZXB0YWJsZS4NCg0KZm9yIDIsIHJlcGxhY2luZyBhbGwgaXMg cmVhc29uYWJsZS4NCg0KDQpUaGUgUkZDNTczMyBleGFtcGxlIGlzIDoNCiAgIEM6ICAgICAgICAg ICAgPGNvbnRhY3Q6YWRkcj4NCiAgIEM6ICAgICAgICAgICAgICA8Y29udGFjdDpzdHJlZXQ+MTI0 IEV4YW1wbGUgRHIuPC9jb250YWN0OnN0cmVldD4NCiAgIEM6ICAgICAgICAgICAgICA8Y29udGFj dDpzdHJlZXQ+U3VpdGUgMjAwPC9jb250YWN0OnN0cmVldD4NCiAgIEM6ICAgICAgICAgICAgICA8 Y29udGFjdDpjaXR5PkR1bGxlczwvY29udGFjdDpjaXR5Pg0KICAgQzogICAgICAgICAgICAgIDxj b250YWN0OnNwPlZBPC9jb250YWN0OnNwPg0KICAgQzogICAgICAgICAgICAgIDxjb250YWN0OnBj PjIwMTY2LTY1MDM8L2NvbnRhY3Q6cGM+DQogICBDOiAgICAgICAgICAgICAgPGNvbnRhY3Q6Y2M+ VVM8L2NvbnRhY3Q6Y2M+DQogICBDOiAgICAgICAgICAgIDwvY29udGFjdDphZGRyPg0KDQpUd28g c3RyZWV0cyAnU3VpdGUgMjAwJyBhbmQgJzEyNCBFeGFtcGxlIERyLicgaXMgbm90IG9idmlvdXMg Zm9yIG1lLi4uICBDYW4gYW55Ym9keSBleHBsYWluIGl0Pw== ------=_001_NextPart523775815062_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
Hello, Klaus,=
 
I=20 think it is necessary to come = to a=20 conclusion what is meaning of  label <contact:street>=20 :
= 1,  =20 two <street> is alternative,  e.g.
= 
   C:            <contact=
:street>one address</contact:street>
   C:            <contact:street>another address</contact:street&=
gt;
   C:            <contact:city>Dulles</contact:city>
   C:            <contact:sp>VA</contact:sp>
   C:            <contact:pc>20166-6503</contact:pc>
   C:            <contact:cc>US</contact:cc>
 
 <=
/SPAN>

=
2,  =20
two <street>  is supposed to be composed to a complete add=
ress,=20
e.g.
=

   C:            <contact=
:street>high level of address</contact:street>
   C:            <contact:street>low level of address</contact:st=
reet>
   C:            <contact:city>Dulles</contact:city>
   C:            <contact:sp>VA</contact:sp>
   C:            <contact:pc>20166-6503</contact:pc>
   C:            <contact:cc>US</contact:cc>


 


for 1, replac=
ing one=20
is acceptable.


 


for 2, replac=
ing all=20
is reasonable.


 


 


The RFC5733 e=
xample=20
is :


   C:            <contact:addr>
   C:              <contact:street>124 Example Dr.</contact:stree=
t>
   C:              <contact:street>Suite 200</contact:street>
   C:              <contact:city>Dulles</contact:city>
   C:              <contact:sp>VA</contact:sp>
   C:              <contact:pc>20166-6503</contact:pc>
   C:              <contact:cc>US</contact:cc>
   C:            </contact:addr>


 


Two streets '=
Suite=20
200' and '124 Example Dr.' is not obvious for me...  Can anybody expl=
ain=20
it?


------=_001_NextPart523775815062_=------


From Klaus.Malorny@knipp.de  Fri Nov 15 01:01:54 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DC111E810A for ; Fri, 15 Nov 2013 01:01:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfI+ucsTVtjC for ; Fri, 15 Nov 2013 01:01:48 -0800 (PST)
Received: from kmx10a.knipp.de (clust3b.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id E98B711E8102 for ; Fri, 15 Nov 2013 01:01:47 -0800 (PST)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 52BE957; Fri, 15 Nov 2013 10:01:45 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id RQgy3+1xNd-m; Fri, 15 Nov 2013 10:01:28 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 21E8051; Fri, 15 Nov 2013 10:01:23 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id rAF91LBC020321;  Fri, 15 Nov 2013 10:01:22 +0100 (MEZ)
Message-ID: <5285E2E8.7020304@knipp.de>
Date: Fri, 15 Nov 2013 10:01:28 +0100
From: Klaus Malorny 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Thunderbird/28.0a1
MIME-Version: 1.0
To: "Hollenbeck, Scott" , Seth Goldman 
References: <5284EE10.5020809@knipp.de>		 <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: IETF Provreg Mailing List 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 09:01:54 -0000

On 14.11.2013 19:48, Hollenbeck, Scott wrote:
> I don=E2=80=99t know how one can make a case that sub-element replaceme=
nt is acceptable.
> Section 3.2.5 of RFC 5733 says this (emphasis mine):
>
> =E2=80=9CThe EPP  command provides a transform operation that a=
llows a client to
> modify the attributes of a contact _/object/_.=E2=80=9D
>
> and this:
>
> =E2=80=9CAn OPTIONAL  element that contains _/object attri=
bute values to be
> changed/_.=E2=80=9D
>
> The  is thus focused on _/changing/_ the attributes of the _/ob=
ject/_.
> In the example Klaus provided, the command received is =E2=80=9Creplace=
 the existing
>  attribute with a new instance of =E2=80=9D. The
> server failed to replace the two  elements with the single elem=
ent
> provided in the . It shouldn=E2=80=99t work that way.
>
> Scott
>

Hi Scot, Seth,

up to now I regarded the name, the organization and the the whole address=
 block=20
as the replacable units, derived from the associated XML schema. It namel=
y=20
contains two datatypes, "postalInfoType" for the create command and=20
"chgPostalInfoType" for the update command. The first contains the =
 and=20
 elements as mandatory elements, the latter contains them as option=
al=20
elements. If one would consider the postalInfo itself as the replacable u=
nit, it=20
would not make sense to enforce the name and address on , but wou=
ld=20
allow to remove them with a following  request.

So simply asked: What does the following schema-wise legal request do?


   C20131114-01
   
     
   


Does it clear the international contact? Does it leave the international =
postal=20
data simply unchanged (aside from being illegal in Scot's view to submit =
a=20
command that is effectively non-modifying). Does the following command


   C20131114-01
   
     
       ACME Solutions
     
   


modify the postal info so that it *solely* contains the organization and =
nothing=20
else afterwards?

Regards,

Klaus











From Klaus.Malorny@knipp.de  Fri Nov 15 01:16:25 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4D611E810A for ; Fri, 15 Nov 2013 01:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o+jggxhe7aE for ; Fri, 15 Nov 2013 01:16:18 -0800 (PST)
Received: from kmx10a.knipp.de (clust3b.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id 242B011E8109 for ; Fri, 15 Nov 2013 01:16:17 -0800 (PST)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id CE5154C; Fri, 15 Nov 2013 10:16:16 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id Ul3v5HFO652A; Fri, 15 Nov 2013 10:16:06 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 34BD94A; Fri, 15 Nov 2013 10:16:05 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id rAF9G4fW021999;  Fri, 15 Nov 2013 10:16:05 +0100 (MEZ)
Message-ID: <5285E65B.1050400@knipp.de>
Date: Fri, 15 Nov 2013 10:16:11 +0100
From: Klaus Malorny 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Thunderbird/28.0a1
MIME-Version: 1.0
To: =?UTF-8?B?6b2Q6LaF?= , "provreg@ietf.org" 
References: <5284EE10.5020809@knipp.de> <2013111510482550010180@cnnic.cn>
In-Reply-To: <2013111510482550010180@cnnic.cn>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 09:16:25 -0000

On 15.11.2013 03:48, =E9=BD=90=E8=B6=85 wrote:
> Hello, Klaus,
> I think it is necessary to come to a conclusion what is meaning of  lab=
el
>  :
> 1, two  is alternative
>
>     C:            one address
>     C:            another address
>     C:            Dulles
>     C:            VA
>     C:            20166-6503
>     C:            US
>
>
>
>
>
> 2, two   compose to a complete address
>
>     C:            high level of address
>     C:            low level of address=

>     C:            Dulles
>     C:            VA
>     C:            20166-6503
>     C:            US
>
> for 1, replacing one is reasonable
> for 2, replacing all is reasonable.
> The RFC5733 example is :
>
>     C:            
>     C:              124 Example Dr.
>     C:              Suite 200
>     C:              Dulles
>     C:              VA
>     C:              20166-6503
>     C:              US
>     C:            
>
> Two streets 'Suite 200' and '124 Example Dr.' is not distinct for me...=


Hi =E9=BD=90=E8=B6=85,

I think it is clearly the second case. If these would be alternative addr=
esses,=20
then it would probably not be sufficient just to specify different street=
s. The=20
locations could be in different urban districts (maybe causing different =
postal=20
codes) or even different cities, states/provinces and countries. There ar=
e=20
multiple streets to give room for more specific addresses, for example fo=
r large=20
business buildings hosting a lot of companies, to specify departmental=20
information in large companies or to allow different addressing schemes -=
- the=20
western scheme of street names and house numbers are not necessarily appl=
ied=20
world-wide.

Regards,

Klaus



From qichao@cnnic.cn  Fri Nov 15 01:49:04 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734BB11E810D for ; Fri, 15 Nov 2013 01:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.612
X-Spam-Level: 
X-Spam-Status: No, score=-96.612 tagged_above=-999 required=5 tests=[AWL=3.827, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYd-g6BQ26l8 for ; Fri, 15 Nov 2013 01:48:59 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 9E64911E8102 for ; Fri, 15 Nov 2013 01:48:57 -0800 (PST)
X-EYOUMAIL-SMTPAUTH: qichao@cnnic.cn
Received: from unknown218.241.111.100 (HELO qichao) (218.241.111.100) by 218.241.118.7 with SMTP; Fri, 15 Nov 2013 17:48:53 +0800
Date: Fri, 15 Nov 2013 17:48:55 +0800
Organization: CNNIC
From: =?utf-8?B?6b2Q6LaF?= 
To: "Klaus Malorny" 
References: <5284EE10.5020809@knipp.de>		<831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <5285E2E8.7020304@knipp.de>
X-Priority: 3
X-Mailer: Foxmail 7.0.1.76[cn]
Mime-Version: 1.0
Message-ID: <20131115174854953765161@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart608215171534_=----"
Cc: "provreg@ietf.org" 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 09:49:04 -0000

This is a multi-part message in MIME format.

------=_001_NextPart608215171534_=----
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8gS2xhdXMsDQoNCiAgICBJbiBteSBvcGluaW9uICwgIDxjb250YWN0OnJlbT4gd2lsbCBi
ZSB1c2VkIHRvIGNsZWFyIGEgcG9zdGFsSW5mbyBpZiByZWdzaXRyYXIgd2FudHMgdG8gcmVtb3Zl
IGl0IC4NCg0KU28gIGZvciByZXF1ZXN0IDEsIG5vdGhpbmcgY2hhbmdlZCBmb3IgbGFja2luZyBu
ZWNlc3NhcnkgdmFsdWVzLCAgZm9yIHJlcXVlc3QgMiwgb25seSBvcmdhbml6YXRpb24gb2YgdHlw
ZSAnaW50JyB3aWxsIGJlIHVwZGF0ZWQuDQoNCg0KDQoNCg0KDQrpvZDotoUgdmlhIGZveG1haWwN
Cg0K5Y+R5Lu25Lq677yaIEtsYXVzIE1hbG9ybnkNCuWPkemAgeaXtumXtO+8miAyMDEz5bm0MTHm
nIgxNeaXpSjmmJ/mnJ/kupQpIOS4i+WNiDU6MDENCuaUtuS7tuS6uu+8miBIb2xsZW5iZWNrLCBT
Y290dDsgU2V0aCBHb2xkbWFuDQrmioTpgIHvvJogSUVURiBQcm92cmVnIE1haWxpbmcgTGlzdA0K
5Li76aKY77yaIFJlOiBbcHJvdnJlZ10gUkZDIDU3MzM6IHN0cmVldCBjaGFuZ2VzIHdpdGggY29u
dGFjdDp1cGRhdGUNCk9uIDE0LjExLjIwMTMgMTk6NDgsIEhvbGxlbmJlY2ssIFNjb3R0IHdyb3Rl
Og0KPiBJIGRvbuKAmXQga25vdyBob3cgb25lIGNhbiBtYWtlIGEgY2FzZSB0aGF0IHN1Yi1lbGVt
ZW50IHJlcGxhY2VtZW50IGlzIGFjY2VwdGFibGUuDQo+IFNlY3Rpb24gMy4yLjUgb2YgUkZDIDU3
MzMgc2F5cyB0aGlzIChlbXBoYXNpcyBtaW5lKToNCj4NCj4g4oCcVGhlIEVQUCA8dXBkYXRlPiBj
b21tYW5kIHByb3ZpZGVzIGEgdHJhbnNmb3JtIG9wZXJhdGlvbiB0aGF0IGFsbG93cyBhIGNsaWVu
dCB0bw0KPiBtb2RpZnkgdGhlIGF0dHJpYnV0ZXMgb2YgYSBjb250YWN0IF8vb2JqZWN0L18u4oCd
DQo+DQo+IGFuZCB0aGlzOg0KPg0KPiDigJxBbiBPUFRJT05BTCA8Y29udGFjdDpjaGc+IGVsZW1l
bnQgdGhhdCBjb250YWlucyBfL29iamVjdCBhdHRyaWJ1dGUgdmFsdWVzIHRvIGJlDQo+IGNoYW5n
ZWQvXy7igJ0NCj4NCj4gVGhlIDx1cGRhdGU+IGlzIHRodXMgZm9jdXNlZCBvbiBfL2NoYW5naW5n
L18gdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIF8vb2JqZWN0L18uDQo+IEluIHRoZSBleGFtcGxlIEts
YXVzIHByb3ZpZGVkLCB0aGUgY29tbWFuZCByZWNlaXZlZCBpcyDigJxyZXBsYWNlIHRoZSBleGlz
dGluZw0KPiA8Y29udGFjdDpwb3N0YWxJbmZvPiBhdHRyaWJ1dGUgd2l0aCBhIG5ldyBpbnN0YW5j
ZSBvZiA8Y29udGFjdDpwb3N0YWxJbmZvPuKAnS4gVGhlDQo+IHNlcnZlciBmYWlsZWQgdG8gcmVw
bGFjZSB0aGUgdHdvIDxzdHJlZXQ+IGVsZW1lbnRzIHdpdGggdGhlIHNpbmdsZSBlbGVtZW50DQo+
IHByb3ZpZGVkIGluIHRoZSA8dXBkYXRlPi4gSXQgc2hvdWxkbuKAmXQgd29yayB0aGF0IHdheS4N
Cj4NCj4gU2NvdHQNCj4NCg0KSGkgU2NvdCwgU2V0aCwNCg0KdXAgdG8gbm93IEkgcmVnYXJkZWQg
dGhlIG5hbWUsIHRoZSBvcmdhbml6YXRpb24gYW5kIHRoZSB0aGUgd2hvbGUgYWRkcmVzcyBibG9j
ayANCmFzIHRoZSByZXBsYWNhYmxlIHVuaXRzLCBkZXJpdmVkIGZyb20gdGhlIGFzc29jaWF0ZWQg
WE1MIHNjaGVtYS4gSXQgbmFtZWx5IA0KY29udGFpbnMgdHdvIGRhdGF0eXBlcywgInBvc3RhbElu
Zm9UeXBlIiBmb3IgdGhlIGNyZWF0ZSBjb21tYW5kIGFuZCANCiJjaGdQb3N0YWxJbmZvVHlwZSIg
Zm9yIHRoZSB1cGRhdGUgY29tbWFuZC4gVGhlIGZpcnN0IGNvbnRhaW5zIHRoZSA8bmFtZT4gYW5k
IA0KPGFkZHI+IGVsZW1lbnRzIGFzIG1hbmRhdG9yeSBlbGVtZW50cywgdGhlIGxhdHRlciBjb250
YWlucyB0aGVtIGFzIG9wdGlvbmFsIA0KZWxlbWVudHMuIElmIG9uZSB3b3VsZCBjb25zaWRlciB0
aGUgcG9zdGFsSW5mbyBpdHNlbGYgYXMgdGhlIHJlcGxhY2FibGUgdW5pdCwgaXQgDQp3b3VsZCBu
b3QgbWFrZSBzZW5zZSB0byBlbmZvcmNlIHRoZSBuYW1lIGFuZCBhZGRyZXNzIG9uIDxjcmVhdGU+
LCBidXQgd291bGQgDQphbGxvdyB0byByZW1vdmUgdGhlbSB3aXRoIGEgZm9sbG93aW5nIDx1cGRh
dGU+IHJlcXVlc3QuDQoNClNvIHNpbXBseSBhc2tlZDogV2hhdCBkb2VzIHRoZSBmb2xsb3dpbmcg
c2NoZW1hLXdpc2UgbGVnYWwgcmVxdWVzdCBkbz8NCg0KPGNvbnRhY3Q6dXBkYXRlIHhtbG5zOmNv
bnRhY3Q9InVybjppZXRmOnBhcmFtczp4bWw6bnM6Y29udGFjdC0xLjAiPg0KICAgPGNvbnRhY3Q6
aWQ+QzIwMTMxMTE0LTAxPC9jb250YWN0OmlkPg0KICAgPGNvbnRhY3Q6Y2hnPg0KICAgICA8Y29u
dGFjdDpwb3N0YWxJbmZvIHR5cGU9ImludCIvPg0KICAgPC9jb250YWN0OmNoZz4NCjwvY29udGFj
dDp1cGRhdGU+DQoNCkRvZXMgaXQgY2xlYXIgdGhlIGludGVybmF0aW9uYWwgY29udGFjdD8gRG9l
cyBpdCBsZWF2ZSB0aGUgaW50ZXJuYXRpb25hbCBwb3N0YWwgDQpkYXRhIHNpbXBseSB1bmNoYW5n
ZWQgKGFzaWRlIGZyb20gYmVpbmcgaWxsZWdhbCBpbiBTY290J3MgdmlldyB0byBzdWJtaXQgYSAN
CmNvbW1hbmQgdGhhdCBpcyBlZmZlY3RpdmVseSBub24tbW9kaWZ5aW5nKS4gRG9lcyB0aGUgZm9s
bG93aW5nIGNvbW1hbmQNCg0KPGNvbnRhY3Q6dXBkYXRlIHhtbG5zOmNvbnRhY3Q9InVybjppZXRm
OnBhcmFtczp4bWw6bnM6Y29udGFjdC0xLjAiPg0KICAgPGNvbnRhY3Q6aWQ+QzIwMTMxMTE0LTAx
PC9jb250YWN0OmlkPg0KICAgPGNvbnRhY3Q6Y2hnPg0KICAgICA8Y29udGFjdDpwb3N0YWxJbmZv
IHR5cGU9ImludCI+DQogICAgICAgPGNvbnRhY3Q6b3JnPkFDTUUgU29sdXRpb25zPC9jb250YWN0
Om9yZz4NCiAgICAgPC9jb250YWN0OnBvc3RhbEluZm8+DQogICA8L2NvbnRhY3Q6Y2hnPg0KPC9j
b250YWN0OnVwZGF0ZT4NCg0KbW9kaWZ5IHRoZSBwb3N0YWwgaW5mbyBzbyB0aGF0IGl0ICpzb2xl
bHkqIGNvbnRhaW5zIHRoZSBvcmdhbml6YXRpb24gYW5kIG5vdGhpbmcgDQplbHNlIGFmdGVyd2Fy
ZHM/DQoNClJlZ2FyZHMsDQoNCktsYXVzDQoNCg0KDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcm92cmVnIG1haWxpbmcgbGlz
dA0KcHJvdnJlZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9wcm92cmVn

------=_001_NextPart608215171534_=----
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF







Hello Klaus,


 


    In my opini=
on=20
,  <contact:rem> will be used to clear a postalInfo if regsitra=
r=20
wants to remove it .


 


So  for request 1, n=
othing=20
changed for lacking necessary values,  for=20
request 2, only organization of type 'int' will be updated.


 


 


 





=E9=BD=90=E8=B6=85=20
via foxmail


 




=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Klaus=20
Malorny


=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A 2013=E5=B9=
=B411=E6=9C=8815=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=94) =E4=B8=8B=E5=
=8D=885:01


=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Hollenbeck,=20
Scott; Seth Goldman


=E6=8A=84=E9=80=81=EF=BC=9A IETF Provreg Mailing=20
List


=E4=B8=BB=E9=A2=98=EF=BC=9A Re: [provreg] RFC 5733: stree=
t changes with=20
contact:update




On 14.11.2013 19:48, Hollenbeck, Scott wrote=
:


> I don=E2=80=99t know how one can&n=
bsp;make a case that sub-element replacement =
;is acceptable.


> Section 3.2.5 of RFC 5733 says&nbs=
p;this (emphasis mine):


>


> =E2=80=9CThe EPP <update> command =
;provides a transform operation that allows =
a client to


> modify the attributes of a contact=
 _/object/_.=E2=80=9D


>


> and this:


>


> =E2=80=9CAn OPTIONAL <contact:chg> ele=
ment that contains _/object attribute values =
;to be


> changed/_.=E2=80=9D


>


> The <update> is thus focused =
;on _/changing/_ the attributes of the _/obj=
ect/_.


> In the example Klaus provided, the=
 command received is =E2=80=9Creplace the ex=
isting


> <contact:postalInfo> attribute with a&=
nbsp;new instance of <contact:postalInfo>=E2=80=9D.&n=
bsp;The


> server failed to replace the two&n=
bsp;<street> elements with the single eleme=
nt


> provided in the <update>. It =
;shouldn=E2=80=99t work that way.


>


> Scott


>


 


Hi Scot, Seth,


 


up to now I regarded the name, the=
 organization and the the whole address =
;block 


as the replacable units, derived from t=
he associated XML schema. It namely 


contains two datatypes, "postalInfoType" for =
;the create command and 


"chgPostalInfoType" for the update command. =
The first contains the <name> and 

<addr> elements as mandatory elements, =
;the latter contains them as optional 


elements. If one would consider the pos=
talInfo itself as the replacable unit, it&nb=
sp;


would not make sense to enforce the&nbs=
p;name and address on <create>, but wo=
uld 


allow to remove them with a following&n=
bsp;<update> request.


 


So simply asked: What does the followin=
g schema-wise legal request do?


 


<contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:conta=
ct-1.0">


   <contact:id>C20131114-01</contact:id>

   <contact:chg>


     <contact:postalInfo type=3D"int=
"/>


   </contact:chg>


</contact:update>


 


Does it clear the international contact?&nbs=
p;Does it leave the international postal 

data simply unchanged (aside from being =
;illegal in Scot's view to submit a 

command that is effectively non-modifying). =
Does the following command


 


<contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:conta=
ct-1.0">


   <contact:id>C20131114-01</contact:id>

   <contact:chg>


     <contact:postalInfo type=3D"int=
">


       <contact:org>ACME&nbs=
p;Solutions</contact:org>


     </contact:postalInfo>


   </contact:chg>


</contact:update>


 


modify the postal info so that it =
*solely* contains the organization and nothing&nb=
sp;


else afterwards?


 


Regards,


 


Klaus


 


 


 


 


 


 


 


 


 


 


_______________________________________________


provreg mailing list


provreg@ietf.org


https://www.ietf.org/mailman/listinfo/provreg


------=_001_NextPart608215171534_=------


From shollenbeck@verisign.com  Fri Nov 15 03:47:07 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D4311E80EC for ; Fri, 15 Nov 2013 03:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO2N7Ls3aF6H for ; Fri, 15 Nov 2013 03:47:00 -0800 (PST)
Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id E025121F8FF8 for ; Fri, 15 Nov 2013 03:46:56 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUoYJsOCrrn2NplXzGWs5CMyMwNsWeIMR@postini.com; Fri, 15 Nov 2013 03:46:59 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rAFBktxP026592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 06:46:55 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 15 Nov 2013 06:46:55 -0500
From: "Hollenbeck, Scott" 
To: Klaus Malorny 
Thread-Topic: [provreg] RFC 5733: street changes with contact:update
Thread-Index: AQHO4eFE+i6MWHhfnUGX00QbNW5705omLARw
Date: Fri, 15 Nov 2013 11:46:54 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F492D5C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <5284EE10.5020809@knipp.de>   <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5285E2E8.7020304@knipp.de>
In-Reply-To: <5285E2E8.7020304@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: IETF Provreg Mailing List 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 11:47:07 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLbGF1cyBNYWxvcm55IFttYWls
dG86S2xhdXMuTWFsb3JueUBrbmlwcC5kZV0NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNSwg
MjAxMyA0OjAxIEFNDQo+IFRvOiBIb2xsZW5iZWNrLCBTY290dDsgU2V0aCBHb2xkbWFuDQo+IENj
OiBJRVRGIFByb3ZyZWcgTWFpbGluZyBMaXN0DQo+IFN1YmplY3Q6IFJlOiBbcHJvdnJlZ10gUkZD
IDU3MzM6IHN0cmVldCBjaGFuZ2VzIHdpdGggY29udGFjdDp1cGRhdGUNCj4gDQo+IE9uIDE0LjEx
LjIwMTMgMTk6NDgsIEhvbGxlbmJlY2ssIFNjb3R0IHdyb3RlOg0KPiA+IEkgZG9u4oCZdCBrbm93
IGhvdyBvbmUgY2FuIG1ha2UgYSBjYXNlIHRoYXQgc3ViLWVsZW1lbnQgcmVwbGFjZW1lbnQgaXMN
Cj4gYWNjZXB0YWJsZS4NCj4gPiBTZWN0aW9uIDMuMi41IG9mIFJGQyA1NzMzIHNheXMgdGhpcyAo
ZW1waGFzaXMgbWluZSk6DQo+ID4NCj4gPiDigJxUaGUgRVBQIDx1cGRhdGU+IGNvbW1hbmQgcHJv
dmlkZXMgYSB0cmFuc2Zvcm0gb3BlcmF0aW9uIHRoYXQgYWxsb3dzDQo+IGEgY2xpZW50IHRvDQo+
ID4gbW9kaWZ5IHRoZSBhdHRyaWJ1dGVzIG9mIGEgY29udGFjdCBfL29iamVjdC9fLuKAnQ0KPiA+
DQo+ID4gYW5kIHRoaXM6DQo+ID4NCj4gPiDigJxBbiBPUFRJT05BTCA8Y29udGFjdDpjaGc+IGVs
ZW1lbnQgdGhhdCBjb250YWlucyBfL29iamVjdCBhdHRyaWJ1dGUNCj4gdmFsdWVzIHRvIGJlDQo+
ID4gY2hhbmdlZC9fLuKAnQ0KPiA+DQo+ID4gVGhlIDx1cGRhdGU+IGlzIHRodXMgZm9jdXNlZCBv
biBfL2NoYW5naW5nL18gdGhlIGF0dHJpYnV0ZXMgb2YgdGhlDQo+IF8vb2JqZWN0L18uDQo+ID4g
SW4gdGhlIGV4YW1wbGUgS2xhdXMgcHJvdmlkZWQsIHRoZSBjb21tYW5kIHJlY2VpdmVkIGlzIOKA
nHJlcGxhY2UgdGhlDQo+IGV4aXN0aW5nDQo+ID4gPGNvbnRhY3Q6cG9zdGFsSW5mbz4gYXR0cmli
dXRlIHdpdGggYSBuZXcgaW5zdGFuY2Ugb2YNCj4gPGNvbnRhY3Q6cG9zdGFsSW5mbz7igJ0uIFRo
ZQ0KPiA+IHNlcnZlciBmYWlsZWQgdG8gcmVwbGFjZSB0aGUgdHdvIDxzdHJlZXQ+IGVsZW1lbnRz
IHdpdGggdGhlIHNpbmdsZQ0KPiBlbGVtZW50DQo+ID4gcHJvdmlkZWQgaW4gdGhlIDx1cGRhdGU+
LiBJdCBzaG91bGRu4oCZdCB3b3JrIHRoYXQgd2F5Lg0KPiA+DQo+ID4gU2NvdHQNCj4gPg0KPiAN
Cj4gSGkgU2NvdCwgU2V0aCwNCj4gDQo+IHVwIHRvIG5vdyBJIHJlZ2FyZGVkIHRoZSBuYW1lLCB0
aGUgb3JnYW5pemF0aW9uIGFuZCB0aGUgdGhlIHdob2xlDQo+IGFkZHJlc3MgYmxvY2sNCj4gYXMg
dGhlIHJlcGxhY2FibGUgdW5pdHMsIGRlcml2ZWQgZnJvbSB0aGUgYXNzb2NpYXRlZCBYTUwgc2No
ZW1hLiBJdA0KPiBuYW1lbHkNCj4gY29udGFpbnMgdHdvIGRhdGF0eXBlcywgInBvc3RhbEluZm9U
eXBlIiBmb3IgdGhlIGNyZWF0ZSBjb21tYW5kIGFuZA0KPiAiY2hnUG9zdGFsSW5mb1R5cGUiIGZv
ciB0aGUgdXBkYXRlIGNvbW1hbmQuIFRoZSBmaXJzdCBjb250YWlucyB0aGUNCj4gPG5hbWU+IGFu
ZA0KPiA8YWRkcj4gZWxlbWVudHMgYXMgbWFuZGF0b3J5IGVsZW1lbnRzLCB0aGUgbGF0dGVyIGNv
bnRhaW5zIHRoZW0gYXMNCj4gb3B0aW9uYWwNCj4gZWxlbWVudHMuIElmIG9uZSB3b3VsZCBjb25z
aWRlciB0aGUgcG9zdGFsSW5mbyBpdHNlbGYgYXMgdGhlIHJlcGxhY2FibGUNCj4gdW5pdCwgaXQN
Cj4gd291bGQgbm90IG1ha2Ugc2Vuc2UgdG8gZW5mb3JjZSB0aGUgbmFtZSBhbmQgYWRkcmVzcyBv
biA8Y3JlYXRlPiwgYnV0DQo+IHdvdWxkDQo+IGFsbG93IHRvIHJlbW92ZSB0aGVtIHdpdGggYSBm
b2xsb3dpbmcgPHVwZGF0ZT4gcmVxdWVzdC4NCj4gDQo+IFNvIHNpbXBseSBhc2tlZDogV2hhdCBk
b2VzIHRoZSBmb2xsb3dpbmcgc2NoZW1hLXdpc2UgbGVnYWwgcmVxdWVzdCBkbz8NCj4gDQo+IDxj
b250YWN0OnVwZGF0ZSB4bWxuczpjb250YWN0PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmNvbnRh
Y3QtMS4wIj4NCj4gICAgPGNvbnRhY3Q6aWQ+QzIwMTMxMTE0LTAxPC9jb250YWN0OmlkPg0KPiAg
ICA8Y29udGFjdDpjaGc+DQo+ICAgICAgPGNvbnRhY3Q6cG9zdGFsSW5mbyB0eXBlPSJpbnQiLz4N
Cj4gICAgPC9jb250YWN0OmNoZz4NCj4gPC9jb250YWN0OnVwZGF0ZT4NCj4gDQo+IERvZXMgaXQg
Y2xlYXIgdGhlIGludGVybmF0aW9uYWwgY29udGFjdD8gRG9lcyBpdCBsZWF2ZSB0aGUNCj4gaW50
ZXJuYXRpb25hbCBwb3N0YWwNCj4gZGF0YSBzaW1wbHkgdW5jaGFuZ2VkIChhc2lkZSBmcm9tIGJl
aW5nIGlsbGVnYWwgaW4gU2NvdCdzIHZpZXcgdG8NCj4gc3VibWl0IGENCj4gY29tbWFuZCB0aGF0
IGlzIGVmZmVjdGl2ZWx5IG5vbi1tb2RpZnlpbmcpLiBEb2VzIHRoZSBmb2xsb3dpbmcgY29tbWFu
ZA0KDQpHbyBiYWNrIHRvIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheSB5ZXN0ZXJkYXk6IDxjaGc+
IG1lYW5zICJyZXBsYWNlIGV4aXN0aW5nIHdpdGggbmV3Ii4gU28geWVzLCBpdCB3b3VsZCBjaGFu
Z2UgdGhlIGludGVybmF0aW9uYWwgcG9zdGFsIGluZm8gdG8gImVtcHR5Ii4NCg0KPiA8Y29udGFj
dDp1cGRhdGUgeG1sbnM6Y29udGFjdD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpjb250YWN0LTEu
MCI+DQo+ICAgIDxjb250YWN0OmlkPkMyMDEzMTExNC0wMTwvY29udGFjdDppZD4NCj4gICAgPGNv
bnRhY3Q6Y2hnPg0KPiAgICAgIDxjb250YWN0OnBvc3RhbEluZm8gdHlwZT0iaW50Ij4NCj4gICAg
ICAgIDxjb250YWN0Om9yZz5BQ01FIFNvbHV0aW9uczwvY29udGFjdDpvcmc+DQo+ICAgICAgPC9j
b250YWN0OnBvc3RhbEluZm8+DQo+ICAgIDwvY29udGFjdDpjaGc+DQo+IDwvY29udGFjdDp1cGRh
dGU+DQo+IA0KPiBtb2RpZnkgdGhlIHBvc3RhbCBpbmZvIHNvIHRoYXQgaXQgKnNvbGVseSogY29u
dGFpbnMgdGhlIG9yZ2FuaXphdGlvbg0KPiBhbmQgbm90aGluZw0KPiBlbHNlIGFmdGVyd2FyZHM/
DQoNCkFzc3VtaW5nIGFsbCBvdGhlciBzY2hlbWEgcmVxdWlyZW1lbnRzIGFyZSBtZXQsIHllcy4N
Cg0KU2NvdHQNCg==

From sethamin@google.com  Fri Nov 15 04:19:57 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C110611E81A0 for ; Fri, 15 Nov 2013 04:19:57 -0800 (PST)
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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmYbIWA6CYDR for ; Fri, 15 Nov 2013 04:19:57 -0800 (PST)
Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DCE7F11E814C for ; Fri, 15 Nov 2013 04:19:56 -0800 (PST)
Received: by mail-vb0-f45.google.com with SMTP id x13so312122vbb.4 for ; Fri, 15 Nov 2013 04:19:56 -0800 (PST)
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=oRLVWDZpz3O14vX/rrooPuOxsdBVlQ0JsNTPTBtB6lk=; b=LqJ/pZUP2L1NUe0TCtB13o2eWuM4cc2i0IVWAqTlP4fPDhr0FoYbW541hW+b3ghrTk gIdaXxw91NK6P1qsE8OwMl1LtKpKlCohLAsIMSLYIUh6DRaeUsw9T2ud/aBlgvozPMUj XB8i1mcbLoGHAH8Oeur6X/q3LmT958P0oQubH0DE4xjw7cBnALZN5dBKFLjgwnhiZSvd ULQ6V8+CP02MABSCGq4Mwtt2DPx3THZFF2tMdbolKibf+shMJGs13hBhkpkMeh5XJs4A WFg9aOEJt5xRhebqSUoPkPogPLTLfV4szmoW4EH2Pxheo2cVXvAu6tO/ZQUwaZH9HHSN jxIg==
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=oRLVWDZpz3O14vX/rrooPuOxsdBVlQ0JsNTPTBtB6lk=; b=iHrkIFmus4UFR4uXr/3QuKSVcdP8oOUwHG4FqPOhsg0HdrOL60TrFBuV1GyZmYTafu d/Mu0YwqPpmQauQi54PIQUTcPDDDsFkJWhv+73+tqp2sXAr9rWbdfl6CFStnN7jse+pm MFnBiygX1muXHq3ENUDdpWN1apsJXr272ZlGiGxMS4UoZ+bdx7+DR5LORmTF3wkhnnwm 4PWJQo1O3YGyza2giRPejJb3ksnFOqR6L/0upo2FtFpap0wsT8DTCfu5gBTYayPN7pXd 5uJgR5lIBOd1T16kSYIQofR73wIUnvSip6jpE8McsaP/Z3Nz0RDsuqME9Z8A3bezFqIB hWBg==
X-Gm-Message-State: ALoCoQnSrm6RTRjX7MYQrY+WkL7WoMaY75FKw7RTHC35npxYS+aUbyZ10PWSoPu7NaP/i0Om9S8BMDeq9Tstme20HR4KAIbKTRQrEt6Jfy0pDVvJPeQrpa5rH7LUHAdLPp39HMseMSB+MdLPCJoJj70e6j9fsM7Q5J2QtTsYd6TKXX1tRJdux241geJ+86k0y+TngEd9Zo8c
MIME-Version: 1.0
X-Received: by 10.52.182.39 with SMTP id eb7mr3485033vdc.6.1384517996200; Fri, 15 Nov 2013 04:19:56 -0800 (PST)
Received: by 10.52.111.230 with HTTP; Fri, 15 Nov 2013 04:19:56 -0800 (PST)
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492D5C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <5284EE10.5020809@knipp.de>   <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5285E2E8.7020304@knipp.de> <831693C2CDA2E849A7D7A712B24E257F492D5C6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Date: Fri, 15 Nov 2013 07:19:56 -0500
Message-ID: 
From: Seth Goldman 
To: "Hollenbeck, Scott" 
Content-Type: multipart/alternative; boundary=bcaec547ca8d596b0004eb3637c9
Cc: IETF Provreg Mailing List 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 12:19:57 -0000

--bcaec547ca8d596b0004eb3637c9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Scott  wrote:

> > -----Original Message-----
> > From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
> > Sent: Friday, November 15, 2013 4:01 AM
> > To: Hollenbeck, Scott; Seth Goldman
> > Cc: IETF Provreg Mailing List
> > Subject: Re: [provreg] RFC 5733: street changes with contact:update
> >
> > On 14.11.2013 19:48, Hollenbeck, Scott wrote:
> > > I don=92t know how one can make a case that sub-element replacement i=
s
> > acceptable.
> > > Section 3.2.5 of RFC 5733 says this (emphasis mine):
> > >
> > > =93The EPP  command provides a transform operation that allow=
s
> > a client to
> > > modify the attributes of a contact _/object/_.=94
> > >
> > > and this:
> > >
> > > =93An OPTIONAL  element that contains _/object attribute
> > values to be
> > > changed/_.=94
> > >
> > > The  is thus focused on _/changing/_ the attributes of the
> > _/object/_.
> > > In the example Klaus provided, the command received is =93replace the
> > existing
> > >  attribute with a new instance of
> > =94. The
> > > server failed to replace the two  elements with the single
> > element
> > > provided in the . It shouldn=92t work that way.
> > >
> > > Scott
> > >
> >
> > Hi Scot, Seth,
> >
> > up to now I regarded the name, the organization and the the whole
> > address block
> > as the replacable units, derived from the associated XML schema. It
> > namely
> > contains two datatypes, "postalInfoType" for the create command and
> > "chgPostalInfoType" for the update command. The first contains the
> >  and
> >  elements as mandatory elements, the latter contains them as
> > optional
> > elements. If one would consider the postalInfo itself as the replacable
> > unit, it
> > would not make sense to enforce the name and address on , but
> > would
> > allow to remove them with a following  request.
> >
> > So simply asked: What does the following schema-wise legal request do?
> >
> > 
> >    C20131114-01
> >    
> >      
> >    
> > 
> >
> > Does it clear the international contact? Does it leave the
> > international postal
> > data simply unchanged (aside from being illegal in Scot's view to
> > submit a
> > command that is effectively non-modifying). Does the following command
>
> Go back to what I was trying to say yesterday:  means "replace
> existing with new". So yes, it would change the international postal info
> to "empty".
>
> > 
> >    C20131114-01
> >    
> >      
> >        ACME Solutions
> >      
> >    
> > 
> >
> > modify the postal info so that it *solely* contains the organization
> > and nothing
> > else afterwards?
>
> Assuming all other schema requirements are met, yes.
>

I believe Klaus's point is that under this interpretation, the schema
allows you to update a postalInfo to a version that would not be allowed in
a create.

I still think your interpretation of the replace semantics is correct. But
the schema is inconsistent, so it's understandable to interpret it
otherwise.


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

--bcaec547ca8d596b0004eb3637c9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable





On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Scott <shollen=
beck@verisign.com> wrote:


> -----Original Message=
-----

> From: Klaus Malorny [mailto:=
Klaus.Malorny@knipp.de]

> Sent: Friday, November 15, 2013 4:01 AM

> To: Hollenbeck, Scott; Seth Goldman

> Cc: IETF Provreg Mailing List

> Subject: Re: [provreg] RFC 5733: street changes with contact:update
>


> On 14.11.2013 19:48, Hollenbeck, Scott wr=
ote:

> > I don=92t know how one can make a case that sub-element replaceme=
nt is

> acceptable.

> > Section 3.2.5 of RFC 5733 says this (emphasis mine):

> >

> > =93The EPP <update> command provides a transform operation =
that allows

> a client to

> > modify the attributes of a contact _/object/_.=94

> >

> > and this:

> >

> > =93An OPTIONAL <contact:chg> element that contains _/object=
 attribute

> values to be

> > changed/_.=94

> >

> > The <update> is thus focused on _/changing/_ the attributes=
 of the

> _/object/_.

> > In the example Klaus provided, the command received is =93replace=
 the

> existing

> > <contact:postalInfo> attribute with a new instance of

> <contact:postalInfo>=94. The

> > server failed to replace the two <street> elements with the=
 single

> element

> > provided in the <update>. It shouldn=92t work that way.

> >

> > Scott

> >

>

> Hi Scot, Seth,

>

> up to now I regarded the name, the organization and the the whole

> address block

> as the replacable units, derived from the associated XML schema. It
> namely

> contains two datatypes, "postalInfoType" for the create comm=
and and

> "chgPostalInfoType" for the update command. The first contai=
ns the

> <name> and

> <addr> elements as mandatory elements, the latter contains them =
as

> optional

> elements. If one would consider the postalInfo itself as the replacabl=
e

> unit, it

> would not make sense to enforce the name and address on <create>=
, but

> would

> allow to remove them with a following <update> request.

>

> So simply asked: What does the following schema-wise legal request do?=


>

> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac=
t-1.0">

> =A0 =A0<contact:id>C20131114-01</contact:id>

> =A0 =A0<contact:chg>

> =A0 =A0 =A0<contact:postalInfo type=3D"int"/>

> =A0 =A0</contact:chg>

> </contact:update>

>

> Does it clear the international contact? Does it leave the

> international postal

> data simply unchanged (aside from being illegal in Scot's view to<=
br>
> submit a

> command that is effectively non-modifying). Does the following command=





Go back to what I was trying to say yesterday: <chg> mean=
s "replace existing with new". So yes, it would change the intern=
ational postal info to "empty".




> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac=
t-1.0">

> =A0 =A0<contact:id>C20131114-01</contact:id>

> =A0 =A0<contact:chg>

> =A0 =A0 =A0<contact:postalInfo type=3D"int">

> =A0 =A0 =A0 =A0<contact:org>ACME Solutions</contact:org>
> =A0 =A0 =A0</contact:postalInfo>

> =A0 =A0</contact:chg>

> </contact:update>

>

> modify the postal info so that it *solely* contains the organization
> and nothing

> else afterwards?




Assuming all other schema requirements are met, yes.
=


I believe Klaus's point is that under this interpre=
tation, the schema allows you to update a postalInfo to a version that woul=
d not be allowed in a create.



I still think your interpretation of the replace semant=
ics is correct. But the schema is inconsistent, so it's understandable =
to interpret it otherwise.
=A0


Scott


_____________________=
__________________________

provreg mailing list

provreg@ietf.org

https://www.ietf.org/mailman/listinfo/provreg





--bcaec547ca8d596b0004eb3637c9--

From james.mitchell@ausregistry.com.au  Fri Nov 15 04:43:42 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E731911E8116 for ; Fri, 15 Nov 2013 04:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YV8lQpgHV7Z for ; Fri, 15 Nov 2013 04:43:38 -0800 (PST)
Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [120.29.249.162]) by ietfa.amsl.com (Postfix) with ESMTP id 99F8E11E814C for ; Fri, 15 Nov 2013 04:43:37 -0800 (PST)
Received: from unknown (HELO ausregistry.com.au) ([10.30.220.61]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 15 Nov 2013 23:42:34 +1100
Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.94]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 23:43:40 +1100
From: James Mitchell 
To: Seth Goldman , "Hollenbeck, Scott" 
Thread-Topic: [provreg] RFC 5733: street changes with contact:update
Thread-Index: AQHO4U+kCRAWMhz6P0OOYskO96Wl9pokOycAgAAF/QCAABgkAIAA7jsAgAAuOQCAAAk7AIAAvvuA
Date: Fri, 15 Nov 2013 12:43:38 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-NZ, en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [180.181.200.123]
Content-Type: multipart/alternative; boundary="_000_CEAC5D2B1462Bjamesmitchellausregistrycomau_"
MIME-Version: 1.0
Cc: IETF Provreg Mailing List 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 12:43:43 -0000

--_000_CEAC5D2B1462Bjamesmitchellausregistrycomau_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Seth et al,

The info response would be invalid for contacts having a  with =
only an . IMO the correct interpretation is that the command changes/m=
odifies only the elements specified, however I=92m not sure how one would i=
nterpret A lane=
 - replace the =93first=94 street element or all street =
elements?

FYI, for backwards compatibility our implementation performs a remove/repla=
ce for the direct children of the  element only. The following example=
s hopefully illustrate the behaviour.

 -> remove the localised postal info
ACME -> fail, mi=
ssing required values
ACMEMelbourne=
AU -> success, previous int postal info r=
eplaced

Regards,
James Mitchell
Software Product Manager / ARI Registry Services

From: Seth Goldman >
Date: Friday, 15 November 2013 11:19 pm
To: "Hollenbeck, Scott" >
Cc: IETF Provreg Mailing List >
Subject: Re: [provreg] RFC 5733: street changes with contact:update




On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Scott > wrote:
> -----Original Message-----
> From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
> Sent: Friday, November 15, 2013 4:01 AM
> To: Hollenbeck, Scott; Seth Goldman
> Cc: IETF Provreg Mailing List
> Subject: Re: [provreg] RFC 5733: street changes with contact:update
>
> On 14.11.2013 19:48, Hollenbeck, Scott wrote:
> > I don=92t know how one can make a case that sub-element replacement is
> acceptable.
> > Section 3.2.5 of RFC 5733 says this (emphasis mine):
> >
> > =93The EPP  command provides a transform operation that allows
> a client to
> > modify the attributes of a contact _/object/_.=94
> >
> > and this:
> >
> > =93An OPTIONAL  element that contains _/object attribute
> values to be
> > changed/_.=94
> >
> > The  is thus focused on _/changing/_ the attributes of the
> _/object/_.
> > In the example Klaus provided, the command received is =93replace the
> existing
> >  attribute with a new instance of
> =94. The
> > server failed to replace the two  elements with the single
> element
> > provided in the . It shouldn=92t work that way.
> >
> > Scott
> >
>
> Hi Scot, Seth,
>
> up to now I regarded the name, the organization and the the whole
> address block
> as the replacable units, derived from the associated XML schema. It
> namely
> contains two datatypes, "postalInfoType" for the create command and
> "chgPostalInfoType" for the update command. The first contains the
>  and
>  elements as mandatory elements, the latter contains them as
> optional
> elements. If one would consider the postalInfo itself as the replacable
> unit, it
> would not make sense to enforce the name and address on , but
> would
> allow to remove them with a following  request.
>
> So simply asked: What does the following schema-wise legal request do?
>
> 
>    C20131114-01
>    
>      
>    
> 
>
> Does it clear the international contact? Does it leave the
> international postal
> data simply unchanged (aside from being illegal in Scot's view to
> submit a
> command that is effectively non-modifying). Does the following command

Go back to what I was trying to say yesterday:  means "replace existin=
g with new". So yes, it would change the international postal info to "empt=
y".

> 
>    C20131114-01
>    
>      
>        ACME Solutions
>      
>    
> 
>
> modify the postal info so that it *solely* contains the organization
> and nothing
> else afterwards?

Assuming all other schema requirements are met, yes.

I believe Klaus's point is that under this interpretation, the schema allow=
s you to update a postalInfo to a version that would not be allowed in a cr=
eate.

I still think your interpretation of the replace semantics is correct. But =
the schema is inconsistent, so it's understandable to interpret it otherwis=
e.


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


--_000_CEAC5D2B1462Bjamesmitchellausregistrycomau_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Seth et al,







The info response would be invalid for contacts having a <postalInf=
o> with only an <org>. IMO the correct interpretation is that the =
command changes/modifies only the elements specified, however I=92m not sur=
e how one would interpret <chg><postalInfo type=3D"int"&=
gt;<addr><street>A
 lane</street></addr></postalInfo></chg> - replace =
the =93first=94 street element or all street elements?







FYI, for backwards compatibility our implementation performs a remove/=
replace for the direct children of the <chg> element only. The follow=
ing examples hopefully illustrate the behaviour.







<chg><postalInfo type=3D"loc"/><chg> ->=
 remove the localised postal info


<chg><postalInfo type=3D"int"><org>ACME<=
;/org></postalInfo><chg> -> fail, missing required values=



<chg><postalInfo type=3D"int"><name>ACME&l=
t;/name><addr><city>Melbourne</city><cc>AU</c=
c></addr></postalInfo><chg> -> success, previous in=
t postal info replaced







Regards,


James Mitchell


Software Product Manager / ARI Registry Services









From: Seth Goldman <sethamin@google.com>

Date: Friday, 15 November 2013 11:1=
9 pm

To: "Hollenbeck, Scott" &=
lt;shollenbeck@verisign.com=
>

Cc: IETF Provreg Mailing List <<=
a href=3D"mailto:provreg@ietf.org">provreg@ietf.org>

Subject: Re: [provreg] RFC 5733: st=
reet changes with contact:update





















On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Sco=
tt 
<shollenbe=
ck@verisign.com> wrote:




> -----Original Message-----

> From: Klaus Malorny [mailto:=
Klaus.Malorny@knipp.de]

> Sent: Friday, November 15, 2013 4:01 AM

> To: Hollenbeck, Scott; Seth Goldman

> Cc: IETF Provreg Mailing List

> Subject: Re: [provreg] RFC 5733: street changes with contact:update
>






> On 14.11.2013 19:48, Hollenbeck, Scott wrote:

> > I don=92t know how one can make a case that sub-element replaceme=
nt is

> acceptable.

> > Section 3.2.5 of RFC 5733 says this (emphasis mine):

> >

> > =93The EPP <update> command provides a transform operation =
that allows

> a client to

> > modify the attributes of a contact _/object/_.=94

> >

> > and this:

> >

> > =93An OPTIONAL <contact:chg> element that contains _/object=
 attribute

> values to be

> > changed/_.=94

> >

> > The <update> is thus focused on _/changing/_ the attributes=
 of the

> _/object/_.

> > In the example Klaus provided, the command received is =93replace=
 the

> existing

> > <contact:postalInfo> attribute with a new instance of

> <contact:postalInfo>=94. The

> > server failed to replace the two <street> elements with the=
 single

> element

> > provided in the <update>. It shouldn=92t work that way.

> >

> > Scott

> >

>

> Hi Scot, Seth,

>

> up to now I regarded the name, the organization and the the whole

> address block

> as the replacable units, derived from the associated XML schema. It
> namely

> contains two datatypes, "postalInfoType" for the create comm=
and and

> "chgPostalInfoType" for the update command. The first contai=
ns the

> <name> and

> <addr> elements as mandatory elements, the latter contains them =
as

> optional

> elements. If one would consider the postalInfo itself as the replacabl=
e

> unit, it

> would not make sense to enforce the name and address on <create>=
, but

> would

> allow to remove them with a following <update> request.

>

> So simply asked: What does the following schema-wise legal request do?=


>

> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac=
t-1.0">

>    <contact:id>C20131114-01</contact:id>

>    <contact:chg>

>      <contact:postalInfo type=3D"int"/>=


>    </contact:chg>

> </contact:update>

>

> Does it clear the international contact? Does it leave the

> international postal

> data simply unchanged (aside from being illegal in Scot's view to

> submit a

> command that is effectively non-modifying). Does the following command=








Go back to what I was trying to say yesterday: <chg> means "repl=
ace existing with new". So yes, it would change the international post=
al info to "empty".




> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac=
t-1.0">

>    <contact:id>C20131114-01</contact:id>

>    <contact:chg>

>      <contact:postalInfo type=3D"int"><=
br>
>        <contact:org>ACME Solutions</conta=
ct:org>

>      </contact:postalInfo>

>    </contact:chg>

> </contact:update>

>

> modify the postal info so that it *solely* contains the organization
> and nothing

> else afterwards?





Assuming all other schema requirements are met, yes.









I believe Klaus's point is that under this interpretation, the schema =
allows you to update a postalInfo to a version that would not be allowed in=
 a create.







I still think your interpretation of the replace semantics is correct.=
 But the schema is inconsistent, so it's understandable to interpret it oth=
erwise.


 





Scott





_______________________________________________

provreg mailing list

provreg@ietf.org

https://www.ietf.org/mailman/listinfo/provreg























--_000_CEAC5D2B1462Bjamesmitchellausregistrycomau_--

From JGould@verisign.com  Fri Nov 15 06:04:23 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A7E11E81B8 for ; Fri, 15 Nov 2013 06:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.598
X-Spam-Level: 
X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8lf5lTmKLRi for ; Fri, 15 Nov 2013 06:04:18 -0800 (PST)
Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id E004D11E81B7 for ; Fri, 15 Nov 2013 06:04:13 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUoYp3WWUPuTqqiEzZiBc6/tesK5uLjxY@postini.com; Fri, 15 Nov 2013 06:04:18 PST
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAFE4Crl030823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 09:04:12 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 15 Nov 2013 09:04:11 -0500
From: "Gould, James" 
To: "james.mitchell@ausregistry.com.au" , Seth Goldman , "Hollenbeck, Scott" 
Thread-Topic: [provreg] RFC 5733: street changes with contact:update
Thread-Index: AQHO4U+h+i6MWHhfnUGX00QbNW5705olR18AgAAF/QCAABgkAIAA7jwAgAAuOACAAAk7AIAABp8A///CqAA=
Date: Fri, 15 Nov 2013 14:04:11 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_CEAB90ED51E41jgouldverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: IETF Provreg Mailing List 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 14:04:23 -0000

--_004_CEAB90ED51E41jgouldverisigncom_
Content-Type: multipart/alternative;
	boundary="_000_CEAB90ED51E41jgouldverisigncom_"

--_000_CEAB90ED51E41jgouldverisigncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I agree that it changes/modifies the elements specified, where I view the e=
lements as being the direct child elements of , which include:

  1.   with type attribute as being relevant
     *   For example, if a contact had both types of postalInfo, inclusion =
of only one of the types ("int" or "loc") under the  does not =
implicitly remove the other type.
     *   All sub-elements of the  with type would be re=
placed including the two streets to one street example.
  2.   to replace the voice
  3.   to replace the fax
  4.   to replace the email
  5.   to replace the authorization information
  6.   to replace the disclosure.

The questions are focused on  since it's a complex enti=
ty with one to two instances ("int" or "loc").  I view the concept of chang=
e as being a replace of the instance whether it's a complex or simple insta=
nce.

--

JG

[cid:1A04AEB8-F54A-435E-8231-E78362210DD9]

James Gould
Principal Software Engineer
jgould@verisign.com

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: James Mitchell >
Date: Friday, November 15, 2013 7:43 AM
To: Seth Goldman >, "Hollen=
beck, Scott" >
Cc: EPP Provreg >
Subject: Re: [provreg] RFC 5733: street changes with contact:update

Seth et al,

The info response would be invalid for contacts having a  with =
only an . IMO the correct interpretation is that the command changes/m=
odifies only the elements specified, however I=92m not sure how one would i=
nterpret A lane=
 - replace the =93first=94 street element or all street =
elements?

FYI, for backwards compatibility our implementation performs a remove/repla=
ce for the direct children of the  element only. The following example=
s hopefully illustrate the behaviour.

 -> remove the localised postal info
ACME -> fail, mi=
ssing required values
ACMEMelbourne=
AU -> success, previous int postal info r=
eplaced

Regards,
James Mitchell
Software Product Manager / ARI Registry Services

From: Seth Goldman >
Date: Friday, 15 November 2013 11:19 pm
To: "Hollenbeck, Scott" >
Cc: IETF Provreg Mailing List >
Subject: Re: [provreg] RFC 5733: street changes with contact:update




On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Scott > wrote:
> -----Original Message-----
> From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de]
> Sent: Friday, November 15, 2013 4:01 AM
> To: Hollenbeck, Scott; Seth Goldman
> Cc: IETF Provreg Mailing List
> Subject: Re: [provreg] RFC 5733: street changes with contact:update
>
> On 14.11.2013 19:48, Hollenbeck, Scott wrote:
> > I don=92t know how one can make a case that sub-element replacement is
> acceptable.
> > Section 3.2.5 of RFC 5733 says this (emphasis mine):
> >
> > =93The EPP  command provides a transform operation that allows
> a client to
> > modify the attributes of a contact _/object/_.=94
> >
> > and this:
> >
> > =93An OPTIONAL  element that contains _/object attribute
> values to be
> > changed/_.=94
> >
> > The  is thus focused on _/changing/_ the attributes of the
> _/object/_.
> > In the example Klaus provided, the command received is =93replace the
> existing
> >  attribute with a new instance of
> =94. The
> > server failed to replace the two  elements with the single
> element
> > provided in the . It shouldn=92t work that way.
> >
> > Scott
> >
>
> Hi Scot, Seth,
>
> up to now I regarded the name, the organization and the the whole
> address block
> as the replacable units, derived from the associated XML schema. It
> namely
> contains two datatypes, "postalInfoType" for the create command and
> "chgPostalInfoType" for the update command. The first contains the
>  and
>  elements as mandatory elements, the latter contains them as
> optional
> elements. If one would consider the postalInfo itself as the replacable
> unit, it
> would not make sense to enforce the name and address on , but
> would
> allow to remove them with a following  request.
>
> So simply asked: What does the following schema-wise legal request do?
>
> 
>    C20131114-01
>    
>      
>    
> 
>
> Does it clear the international contact? Does it leave the
> international postal
> data simply unchanged (aside from being illegal in Scot's view to
> submit a
> command that is effectively non-modifying). Does the following command

Go back to what I was trying to say yesterday:  means "replace existin=
g with new". So yes, it would change the international postal info to "empt=
y".

> 
>    C20131114-01
>    
>      
>        ACME Solutions
>      
>    
> 
>
> modify the postal info so that it *solely* contains the organization
> and nothing
> else afterwards?

Assuming all other schema requirements are met, yes.

I believe Klaus's point is that under this interpretation, the schema allow=
s you to update a postalInfo to a version that would not be allowed in a cr=
eate.

I still think your interpretation of the replace semantics is correct. But =
the schema is inconsistent, so it's understandable to interpret it otherwis=
e.


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


--_000_CEAB90ED51E41jgouldverisigncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8D4419C7D37AED48B3385A16B7A6140E@verisign.com>
Content-Transfer-Encoding: quoted-printable









I agree that it changes/modifies the elements specified, where I view =
the elements as being the direct child elements of <contact:chg>, whi=
ch include:


    

  1. <contact:postalInfo> with type attribute as being relevant 

      

    1. For example, if a contact had both types of postalInfo, inclusion of on=
ly one of the types ("int" or "loc") under the <cont=
act:chg> does not implicitly remove the other type.  
    2. All s=
ub-elements of the <contact:postalInfo> with type would be replaced i=
ncluding the two streets to one street example.  
    

  2. <contact:voice> to replace the voice 
  3. <conta=
ct:fax> to replace the fax
  4. <contact:email> to replace the =
email
  5. <contact:authInfo> to replace the authorization informa=
tion
  6. <contact:disclose> to replace the disclosure.


The questions are focused on <contact:postalInfo> since it's a c=
omplex entity with one to two instances ("int" or "loc"=
).  I view the concept of change as being a replace of the instance wh=
ether it's a complex or simple instance.  










-- 



 



JG



 







 



=
James Gould



=
Principal Software Engineer



j=
gould@verisign.com



=
 



=
703-948-3271 (Office)



=
12061 Bluemont Way



=
Reston, VA 20190



=
VerisignInc.com













From: James Mitchell <james.mitchell@ausregistry.com.a=
u>

Date: Friday, November 15, 2013 7:4=
3 AM

To: Seth Goldman <sethamin@google.com>, "Hollenbeck, Sco=
tt" <shollenbeck@verisi=
gn.com>

Cc: EPP Provreg <provreg@ietf.org>

Subject: Re: [provreg] RFC 5733: st=
reet changes with contact:update















Seth et al,







The info response would be invalid for contacts having a <postalInf=
o> with only an <org>. IMO the correct interpretation is that the =
command changes/modifies only the elements specified, however I=92m not sur=
e how one would interpret <chg><postalInfo type=3D"int"&=
gt;<addr><street>A
 lane</street></addr></postalInfo></chg> - replace =
the =93first=94 street element or all street elements?







FYI, for backwards compatibility our implementation performs a remove/=
replace for the direct children of the <chg> element only. The follow=
ing examples hopefully illustrate the behaviour.







<chg><postalInfo type=3D"loc"/><chg> ->=
 remove the localised postal info


<chg><postalInfo type=3D"int"><org>ACME<=
;/org></postalInfo><chg> -> fail, missing required values=



<chg><postalInfo type=3D"int"><name>ACME&l=
t;/name><addr><city>Melbourne</city><cc>AU</c=
c></addr></postalInfo><chg> -> success, previous in=
t postal info replaced







Regards,


James Mitchell


Software Product Manager / ARI Registry Services









From: Seth Goldman <sethamin@google.com>

Date: Friday, 15 November 2013 11:1=
9 pm

To: "Hollenbeck, Scott" &=
lt;shollenbeck@verisign.com=
>

Cc: IETF Provreg Mailing List <<=
a href=3D"mailto:provreg@ietf.org">provreg@ietf.org>

Subject: Re: [provreg] RFC 5733: st=
reet changes with contact:update





















On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Sco=
tt 
<shollenbe=
ck@verisign.com> wrote:




> -----Original Message-----

> From: Klaus Malorny [mailto:=
Klaus.Malorny@knipp.de]

> Sent: Friday, November 15, 2013 4:01 AM

> To: Hollenbeck, Scott; Seth Goldman

> Cc: IETF Provreg Mailing List

> Subject: Re: [provreg] RFC 5733: street changes with contact:update
>






> On 14.11.2013 19:48, Hollenbeck, Scott wrote:

> > I don=92t know how one can make a case that sub-element replaceme=
nt is

> acceptable.

> > Section 3.2.5 of RFC 5733 says this (emphasis mine):

> >

> > =93The EPP <update> command provides a transform operation =
that allows

> a client to

> > modify the attributes of a contact _/object/_.=94

> >

> > and this:

> >

> > =93An OPTIONAL <contact:chg> element that contains _/object=
 attribute

> values to be

> > changed/_.=94

> >

> > The <update> is thus focused on _/changing/_ the attributes=
 of the

> _/object/_.

> > In the example Klaus provided, the command received is =93replace=
 the

> existing

> > <contact:postalInfo> attribute with a new instance of

> <contact:postalInfo>=94. The

> > server failed to replace the two <street> elements with the=
 single

> element

> > provided in the <update>. It shouldn=92t work that way.

> >

> > Scott

> >

>

> Hi Scot, Seth,

>

> up to now I regarded the name, the organization and the the whole

> address block

> as the replacable units, derived from the associated XML schema. It
> namely

> contains two datatypes, "postalInfoType" for the create comm=
and and

> "chgPostalInfoType" for the update command. The first contai=
ns the

> <name> and

> <addr> elements as mandatory elements, the latter contains them =
as

> optional

> elements. If one would consider the postalInfo itself as the replacabl=
e

> unit, it

> would not make sense to enforce the name and address on <create>=
, but

> would

> allow to remove them with a following <update> request.

>

> So simply asked: What does the following schema-wise legal request do?=


>

> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac=
t-1.0">

>    <contact:id>C20131114-01</contact:id>

>    <contact:chg>

>      <contact:postalInfo type=3D"int"/>=


>    </contact:chg>

> </contact:update>

>

> Does it clear the international contact? Does it leave the

> international postal

> data simply unchanged (aside from being illegal in Scot's view to

> submit a

> command that is effectively non-modifying). Does the following command=








Go back to what I was trying to say yesterday: <chg> means "repl=
ace existing with new". So yes, it would change the international post=
al info to "empty".




> <contact:update xmlns:contact=3D"urn:ietf:params:xml:ns:contac=
t-1.0">

>    <contact:id>C20131114-01</contact:id>

>    <contact:chg>

>      <contact:postalInfo type=3D"int"><=
br>
>        <contact:org>ACME Solutions</conta=
ct:org>

>      </contact:postalInfo>

>    </contact:chg>

> </contact:update>

>

> modify the postal info so that it *solely* contains the organization
> and nothing

> else afterwards?





Assuming all other schema requirements are met, yes.









I believe Klaus's point is that under this interpretation, the schema =
allows you to update a postalInfo to a version that would not be allowed in=
 a create.







I still think your interpretation of the replace semantics is correct.=
 But the schema is inconsistent, so it's understandable to interpret it oth=
erwise.


 





Scott





_______________________________________________

provreg mailing list

provreg@ietf.org

https://www.ietf.org/mailman/listinfo/provreg





























--_000_CEAB90ED51E41jgouldverisigncom_--

--_004_CEAB90ED51E41jgouldverisigncom_
Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[49].png"
Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[49].png
Content-Disposition: inline;
	filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[49].png"; size=4109;
	creation-date="Fri, 15 Nov 2013 14:04:11 GMT";
	modification-date="Fri, 15 Nov 2013 14:04:11 GMT"
Content-ID: <1A04AEB8-F54A-435E-8231-E78362210DD9>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ
hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC
1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl
hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0
UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4
aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT
LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff
mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU
yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9
x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY
u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K
hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg
8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF
SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a
w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD
ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z
0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4
eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y
q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+
saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto
uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o
alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0
l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj
ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739
+RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl
CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me
X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt
1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk
vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL
Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp
KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw
1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6
fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU
fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L
y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg
6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk
cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0
9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol
oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R
pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL
74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW
zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs
+aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk
WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0
TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB
Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth
eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr
xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx
iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N
yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI
4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2
eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY
u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn
FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG
VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY
TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy
c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg
xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu
2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu
jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196
6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO
24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN
YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq
FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI
tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex
TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq
bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau
LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY
O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx
J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1
ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J
GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO
RK5CYII=

--_004_CEAB90ED51E41jgouldverisigncom_--

From Klaus.Malorny@knipp.de  Mon Nov 18 03:52:50 2013
Return-Path: 
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25711E8198 for ; Mon, 18 Nov 2013 03:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.43
X-Spam-Level: 
X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.670,  BAYES_05=-1.11, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P32yFeT7ndfh for ; Mon, 18 Nov 2013 03:52:34 -0800 (PST)
Received: from kmx10a.knipp.de (clust3b.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id CC60711E80FB for ; Mon, 18 Nov 2013 03:52:33 -0800 (PST)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3681C49; Mon, 18 Nov 2013 12:52:31 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id a68sKHIU1Pg3; Mon, 18 Nov 2013 12:52:23 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 61D964A; Mon, 18 Nov 2013 12:52:23 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id rAIBqMrC015987;  Mon, 18 Nov 2013 12:52:22 +0100 (MEZ)
Message-ID: <5289FF75.6060501@knipp.de>
Date: Mon, 18 Nov 2013 12:52:21 +0100
From: Klaus Malorny 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Thunderbird/28.0a1
MIME-Version: 1.0
To: "Gould, James" , "james.mitchell@ausregistry.com.au" , Seth Goldman , "Hollenbeck, Scott" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Provreg Mailing List 
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Nov 2013 11:52:50 -0000

On 15.11.2013 15:04, Gould, James wrote:
> I agree that it changes/modifies the elements specified, where I view the
> elements as being the direct child elements of , which include:
>
>  1.  with type attribute as being relevant
>      1. For example, if a contact had both types of postalInfo, inclusion of
>         only one of the types ("int" or "loc") under the  does not
>         implicitly remove the other type.
>      2. All sub-elements of the  with type would be replaced
>         including the two streets to one street example.

ok, I think that makes most sense. Missing subelements within the  
element shall be regarded in the same way as during the , i.e. 
as an empty, "not specified" value that replaces any previous value. The 
elements ,  and  elements may not be excluded for a general 
update, as they are mandatory. The  and  elements may only be 
omitted along with the  element, which indicates that the respective 
 version shall be removed from contact as a whole.

Thanks all for the participation.

Regards,

Klaus


From shollenbeck@verisign.com  Thu Nov 21 06:07:30 2013
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 354F21ADF12 for ; Thu, 21 Nov 2013 06:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 rfIUAomZht-w for ; Thu, 21 Nov 2013 06:07:29 -0800 (PST)
Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id A62B81AE130 for ; Thu, 21 Nov 2013 06:07:28 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUo4TmeVaMTlbPXaGxSjIxMIVGP8dqXMp@postini.com; Thu, 21 Nov 2013 06:07:22 PST
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rALE7Ls1007394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Nov 2013 09:07:21 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 21 Nov 2013 09:07:20 -0500
From: "Hollenbeck, Scott" 
To: "provreg@ietf.org" 
Thread-Topic: IESG Review of Proposed EPPEXT Charter
Thread-Index: Ac7mwvv6hmyRTNU5QRql8SPU+VDS6g==
Date: Thu, 21 Nov 2013 14:07:19 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F492DDF6F@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [provreg] IESG Review of Proposed EPPEXT Charter
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, 21 Nov 2013 14:07:30 -0000

The IESG will discuss the proposed charter for a new EPP Extensions (EPPEXT=
) working group during today's telechat:

https://datatracker.ietf.org/doc/charter-ietf-eppext/

If the proposal is approved by the IESG the charter will be submitted to th=
e IETF community for review.

Scott

From shollenbeck@verisign.com  Fri Nov 22 09:20:27 2013
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 112F31AE04C for ; Fri, 22 Nov 2013 09:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Mp5tPlRHuxXI for ; Fri, 22 Nov 2013 09:20:24 -0800 (PST)
Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 90E3F1AE00C for ; Fri, 22 Nov 2013 09:20:24 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUo+SUdcK1F9KDqddPfVJENRUr2FkTRrw@postini.com; Fri, 22 Nov 2013 09:20:17 PST
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAMHKHQ3026123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Nov 2013 12:20:17 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 22 Nov 2013 12:20:16 -0500
From: "Hollenbeck, Scott" 
To: "provreg@ietf.org" 
Thread-Topic: WG Review: Extensible Provisioning Protocol Extensions (eppext)
Thread-Index: AQHO56bdz22Yz70R50Sqrygz07mTEJoxftAg
Date: Fri, 22 Nov 2013 17:20:16 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <20131122171808.16557.95825.idtracker@ietfa.amsl.com>
In-Reply-To: <20131122171808.16557.95825.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [provreg] FW: WG Review: Extensible Provisioning Protocol Extensions (eppext)
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, 22 Nov 2013 17:20:27 -0000

Yay!

Scott

-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Th=
e IESG
Sent: Friday, November 22, 2013 12:18 PM
To: IETF-Announce
Cc: eppext WG
Subject: WG Review: Extensible Provisioning Protocol Extensions (eppext)

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.

Extensible Provisioning Protocol Extensions (eppext)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Pete Resnick 

Charter:

The Extensible Provisioning Protocol (EPP) was a work product of the IETF
Provisioning Registry Protocol (provreg) working group. EPP was published
as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March
2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934)
in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733,
and 5734) in August 2009. It is the standard domain name provisioning
protocol for generic top-level domain name registries that operate under
the auspices of the Internet Corporation for Assigned Names and Numbers
(ICANN). It is also used by a number of country code top-level domain
registries.

Domain name registries implement a variety of business models. The
difference in these models made it very difficult to come up with a "one
size fits all" provisioning protocol, so the provreg working group made a
conscious decision to focus on a minimal set of common functionality. EPP
was designed to be extensible to allow additional features to be
specified on an "as needed" basis. Guidelines for extending EPP were
published as Informational RFC 3735 in March 2004.

The provreg working group was chartered to develop EPP, but not these
additional extensions. The working group was closed in 2004 after
producing a number of Proposed Standard specifications. As registries
began to implement and deploy EPP the need for extensions became real,
and the user community found itself facing a situation in which multiple
extensions were being developed by different registries to solve the same
basic problems, such as registering additional contact information.

EPP is widely implemented by generic top-level domain name registry
operators. It is also used by multiple country-code top-level domain name
registry operators. The Internet Corporation for Assigned Names and
Numbers (ICANN) has an active program to delegate a large number of new
generic top-level domains. EPP will be used to provision those domains,
and new registry operators are expected to develop additional protocol
extensions. With no way to coordinate the development of these
extensions, the problem of non-standard extension duplication by multiple
operators is only expected to become worse.

The goal of the EPP Extensions (eppext) working group is to create an
IANA registry of EPP extensions and to review specifications of
extensions for inclusion in the registry. It will accomplish this goal in
two steps:

1. Develop a specification for a registry of and corresponding
registration procedures for EPP extensions. One proposal is documented in
https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.

2. Produce a small number of extensions based on existing Internet Draft
documents and use the IANA registration process as developed in 1 to
register those extensions, as follows:

DNSSEC key relay: draft-gieben-epp-keyrelay
(http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)

Internationalized domain names: draft-obispo-epp-idn
(http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)

New TLD launch phases: draft-tan-epp-launchphase
(http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)

Trademark Clearinghouse: draft-lozano-tmch-smd
(https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)

Note: draft-tan-epp-launchphase has a normative dependency on
draft-lozano-tmch-smd.

Only the development of the registration process and the
publication/registration of the four extensions noted above are in scope
for the working group. The working group can choose not to publish or
register one or more of the extensions noted above, but it is out of
scope to work on other extensions.


Milestones:
  May 2014 - Extensions registry document to IESG =20
  Jul 2014 - DNSSEC key relay extension to IESG
  Jul 2014 - New TLD launch phases extension to IESG
  Sep 2014 - Internationalized domain names extension to IESG



From paf@frobbit.se  Fri Nov 22 23:48:47 2013
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 40F2E1AE0FA for ; Fri, 22 Nov 2013 23:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.776
X-Spam-Level: 
X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.525, 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 9qTnXTIuF3cW for ; Fri, 22 Nov 2013 23:48:45 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4351AE01D for ; Fri, 22 Nov 2013 23:48:45 -0800 (PST)
Received: from [10.1.6.196] (unknown [37.205.61.203]) by mail.frobbit.se (Postfix) with ESMTPSA id ACBD02032D; Sat, 23 Nov 2013 08:48:35 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Date: Sat, 23 Nov 2013 08:48:34 +0100
Message-Id: 
References: <20131122171808.16557.95825.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
To: Scott Hollenbeck 
X-Mailer: Apple Mail (2.1822)
Cc: "provreg@ietf.org" 
Subject: Re: [provreg] WG Review: Extensible Provisioning Protocol Extensions (eppext)
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: Sat, 23 Nov 2013 07:48:47 -0000

--Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1

On 22 nov 2013, at 18:20, Hollenbeck, Scott  =
wrote:

> Yay!
>=20
> Scott
>=20
> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf =
Of The IESG
> Sent: Friday, November 22, 2013 12:18 PM
> To: IETF-Announce
> Cc: eppext WG
> Subject: WG Review: Extensible Provisioning Protocol Extensions =
(eppext)
>=20
> A new IETF working group has been proposed in the Applications Area. =
The
> IESG has not made any determination yet. The following draft charter =
was
> submitted, and is provided for informational purposes only. Please =
send
> your comments to the IESG mailing list (iesg at ietf.org) by =
2013-12-02.
>=20
> Extensible Provisioning Protocol Extensions (eppext)
> ------------------------------------------------
> Current Status: Proposed WG
>=20
> Assigned Area Director:
>  Pete Resnick 
>=20
> Charter:
>=20
> The Extensible Provisioning Protocol (EPP) was a work product of the =
IETF
> Provisioning Registry Protocol (provreg) working group. EPP was =
published
> as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in =
March
> 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and =
4934)
> in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733,
> and 5734) in August 2009. It is the standard domain name provisioning
> protocol for generic top-level domain name registries that operate =
under
> the auspices of the Internet Corporation for Assigned Names and =
Numbers
> (ICANN). It is also used by a number of country code top-level domain
> registries.
>=20
> Domain name registries implement a variety of business models. The
> difference in these models made it very difficult to come up with a =
"one
> size fits all" provisioning protocol, so the provreg working group =
made a
> conscious decision to focus on a minimal set of common functionality. =
EPP
> was designed to be extensible to allow additional features to be
> specified on an "as needed" basis. Guidelines for extending EPP were
> published as Informational RFC 3735 in March 2004.
>=20
> The provreg working group was chartered to develop EPP, but not these
> additional extensions. The working group was closed in 2004 after
> producing a number of Proposed Standard specifications. As registries
> began to implement and deploy EPP the need for extensions became real,
> and the user community found itself facing a situation in which =
multiple
> extensions were being developed by different registries to solve the =
same
> basic problems, such as registering additional contact information.
>=20
> EPP is widely implemented by generic top-level domain name registry
> operators. It is also used by multiple country-code top-level domain =
name
> registry operators. The Internet Corporation for Assigned Names and
> Numbers (ICANN) has an active program to delegate a large number of =
new
> generic top-level domains. EPP will be used to provision those =
domains,
> and new registry operators are expected to develop additional protocol
> extensions. With no way to coordinate the development of these
> extensions, the problem of non-standard extension duplication by =
multiple
> operators is only expected to become worse.
>=20
> The goal of the EPP Extensions (eppext) working group is to create an
> IANA registry of EPP extensions and to review specifications of
> extensions for inclusion in the registry. It will accomplish this goal =
in
> two steps:
>=20
> 1. Develop a specification for a registry of and corresponding
> registration procedures for EPP extensions. One proposal is documented =
in
> https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.
>=20
> 2. Produce a small number of extensions based on existing Internet =
Draft
> documents and use the IANA registration process as developed in 1 to
> register those extensions, as follows:
>=20
> DNSSEC key relay: draft-gieben-epp-keyrelay
> (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)
>=20
> Internationalized domain names: draft-obispo-epp-idn
> (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)
>=20
> New TLD launch phases: draft-tan-epp-launchphase
> (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)
>=20
> Trademark Clearinghouse: draft-lozano-tmch-smd
> (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)
>=20
> Note: draft-tan-epp-launchphase has a normative dependency on
> draft-lozano-tmch-smd.
>=20
> Only the development of the registration process and the
> publication/registration of the four extensions noted above are in =
scope
> for the working group. The working group can choose not to publish or
> register one or more of the extensions noted above, but it is out of
> scope to work on other extensions.
>=20
>=20
> Milestones:
>  May 2014 - Extensions registry document to IESG =20
>  Jul 2014 - DNSSEC key relay extension to IESG
>  Jul 2014 - New TLD launch phases extension to IESG
>  Sep 2014 - Internationalized domain names extension to IESG
>=20
>=20
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg


--Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFSkF3SrMabGguI180RAo8+AKCVOXaZp7c0E9gM+bKEaDpMlhrEOwCZAdTA
pCIi3TdxHdBRyhCfyXCUPqA=
=4MeE
-----END PGP SIGNATURE-----

--Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27--

From bernie@ietf.hoeneisen.ch  Sat Nov 23 02:59:40 2013
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 56CC91AE2B6 for ; Sat, 23 Nov 2013 02:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level: 
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 bxWm34gp9aZY for ; Sat, 23 Nov 2013 02:59:37 -0800 (PST)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA11AC862 for ; Sat, 23 Nov 2013 02:59:36 -0800 (PST)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1VkAw0-00079C-Bd; Sat, 23 Nov 2013 11:59:33 +0100
Date: Sat, 23 Nov 2013 11:59:32 +0100 (CET)
From: Bernie Hoeneisen 
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: "Hollenbeck, Scott" 
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Message-ID: 
References: <20131122171808.16557.95825.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Cc: "provreg@ietf.org" 
Subject: Re: [provreg] FW: WG Review: Extensible Provisioning Protocol Extensions (eppext)
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: Sat, 23 Nov 2013 10:59:40 -0000

+1

Looks like a great plan! Glad to see this moving forward!

[ Something I was proposing already 7:ish years ago, though with far less 
traction than now...the proposal appears to have matured a lot over 
time... ]

Thanks Scott et al. for taking care of this!

All the best,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Technology


On Fri, 22 Nov 2013, Hollenbeck, Scott wrote:

> Yay!
>
> Scott
>
> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
> Sent: Friday, November 22, 2013 12:18 PM
> To: IETF-Announce
> Cc: eppext WG
> Subject: WG Review: Extensible Provisioning Protocol Extensions (eppext)
>
> A new IETF working group has been proposed in the Applications Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.
>
> Extensible Provisioning Protocol Extensions (eppext)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Assigned Area Director:
>  Pete Resnick 
>
> Charter:
>
> The Extensible Provisioning Protocol (EPP) was a work product of the IETF
> Provisioning Registry Protocol (provreg) working group. EPP was published
> as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March
> 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934)
> in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733,
> and 5734) in August 2009. It is the standard domain name provisioning
> protocol for generic top-level domain name registries that operate under
> the auspices of the Internet Corporation for Assigned Names and Numbers
> (ICANN). It is also used by a number of country code top-level domain
> registries.
>
> Domain name registries implement a variety of business models. The
> difference in these models made it very difficult to come up with a "one
> size fits all" provisioning protocol, so the provreg working group made a
> conscious decision to focus on a minimal set of common functionality. EPP
> was designed to be extensible to allow additional features to be
> specified on an "as needed" basis. Guidelines for extending EPP were
> published as Informational RFC 3735 in March 2004.
>
> The provreg working group was chartered to develop EPP, but not these
> additional extensions. The working group was closed in 2004 after
> producing a number of Proposed Standard specifications. As registries
> began to implement and deploy EPP the need for extensions became real,
> and the user community found itself facing a situation in which multiple
> extensions were being developed by different registries to solve the same
> basic problems, such as registering additional contact information.
>
> EPP is widely implemented by generic top-level domain name registry
> operators. It is also used by multiple country-code top-level domain name
> registry operators. The Internet Corporation for Assigned Names and
> Numbers (ICANN) has an active program to delegate a large number of new
> generic top-level domains. EPP will be used to provision those domains,
> and new registry operators are expected to develop additional protocol
> extensions. With no way to coordinate the development of these
> extensions, the problem of non-standard extension duplication by multiple
> operators is only expected to become worse.
>
> The goal of the EPP Extensions (eppext) working group is to create an
> IANA registry of EPP extensions and to review specifications of
> extensions for inclusion in the registry. It will accomplish this goal in
> two steps:
>
> 1. Develop a specification for a registry of and corresponding
> registration procedures for EPP extensions. One proposal is documented in
> https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.
>
> 2. Produce a small number of extensions based on existing Internet Draft
> documents and use the IANA registration process as developed in 1 to
> register those extensions, as follows:
>
> DNSSEC key relay: draft-gieben-epp-keyrelay
> (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)
>
> Internationalized domain names: draft-obispo-epp-idn
> (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)
>
> New TLD launch phases: draft-tan-epp-launchphase
> (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)
>
> Trademark Clearinghouse: draft-lozano-tmch-smd
> (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)
>
> Note: draft-tan-epp-launchphase has a normative dependency on
> draft-lozano-tmch-smd.
>
> Only the development of the registration process and the
> publication/registration of the four extensions noted above are in scope
> for the working group. The working group can choose not to publish or
> register one or more of the extensions noted above, but it is out of
> scope to work on other extensions.
>
>
> Milestones:
>  May 2014 - Extensions registry document to IESG
>  Jul 2014 - DNSSEC key relay extension to IESG
>  Jul 2014 - New TLD launch phases extension to IESG
>  Sep 2014 - Internationalized domain names extension to IESG
>
>
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
>

From yaojk@cnnic.cn  Sun Nov 24 18:44:38 2013
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 C445B1A1F5B for ; Sun, 24 Nov 2013 18:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 EUFmBudOocFX for ; Sun, 24 Nov 2013 18:44:36 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 187161A1F1B for ; Sun, 24 Nov 2013 18:44:34 -0800 (PST)
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 25 Nov 2013 10:44:30 +0800
Date: Mon, 25 Nov 2013 10:44:31 +0800
From: "Jiankang Yao" 
To: =?gb2312?B?SG9sbGVuYmVjaywgU2NvdHQ=?= ,  "provreg@ietf.org" 
References: <20131122171808.16557.95825.idtracker@ietfa.amsl.com>,  <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.0.1.92[cn]
Mime-Version: 1.0
Message-ID: <201311251044260557202@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart026522437723_=----"
Subject: Re: [provreg] FW: WG Review: Extensible Provisioning Protocol Extensions (eppext)
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: yaojk 
List-Id: EPP discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Nov 2013 02:44:39 -0000

This is a multi-part message in MIME format.

------=_001_NextPart026522437723_=----
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

R3JlYXQhDQppdCBpcyBhIGJpZyBzdGVwIHRvIG1vdmUgdG8gYSBXRy4NClNvIHdlIGhhdmUgYSBX
RyBtZWV0aW5nIGluIExvbmRvbiBtZWV0aW5nLCBNYXJjaCwgMjAxNC4NCg0KVGhlIGdvYWwgaXMg
dG8gaGF2ZSAiTWF5IDIwMTQgLSBFeHRlbnNpb25zIHJlZ2lzdHJ5IGRvY3VtZW50IHRvIElFU0cg
Ig0KDQpJdCBpcyBhIGxpdHRsZSBhbWJpb3VzLg0KDQoNCg0KDQpKaWFua2FuZyBZYW8NCg0KRnJv
bTogSG9sbGVuYmVjaywgU2NvdHQNCkRhdGU6IDIwMTMtMTEtMjMgMDE6MjANClRvOiBwcm92cmVn
QGlldGYub3JnDQpTdWJqZWN0OiBbcHJvdnJlZ10gRlc6IFdHIFJldmlldzogRXh0ZW5zaWJsZSBQ
cm92aXNpb25pbmcgUHJvdG9jb2wgRXh0ZW5zaW9ucyAoZXBwZXh0KQ0KWWF5IQ0KDQpTY290dA0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURi1Bbm5vdW5jZSBbbWFpbHRv
OmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJRVNHDQpT
ZW50OiBGcmlkYXksIE5vdmVtYmVyIDIyLCAyMDEzIDEyOjE4IFBNDQpUbzogSUVURi1Bbm5vdW5j
ZQ0KQ2M6IGVwcGV4dCBXRw0KU3ViamVjdDogV0cgUmV2aWV3OiBFeHRlbnNpYmxlIFByb3Zpc2lv
bmluZyBQcm90b2NvbCBFeHRlbnNpb25zIChlcHBleHQpDQoNCkEgbmV3IElFVEYgd29ya2luZyBn
cm91cCBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgQXBwbGljYXRpb25zIEFyZWEuIFRoZQ0KSUVT
RyBoYXMgbm90IG1hZGUgYW55IGRldGVybWluYXRpb24geWV0LiBUaGUgZm9sbG93aW5nIGRyYWZ0
IGNoYXJ0ZXIgd2FzDQpzdWJtaXR0ZWQsIGFuZCBpcyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25h
bCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZA0KeW91ciBjb21tZW50cyB0byB0aGUgSUVTRyBt
YWlsaW5nIGxpc3QgKGllc2cgYXQgaWV0Zi5vcmcpIGJ5IDIwMTMtMTItMDIuDQoNCkV4dGVuc2li
bGUgUHJvdmlzaW9uaW5nIFByb3RvY29sIEV4dGVuc2lvbnMgKGVwcGV4dCkNCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ3VycmVudCBTdGF0dXM6IFBy
b3Bvc2VkIFdHDQoNCkFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6DQogIFBldGUgUmVzbmljayA8cHJl
c25pY2tAcXRpLnF1YWxjb21tLmNvbT4NCg0KQ2hhcnRlcjoNCg0KVGhlIEV4dGVuc2libGUgUHJv
dmlzaW9uaW5nIFByb3RvY29sIChFUFApIHdhcyBhIHdvcmsgcHJvZHVjdCBvZiB0aGUgSUVURg0K
UHJvdmlzaW9uaW5nIFJlZ2lzdHJ5IFByb3RvY29sIChwcm92cmVnKSB3b3JraW5nIGdyb3VwLiBF
UFAgd2FzIHB1Ymxpc2hlZA0KYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCAoUkZDcyAzNzMwLCAzNzMx
LCAzNzMyLCAzNzMzLCBhbmQgMzczNCkgaW4gTWFyY2gNCjIwMDQuIEl0IGJlY2FtZSBhIERyYWZ0
IFN0YW5kYXJkIChSRkNzIDQ5MzAsIDQ5MzEsIDQ5MzIsIDQ5MzMsIGFuZCA0OTM0KQ0KaW4gTWF5
IDIwMDcsIGFuZCBhIFN0YW5kYXJkIChTdGFuZGFyZCA2OTsgUkZDcyA1NzMwLCA1NzMxLCA1NzMy
LCA1NzMzLA0KYW5kIDU3MzQpIGluIEF1Z3VzdCAyMDA5LiBJdCBpcyB0aGUgc3RhbmRhcmQgZG9t
YWluIG5hbWUgcHJvdmlzaW9uaW5nDQpwcm90b2NvbCBmb3IgZ2VuZXJpYyB0b3AtbGV2ZWwgZG9t
YWluIG5hbWUgcmVnaXN0cmllcyB0aGF0IG9wZXJhdGUgdW5kZXINCnRoZSBhdXNwaWNlcyBvZiB0
aGUgSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZCBOdW1iZXJzDQoo
SUNBTk4pLiBJdCBpcyBhbHNvIHVzZWQgYnkgYSBudW1iZXIgb2YgY291bnRyeSBjb2RlIHRvcC1s
ZXZlbCBkb21haW4NCnJlZ2lzdHJpZXMuDQoNCkRvbWFpbiBuYW1lIHJlZ2lzdHJpZXMgaW1wbGVt
ZW50IGEgdmFyaWV0eSBvZiBidXNpbmVzcyBtb2RlbHMuIFRoZQ0KZGlmZmVyZW5jZSBpbiB0aGVz
ZSBtb2RlbHMgbWFkZSBpdCB2ZXJ5IGRpZmZpY3VsdCB0byBjb21lIHVwIHdpdGggYSAib25lDQpz
aXplIGZpdHMgYWxsIiBwcm92aXNpb25pbmcgcHJvdG9jb2wsIHNvIHRoZSBwcm92cmVnIHdvcmtp
bmcgZ3JvdXAgbWFkZSBhDQpjb25zY2lvdXMgZGVjaXNpb24gdG8gZm9jdXMgb24gYSBtaW5pbWFs
IHNldCBvZiBjb21tb24gZnVuY3Rpb25hbGl0eS4gRVBQDQp3YXMgZGVzaWduZWQgdG8gYmUgZXh0
ZW5zaWJsZSB0byBhbGxvdyBhZGRpdGlvbmFsIGZlYXR1cmVzIHRvIGJlDQpzcGVjaWZpZWQgb24g
YW4gImFzIG5lZWRlZCIgYmFzaXMuIEd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyBFUFAgd2VyZQ0K
cHVibGlzaGVkIGFzIEluZm9ybWF0aW9uYWwgUkZDIDM3MzUgaW4gTWFyY2ggMjAwNC4NCg0KVGhl
IHByb3ZyZWcgd29ya2luZyBncm91cCB3YXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgRVBQLCBidXQg
bm90IHRoZXNlDQphZGRpdGlvbmFsIGV4dGVuc2lvbnMuIFRoZSB3b3JraW5nIGdyb3VwIHdhcyBj
bG9zZWQgaW4gMjAwNCBhZnRlcg0KcHJvZHVjaW5nIGEgbnVtYmVyIG9mIFByb3Bvc2VkIFN0YW5k
YXJkIHNwZWNpZmljYXRpb25zLiBBcyByZWdpc3RyaWVzDQpiZWdhbiB0byBpbXBsZW1lbnQgYW5k
IGRlcGxveSBFUFAgdGhlIG5lZWQgZm9yIGV4dGVuc2lvbnMgYmVjYW1lIHJlYWwsDQphbmQgdGhl
IHVzZXIgY29tbXVuaXR5IGZvdW5kIGl0c2VsZiBmYWNpbmcgYSBzaXR1YXRpb24gaW4gd2hpY2gg
bXVsdGlwbGUNCmV4dGVuc2lvbnMgd2VyZSBiZWluZyBkZXZlbG9wZWQgYnkgZGlmZmVyZW50IHJl
Z2lzdHJpZXMgdG8gc29sdmUgdGhlIHNhbWUNCmJhc2ljIHByb2JsZW1zLCBzdWNoIGFzIHJlZ2lz
dGVyaW5nIGFkZGl0aW9uYWwgY29udGFjdCBpbmZvcm1hdGlvbi4NCg0KRVBQIGlzIHdpZGVseSBp
bXBsZW1lbnRlZCBieSBnZW5lcmljIHRvcC1sZXZlbCBkb21haW4gbmFtZSByZWdpc3RyeQ0Kb3Bl
cmF0b3JzLiBJdCBpcyBhbHNvIHVzZWQgYnkgbXVsdGlwbGUgY291bnRyeS1jb2RlIHRvcC1sZXZl
bCBkb21haW4gbmFtZQ0KcmVnaXN0cnkgb3BlcmF0b3JzLiBUaGUgSW50ZXJuZXQgQ29ycG9yYXRp
b24gZm9yIEFzc2lnbmVkIE5hbWVzIGFuZA0KTnVtYmVycyAoSUNBTk4pIGhhcyBhbiBhY3RpdmUg
cHJvZ3JhbSB0byBkZWxlZ2F0ZSBhIGxhcmdlIG51bWJlciBvZiBuZXcNCmdlbmVyaWMgdG9wLWxl
dmVsIGRvbWFpbnMuIEVQUCB3aWxsIGJlIHVzZWQgdG8gcHJvdmlzaW9uIHRob3NlIGRvbWFpbnMs
DQphbmQgbmV3IHJlZ2lzdHJ5IG9wZXJhdG9ycyBhcmUgZXhwZWN0ZWQgdG8gZGV2ZWxvcCBhZGRp
dGlvbmFsIHByb3RvY29sDQpleHRlbnNpb25zLiBXaXRoIG5vIHdheSB0byBjb29yZGluYXRlIHRo
ZSBkZXZlbG9wbWVudCBvZiB0aGVzZQ0KZXh0ZW5zaW9ucywgdGhlIHByb2JsZW0gb2Ygbm9uLXN0
YW5kYXJkIGV4dGVuc2lvbiBkdXBsaWNhdGlvbiBieSBtdWx0aXBsZQ0Kb3BlcmF0b3JzIGlzIG9u
bHkgZXhwZWN0ZWQgdG8gYmVjb21lIHdvcnNlLg0KDQpUaGUgZ29hbCBvZiB0aGUgRVBQIEV4dGVu
c2lvbnMgKGVwcGV4dCkgd29ya2luZyBncm91cCBpcyB0byBjcmVhdGUgYW4NCklBTkEgcmVnaXN0
cnkgb2YgRVBQIGV4dGVuc2lvbnMgYW5kIHRvIHJldmlldyBzcGVjaWZpY2F0aW9ucyBvZg0KZXh0
ZW5zaW9ucyBmb3IgaW5jbHVzaW9uIGluIHRoZSByZWdpc3RyeS4gSXQgd2lsbCBhY2NvbXBsaXNo
IHRoaXMgZ29hbCBpbg0KdHdvIHN0ZXBzOg0KDQoxLiBEZXZlbG9wIGEgc3BlY2lmaWNhdGlvbiBm
b3IgYSByZWdpc3RyeSBvZiBhbmQgY29ycmVzcG9uZGluZw0KcmVnaXN0cmF0aW9uIHByb2NlZHVy
ZXMgZm9yIEVQUCBleHRlbnNpb25zLiBPbmUgcHJvcG9zYWwgaXMgZG9jdW1lbnRlZCBpbg0KaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbGVuYmVjay1lcHAtZXh0LXJl
Zy8uDQoNCjIuIFByb2R1Y2UgYSBzbWFsbCBudW1iZXIgb2YgZXh0ZW5zaW9ucyBiYXNlZCBvbiBl
eGlzdGluZyBJbnRlcm5ldCBEcmFmdA0KZG9jdW1lbnRzIGFuZCB1c2UgdGhlIElBTkEgcmVnaXN0
cmF0aW9uIHByb2Nlc3MgYXMgZGV2ZWxvcGVkIGluIDEgdG8NCnJlZ2lzdGVyIHRob3NlIGV4dGVu
c2lvbnMsIGFzIGZvbGxvd3M6DQoNCkROU1NFQyBrZXkgcmVsYXk6IGRyYWZ0LWdpZWJlbi1lcHAt
a2V5cmVsYXkNCihodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdpZWJlbi1l
cHAta2V5cmVsYXkvKQ0KDQpJbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFtZXM6IGRyYWZ0LW9i
aXNwby1lcHAtaWRuDQooaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vYmlz
cG8tZXBwLWlkbi8pDQoNCk5ldyBUTEQgbGF1bmNoIHBoYXNlczogZHJhZnQtdGFuLWVwcC1sYXVu
Y2hwaGFzZQ0KKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGFuLWVwcC1s
YXVuY2hwaGFzZS8pDQoNClRyYWRlbWFyayBDbGVhcmluZ2hvdXNlOiBkcmFmdC1sb3phbm8tdG1j
aC1zbWQNCihodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sb3phbm8tdG1j
aC1zbWQvKQ0KDQpOb3RlOiBkcmFmdC10YW4tZXBwLWxhdW5jaHBoYXNlIGhhcyBhIG5vcm1hdGl2
ZSBkZXBlbmRlbmN5IG9uDQpkcmFmdC1sb3phbm8tdG1jaC1zbWQuDQoNCk9ubHkgdGhlIGRldmVs
b3BtZW50IG9mIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBhbmQgdGhlDQpwdWJsaWNhdGlvbi9y
ZWdpc3RyYXRpb24gb2YgdGhlIGZvdXIgZXh0ZW5zaW9ucyBub3RlZCBhYm92ZSBhcmUgaW4gc2Nv
cGUNCmZvciB0aGUgd29ya2luZyBncm91cC4gVGhlIHdvcmtpbmcgZ3JvdXAgY2FuIGNob29zZSBu
b3QgdG8gcHVibGlzaCBvcg0KcmVnaXN0ZXIgb25lIG9yIG1vcmUgb2YgdGhlIGV4dGVuc2lvbnMg
bm90ZWQgYWJvdmUsIGJ1dCBpdCBpcyBvdXQgb2YNCnNjb3BlIHRvIHdvcmsgb24gb3RoZXIgZXh0
ZW5zaW9ucy4NCg0KDQpNaWxlc3RvbmVzOg0KICBNYXkgMjAxNCAtIEV4dGVuc2lvbnMgcmVnaXN0
cnkgZG9jdW1lbnQgdG8gSUVTRyAgDQogIEp1bCAyMDE0IC0gRE5TU0VDIGtleSByZWxheSBleHRl
bnNpb24gdG8gSUVTRw0KICBKdWwgMjAxNCAtIE5ldyBUTEQgbGF1bmNoIHBoYXNlcyBleHRlbnNp
b24gdG8gSUVTRw0KICBTZXAgMjAxNCAtIEludGVybmF0aW9uYWxpemVkIGRvbWFpbiBuYW1lcyBl
eHRlbnNpb24gdG8gSUVTRw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpwcm92cmVnIG1haWxpbmcgbGlzdA0KcHJvdnJlZ0BpZXRmLm9yZw0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92cmVn

------=_001_NextPart026522437723_=----
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable









Great!


it is a big step to move to a WG.

So we have a WG meeting in London meet=
ing,=20
March, 2014.


 


The goal is to have=20
"May 2014 - Extensions registry document to&=
nbsp;IESG "


 


It is a little ambious.


 





Jiankang Yao


 





Date: 2013-11-23 01:20


To: provreg@ietf.org


Subject: [provreg] FW: WG Review: Extensible Provisioning=
=20
Protocol Extensions (eppext)




Yay!


 


Scott


 


-----Original Message-----


From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org]=
 On Behalf Of The IESG


Sent: Friday, November 22, 2013 12:18 P=
M


To: IETF-Announce


Cc: eppext WG


Subject: WG Review: Extensible Provisioning =
Protocol Extensions (eppext)


 


A new IETF working group has been =
proposed in the Applications Area. The


IESG has not made any determination yet=
. The following draft charter was


submitted, and is provided for informational=
 purposes only. Please send


your comments to the IESG mailing list&=
nbsp;(iesg at ietf.org) by 2013-12-02.


 


Extensible Provisioning Protocol Extensions (eppe=
xt)


------------------------------------------------


Current Status: Proposed WG


 


Assigned Area Director:


  Pete Resnick <presnick@qti.qualcomm.com><=
/DIV>

 


Charter:


 


The Extensible Provisioning Protocol (EPP) w=
as a work product of the IETF


Provisioning Registry Protocol (provreg) working&=
nbsp;group. EPP was published


as a Proposed Standard (RFCs 3730, 3731=
, 3732, 3733, and 3734) in March


2004. It became a Draft Standard (RFCs&=
nbsp;4930, 4931, 4932, 4933, and 4934)


in May 2007, and a Standard (Standard&n=
bsp;69; RFCs 5730, 5731, 5732, 5733,


and 5734) in August 2009. It is th=
e standard domain name provisioning


protocol for generic top-level domain name&n=
bsp;registries that operate under


the auspices of the Internet Corporation&nbs=
p;for Assigned Names and Numbers


(ICANN). It is also used by a numb=
er of country code top-level domain


registries.


 


Domain name registries implement a variety&n=
bsp;of business models. The


difference in these models made it very=
 difficult to come up with a "one


size fits all" provisioning protocol, so&nbs=
p;the provreg working group made a


conscious decision to focus on a minima=
l set of common functionality. EPP


was designed to be extensible to allow&=
nbsp;additional features to be


specified on an "as needed" basis. Guid=
elines for extending EPP were


published as Informational RFC 3735 in =
March 2004.


 


The provreg working group was chartered =
;to develop EPP, but not these


additional extensions. The working group was=
 closed in 2004 after


producing a number of Proposed Standard =
;specifications. As registries


began to implement and deploy EPP the&n=
bsp;need for extensions became real,


and the user community found itself fac=
ing a situation in which multiple


extensions were being developed by different=
 registries to solve the same


basic problems, such as registering addition=
al contact information.


 


EPP is widely implemented by generic to=
p-level domain name registry


operators. It is also used by multiple&=
nbsp;country-code top-level domain name


registry operators. The Internet Corporation =
;for Assigned Names and


Numbers (ICANN) has an active program t=
o delegate a large number of new


generic top-level domains. EPP will be =
used to provision those domains,


and new registry operators are expected =
;to develop additional protocol


extensions. With no way to coordinate t=
he development of these


extensions, the problem of non-standard exte=
nsion duplication by multiple


operators is only expected to become wo=
rse.


 


The goal of the EPP Extensions (eppext)=
 working group is to create an


IANA registry of EPP extensions and to&=
nbsp;review specifications of


extensions for inclusion in the registry.&nb=
sp;It will accomplish this goal in


two steps:


 


1. Develop a specification for a regist=
ry of and corresponding


registration procedures for EPP extensions. =
One proposal is documented in


https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.


 


2. Produce a small number of extensions=
 based on existing Internet Draft


documents and use the IANA registration =
;process as developed in 1 to


register those extensions, as follows:


 


DNSSEC key relay: draft-gieben-epp-keyrelay


(http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)


 


Internationalized domain names: draft-obispo-epp-idn

(http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)


 


New TLD launch phases: draft-tan-epp-launchphase<=
/DIV>

(http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)


 


Trademark Clearinghouse: draft-lozano-tmch-smd


(https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)


 


Note: draft-tan-epp-launchphase has a normative&n=
bsp;dependency on


draft-lozano-tmch-smd.


 


Only the development of the registration&nbs=
p;process and the


publication/registration of the four extensions&n=
bsp;noted above are in scope


for the working group. The working grou=
p can choose not to publish or


register one or more of the extensions&=
nbsp;noted above, but it is out of


scope to work on other extensions.


 


 


Milestones:


  May 2014 - Extensions registry d=
ocument to IESG  


  Jul 2014 - DNSSEC key relay =
;extension to IESG


  Jul 2014 - New TLD launch p=
hases extension to IESG


  Sep 2014 - Internationalized domain&n=
bsp;names extension to IESG


 


 


_______________________________________________


provreg mailing list


provreg@ietf.org


https://www.ietf.org/mailman/listinfo/provreg


------=_001_NextPart026522437723_=------


From shollenbeck@verisign.com  Mon Nov 25 04:25:24 2013
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 AB2BA1AD93D for ; Mon, 25 Nov 2013 04:25:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 05BlP32Vo8tz for ; Mon, 25 Nov 2013 04:25:19 -0800 (PST)
Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id C2D5D1AD94A for ; Mon, 25 Nov 2013 04:25:16 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUpNBrTsEYh8AxBMXmmKu/5cXKfJC0hKh@postini.com; Mon, 25 Nov 2013 04:25:19 PST
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rAPCPGQg025895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 07:25:16 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 25 Nov 2013 07:25:16 -0500
From: "Hollenbeck, Scott" 
To: yaojk , "provreg@ietf.org" 
Thread-Topic: [provreg] FW: WG Review: Extensible Provisioning Protocol Extensions (eppext)
Thread-Index: AQHO56bdz22Yz70R50Sqrygz07mTEJo1QUGfgACfk2A=
Date: Mon, 25 Nov 2013 12:25:15 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F492EDFFA@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <20131122171808.16557.95825.idtracker@ietfa.amsl.com>, <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <201311251044260557202@cnnic.cn>
In-Reply-To: <201311251044260557202@cnnic.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F492EDFFABRN1WNEXMBX01vc_"
MIME-Version: 1.0
Subject: Re: [provreg] FW: WG Review: Extensible Provisioning Protocol Extensions (eppext)
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: Mon, 25 Nov 2013 12:25:24 -0000

--_000_831693C2CDA2E849A7D7A712B24E257F492EDFFABRN1WNEXMBX01vc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Don't be surprised if there is no meeting scheduled for London. Meetings ar=
e used to sort out challenging issues in real time. If there are no challen=
ging issues, there will be no meeting - and creation of a registry frankly =
should not be that challenging.
On the milestone: we already have one document that describes a proposal fo=
r the registry. The WG will have to decide to accept it or not, but IMHO th=
ere aren't too many ways to do this and the existing document can be change=
d to address any deficiencies. It really shouldn't take all that long!
This comment* from Barry Leiba of the IESG provides an interesting counter =
to the comment made below: "Only comment: the proposed milestone for the re=
gistry doc seems sadly pessimistic.  Why should the registry take so long t=
o define?".
Scott

* https://datatracker.ietf.org/doc/charter-ietf-eppext/ballot/

From: Jiankang Yao [mailto:yaojk@cnnic.cn]
Sent: Sunday, November 24, 2013 9:45 PM
To: Hollenbeck, Scott; provreg@ietf.org
Subject: Re: [provreg] FW: WG Review: Extensible Provisioning Protocol Exte=
nsions (eppext)

Great!
it is a big step to move to a WG.
So we have a WG meeting in London meeting, March, 2014.

The goal is to have "May 2014 - Extensions registry document to IESG "

It is a little ambious.

________________________________
Jiankang Yao

From: Hollenbeck, Scott
Date: 2013-11-23 01:20
To: provreg@ietf.org
Subject: [provreg] FW: WG Review: Extensible Provisioning Protocol Extensio=
ns (eppext)
Yay!

Scott

-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Th=
e IESG
Sent: Friday, November 22, 2013 12:18 PM
To: IETF-Announce
Cc: eppext WG
Subject: WG Review: Extensible Provisioning Protocol Extensions (eppext)

A new IETF working group has been proposed in the Applications Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.

Extensible Provisioning Protocol Extensions (eppext)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Pete Resnick =
>

Charter:

The Extensible Provisioning Protocol (EPP) was a work product of the IETF
Provisioning Registry Protocol (provreg) working group. EPP was published
as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March
2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934)
in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733,
and 5734) in August 2009. It is the standard domain name provisioning
protocol for generic top-level domain name registries that operate under
the auspices of the Internet Corporation for Assigned Names and Numbers
(ICANN). It is also used by a number of country code top-level domain
registries.

Domain name registries implement a variety of business models. The
difference in these models made it very difficult to come up with a "one
size fits all" provisioning protocol, so the provreg working group made a
conscious decision to focus on a minimal set of common functionality. EPP
was designed to be extensible to allow additional features to be
specified on an "as needed" basis. Guidelines for extending EPP were
published as Informational RFC 3735 in March 2004.

The provreg working group was chartered to develop EPP, but not these
additional extensions. The working group was closed in 2004 after
producing a number of Proposed Standard specifications. As registries
began to implement and deploy EPP the need for extensions became real,
and the user community found itself facing a situation in which multiple
extensions were being developed by different registries to solve the same
basic problems, such as registering additional contact information.

EPP is widely implemented by generic top-level domain name registry
operators. It is also used by multiple country-code top-level domain name
registry operators. The Internet Corporation for Assigned Names and
Numbers (ICANN) has an active program to delegate a large number of new
generic top-level domains. EPP will be used to provision those domains,
and new registry operators are expected to develop additional protocol
extensions. With no way to coordinate the development of these
extensions, the problem of non-standard extension duplication by multiple
operators is only expected to become worse.

The goal of the EPP Extensions (eppext) working group is to create an
IANA registry of EPP extensions and to review specifications of
extensions for inclusion in the registry. It will accomplish this goal in
two steps:

1. Develop a specification for a registry of and corresponding
registration procedures for EPP extensions. One proposal is documented in
https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.

2. Produce a small number of extensions based on existing Internet Draft
documents and use the IANA registration process as developed in 1 to
register those extensions, as follows:

DNSSEC key relay: draft-gieben-epp-keyrelay
(http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)

Internationalized domain names: draft-obispo-epp-idn
(http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)

New TLD launch phases: draft-tan-epp-launchphase
(http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)

Trademark Clearinghouse: draft-lozano-tmch-smd
(https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)

Note: draft-tan-epp-launchphase has a normative dependency on
draft-lozano-tmch-smd.

Only the development of the registration process and the
publication/registration of the four extensions noted above are in scope
for the working group. The working group can choose not to publish or
register one or more of the extensions noted above, but it is out of
scope to work on other extensions.


Milestones:
  May 2014 - Extensions registry document to IESG
  Jul 2014 - DNSSEC key relay extension to IESG
  Jul 2014 - New TLD launch phases extension to IESG
  Sep 2014 - Internationalized domain names extension to IESG


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

--_000_831693C2CDA2E849A7D7A712B24E257F492EDFFABRN1WNEXMBX01vc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Don’t be surprised if there is no me=
eting scheduled for London. Meetings are used to sort out challenging issue=
s in real time. If there are no challenging issues, there will
 be no meeting – and creation of a registry frankly should not be tha=
t challenging.


On the milestone: we already have one docu=
ment that describes a proposal for the registry. The WG will have to decide=
 to accept it or not, but IMHO there aren’t too many ways
 to do this and the existing document can be changed to address any deficie=
ncies. It really shouldn’t take all that long!


This comment* from Barry Leiba of the IESG=
 provides an interesting counter to the comment made below: “Only com=
ment: the proposed milestone for the registry doc seems sadly
 pessimistic.  Why should the registry take so long to define?”.=





Scott


 


* https://datatracker.ietf.org/doc/charter-ietf=
-eppext/ballot/


 










From: Jiankang Yao [mailto:yaojk@cnnic.cn]


Sent: Sunday, November 24, 2013 9:45 PM

To: Hollenbeck, Scott; provreg@ietf.org

Subject: Re: [provreg] FW: WG Review: Extensible Provisioning Protoc=
ol Extensions (eppext)






 




Great!






it is a big step to move to a WG.






So we have a WG meeting in London meeting, March, 2014.






 






The goal is to have "May 2014 - Extensi=
ons registry document to IESG "






 






It is a little ambious.






 












Jiankang Yao






 











From: Hollenbeck, Scott<=
/span>







Date: 20=
13-11-23 01:20








Subject: =
;[provreg] FW: WG Review: Extensible Provisioning Protocol Extensions (eppe=
xt)












Yay!






 






Scott






 






-----Original Message-----






From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On&nb=
sp;Behalf Of The IESG






Sent: Friday, November 22, 2013 12=
:18 PM






To: IETF-Announce






Cc: eppext WG






Subject: WG Review: Extensible Provisio=
ning Protocol Extensions (eppext)






 






A new IETF working group has =
been proposed in the Applications Area. The






IESG has not made any determinatio=
n yet. The following draft charter was






submitted, and is provided for inf=
ormational purposes only. Please send=







your comments to the IESG mailing&=
nbsp;list (iesg at ietf.org) by 2013-12-02.






 






Extensible Provisioning Protocol Extensions&=
nbsp;(eppext)






------------------------------------------------=







Current Status: Proposed WG






 






Assigned Area Director:






  Pete Resnick <presnick@qti.qualcomm.com>






 






Charter:






 






The Extensible Provisioning Protocol (E=
PP) was a work product of the IETF<=
/o:p>






Provisioning Registry Protocol (provreg)&nbs=
p;working group. EPP was published





as a Proposed Standard (RFCs 3730,=
 3731, 3732, 3733, and 3734) in March






2004. It became a Draft Standard&n=
bsp;(RFCs 4930, 4931, 4932, 4933, and 4934)






in May 2007, and a Standard (=
Standard 69; RFCs 5730, 5731, 5732, 5733,






and 5734) in August 2009. It =
is the standard domain name provisioning






protocol for generic top-level domain&n=
bsp;name registries that operate under






the auspices of the Internet Corpo=
ration for Assigned Names and Numbers






(ICANN). It is also used by a=
 number of country code top-level domain=







registries.






 






Domain name registries implement a =
;variety of business models. The






difference in these models made it=
 very difficult to come up with a &=
quot;one






size fits all" provisioning protoc=
ol, so the provreg working group made a<=
o:p>






conscious decision to focus on a&n=
bsp;minimal set of common functionality. EPP<=
/o:p>






was designed to be extensible to&n=
bsp;allow additional features to be





specified on an "as needed"&n=
bsp;basis. Guidelines for extending EPP were<=
/o:p>






published as Informational RFC 3735&nbs=
p;in March 2004.






 






The provreg working group was char=
tered to develop EPP, but not these






additional extensions. The working grou=
p was closed in 2004 after






producing a number of Proposed Sta=
ndard specifications. As registries






began to implement and deploy EPP&=
nbsp;the need for extensions became real,






and the user community found itsel=
f facing a situation in which multiple






extensions were being developed by =
;different registries to solve the same=







basic problems, such as registering&nbs=
p;additional contact information.






 






EPP is widely implemented by gener=
ic top-level domain name registry






operators. It is also used by =
;multiple country-code top-level domain name=







registry operators. The Internet Corpor=
ation for Assigned Names and






Numbers (ICANN) has an active prog=
ram to delegate a large number of new






generic top-level domains. EPP will&nbs=
p;be used to provision those domains,






and new registry operators are exp=
ected to develop additional protocol<=
/p>





extensions. With no way to coordin=
ate the development of these






extensions, the problem of non-standard=
 extension duplication by multiple





operators is only expected to beco=
me worse.






 






The goal of the EPP Extensions&nbs=
p;(eppext) working group is to create an=







IANA registry of EPP extensions an=
d to review specifications of






extensions for inclusion in the re=
gistry. It will accomplish this goal in<=
/o:p>






two steps:






 






1. Develop a specification for a&n=
bsp;registry of and corresponding






registration procedures for EPP extensi=
ons. One proposal is documented in







 






2. Produce a small number of =
extensions based on existing Internet Draft






documents and use the IANA registr=
ation process as developed in 1 to=







register those extensions, as follows:<=
o:p>






 






DNSSEC key relay: draft-gieben-epp-keyrelay<=
o:p>







 






Internationalized domain names: draft-obispo=
-epp-idn







 






New TLD launch phases: draft-tan-epp-la=
unchphase







 






Trademark Clearinghouse: draft-lozano-tmch-smd







 






Note: draft-tan-epp-launchphase has a n=
ormative dependency on






draft-lozano-tmch-smd.






 






Only the development of the regist=
ration process and the






publication/registration of the four ex=
tensions noted above are in scope






for the working group. The working=
 group can choose not to publish or=







register one or more of the e=
xtensions noted above, but it is out of<=
o:p>






scope to work on other extensions.=







 






 






Milestones:






  May 2014 - Extensions regis=
try document to IESG  






  Jul 2014 - DNSSEC key =
relay extension to IESG






  Jul 2014 - New TLD lau=
nch phases extension to IESG






  Sep 2014 - Internationalized&nbs=
p;domain names extension to IESG






 






 






_______________________________________________<=
/span>






provreg mailing list














--_000_831693C2CDA2E849A7D7A712B24E257F492EDFFABRN1WNEXMBX01vc_--