From mcanix@gmail.com Tue Dec 3 21:13:19 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 035A91AE085 for ; Tue, 3 Dec 2013 21:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 tFUis2kq6yza for ; Tue, 3 Dec 2013 21:13:17 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 601B31ADF86 for ; Tue, 3 Dec 2013 21:13:17 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so14716084wes.15 for ; Tue, 03 Dec 2013 21:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=FXnAWDjOMZZCeS8p8e1g267BzUZBlHKsx5xl5mDFaMI=; b=zFFPPEkcLt6MMgmXIMDi7QiYtEai8ehyQ0hlPTTKNTBQdHWwvSVpmvvowFS1nudpAv SouMqBpz0XQ0OodL7XeN7DL6R8QESt+qH6d2PSe57WsFUuu6UTN2KUUR5wqitp048CA8 LBjRCPdiCu5/jyiQ0OUw/BEd8IxYv31dmYd1G8OXwMe7Gtq8OvXBo84jIRznVAIZ8wB8 TBTCLMnbfXiJeJjo9qJ2LaihTQmZ8+N5y+rX5RNCQu921wEIHacrIM9sxc/++9ePiGzF 3KfVXKQvIQmtFNTB2cVFx2es6rywSEh/kYEkMeqIhfzWIkLiLj+pTLkfmEmxkBtXll7K qWaQ== X-Received: by 10.194.119.106 with SMTP id kt10mr5384189wjb.72.1386133994088; Tue, 03 Dec 2013 21:13:14 -0800 (PST) Received: from nakal.int.coza.net.za ([206.223.136.247]) by mx.google.com with ESMTPSA id uc18sm3350407wib.11.2013.12.03.21.13.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 21:13:13 -0800 (PST) From: Mike O'Connell Content-Type: multipart/alternative; boundary="Apple-Mail=_DE30D4A4-20A8-48A4-B437-B1FA3529211E" Message-Id: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> Date: Wed, 4 Dec 2013 07:13:10 +0200 To: "provreg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [provreg] EPP Domain Contacts 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: Wed, 04 Dec 2013 05:13:19 -0000 --Apple-Mail=_DE30D4A4-20A8-48A4-B437-B1FA3529211E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I came across an issue the other day around Domain Contacts, = specifically, the domain contact element contains an optional attribute = 'type' which can be one of [tech, billing, admin]. The problem here is = that the attribute is optional with no assumed default.=20 Does anybody use the domain contact element without the 'type' = attribute?=20 Does anybody use a default value for the 'type' attribute when it is not = provided? Apologies if this is a old/duplicate topic. Regards, Mike -- If you don't know where you are going, any road will get you there. --Apple-Mail=_DE30D4A4-20A8-48A4-B437-B1FA3529211E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii All,

I came across an issue the other day around Domain Contacts, specifically, the domain contact element contains an optional attribute 'type' which can be one of [tech, billing, admin]. The problem here is that the attribute is optional with no assumed default. 

  1. Does anybody use the domain contact element without the 'type' attribute? 
  2. Does anybody use a default value for the 'type' attribute when it is not provided?

Apologies if this is a old/duplicate topic.

Regards,

Mike

--

If you don't know where you are going, any road will get you there.

--Apple-Mail=_DE30D4A4-20A8-48A4-B437-B1FA3529211E-- From cgoldfeder@google.com Tue Dec 3 21:26: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 20DED1ADFD3 for ; Tue, 3 Dec 2013 21:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFtMbxGlrGqP for ; Tue, 3 Dec 2013 21:26:36 -0800 (PST) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0E11ADF88 for ; Tue, 3 Dec 2013 21:26:36 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id mx12so6361804bkb.20 for ; Tue, 03 Dec 2013 21:26: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:from:date:message-id:subject:to :cc:content-type; bh=3Zq0Ldka552nXR8Djdmoz04pJya9hC9uE8vLNCgCi5o=; b=dAP7ZR8yoNsfCLjRJqt0s1UPiyP+27Ba8GNxPneNVP8QUkgeR6EZ5wkx4cxco3quG+ Q2+1sp7c6VTacF5dSVZocdn5rA2biDDoaILri2LIh3ChfhCiIgeWtTSOK01ULetRlq28 jmeqvsx1xOcc0bGLPQRt2DKHS5h2lpKbrH61EyZaDmQ/5+mqom6Mnr2vlwAhSxM4hxdl VmdDo87EmkBjAJqk1F53cDvvZpnqIuILVxR9FmtHhowohDxzdeCvlpkMLOAk8fEoI/UP opu48o74obl8sSnodFh854xQrKERUx8ylATHBhNuDeQ5DwXfuead+Zen7/fsljulCGoz 3/lA== 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:from:date :message-id:subject:to:cc:content-type; bh=3Zq0Ldka552nXR8Djdmoz04pJya9hC9uE8vLNCgCi5o=; b=N78PVsPjeqSNRxjlau0qIEPfjLLxh2rimh2JbRXyJNkZtQpjHTXwEVXou0sb4Aem4h PNiptjodwzoWjUJKRrYMSOL5SXJruwy1SIbKg1Xw+nDC23U7BpS/qyQ5u3swuXv+74Tf Y8O5NvrbtIEeSHfgPVOR2WvWPLHymBQ+ZXOw9/d8e5hePIQzTFh8CX5ZKdmVYN3Jo3LF 364+lh+mGr9sxKVqkY7ajHMVCzZNDUvSZq+SzFwgheGDx8DT22nGWxkKDIF9IAvqK1gG CvVYtLos7y/p7+so8KBnaNPB1Ux4LlZDvdYXDY4f91hsUXV4ucLQCxi7Mr3GE5jpBsxP WFzQ== X-Gm-Message-State: ALoCoQkCtf0iM8UtJibR8xIfvGwNv1JOtyd1/b6vmWOJHsHNM4o+k/2hZSlUzyy69okuXS72XnfJTpwwuiU/2iEJFFYdVcP+R5+lR2rHDsF7XH6K0c2hRQVTzJHyXobj7jeWGGZ3XZy+OJTmGkDwjnOqClhDALIpp1SJp3oI3kl6sKFmo5/W2FceW+Bh9U0lbGC1/xrR1tpS X-Received: by 10.204.227.14 with SMTP id iy14mr18707bkb.161.1386134792720; Tue, 03 Dec 2013 21:26:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.205.11.6 with HTTP; Tue, 3 Dec 2013 21:26:12 -0800 (PST) In-Reply-To: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> References: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> From: Corey Goldfeder Date: Tue, 3 Dec 2013 21:26:12 -0800 Message-ID: To: "Mike O'Connell" Content-Type: multipart/alternative; boundary=485b3970d1eeeede3b04ecaea76f Cc: "provreg@ietf.org" Subject: Re: [provreg] EPP Domain Contacts 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: Wed, 04 Dec 2013 05:26:38 -0000 --485b3970d1eeeede3b04ecaea76f Content-Type: text/plain; charset=ISO-8859-1 We at Charleston Road Registry return a 2306 for contacts without type. (In other words, we enforce type as a required attribute by policy rather than by schema). On Tue, Dec 3, 2013 at 9:13 PM, Mike O'Connell wrote: > All, > > I came across an issue the other day around Domain Contacts, specifically, > the domain contact element contains an optional attribute 'type' which can > be one of [tech, billing, admin]. The problem here is that the attribute is > optional with no assumed default. > > > 1. Does anybody use the domain contact element without the 'type' > attribute? > 2. Does anybody use a default value for the 'type' attribute when it > is not provided? > > > Apologies if this is a old/duplicate topic. > > Regards, > > Mike > > -- > > If you don't know where you are going, any road will get you there. > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > --485b3970d1eeeede3b04ecaea76f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We at Charleston Road Registry return a 2306 for contacts = without type. (In other words, we enforce type as a required attribute by p= olicy rather than by schema).


On Tue, Dec 3, 2013 at 9:13 PM, Mike O'Connell <mcanix@gmail.com>= ; wrote:
All,

I came across a= n issue the other day around Domain Contacts, specifically, the domain cont= act element contains an optional attribute 'type' which can be one = of [tech, billing, admin]. The problem here is that the attribute is option= al with no assumed default.=A0

  1. Does anybody use the domain contact element wit= hout the 'type' attribute?=A0
  2. Does anybody use a default va= lue for the 'type' attribute when it is not provided?

Apologies if this is a old/duplicate topic.

Regards,

Mike

--

If you don't know where you are going, any road will = get you there.


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


--485b3970d1eeeede3b04ecaea76f-- From mcanix@gmail.com Tue Dec 3 22:36:08 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 8B6EA1ADEBB for ; Tue, 3 Dec 2013 22:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QI202nnr32JG for ; Tue, 3 Dec 2013 22:36:06 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 835481AE04D for ; Tue, 3 Dec 2013 22:36:06 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id cc10so7655715wib.16 for ; Tue, 03 Dec 2013 22:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JD0kruub6MJ6mrsW8E8Er8Fyl1+A+2ID60Uyx8LUnXg=; b=YakWLMkrZ4QGHLGkzAGeqpS0oH+iUWJqCQcC+SkYAKsB1ni1Yfx2VQWM7s+vr+cwaS SAVv+Wg0vWiuv6ab8EETCnUrcIjF5mQEQGNyNvBTBRgv2IVnsAr6byS06XdVUvxaBqe0 +SjDZEsXPQyBlDoDpHVC9ldfoq1CSXohY1Uc9fSoMm3S/K1+EX73KkCNQuNde8PIG+We Ks5QVhlZecrg5iO3GwAB0Mzy7Tsn4XSRAV87JcngxWGvHMyq+3NYTzLNHDEfaeN/Z0Lo I7fIjLgQTOlbx/iMqj6NMzNy8dM9K/RxMRWLvOWxOfDGrHnL9E7CP5iVeSPh5z9cmXLI vxzA== X-Received: by 10.195.13.45 with SMTP id ev13mr61253882wjd.20.1386138963077; Tue, 03 Dec 2013 22:36:03 -0800 (PST) Received: from nakal.int.coza.net.za ([206.223.136.247]) by mx.google.com with ESMTPSA id w1sm3911479wib.6.2013.12.03.22.36.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 22:36:02 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F9B51B0-CA39-4B2F-ACFB-197A19B74461" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mike O'Connell In-Reply-To: Date: Wed, 4 Dec 2013 08:35:57 +0200 Message-Id: <10A78711-E15A-4246-ADDE-F812EB12DA72@gmail.com> References: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> To: Corey Goldfeder X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] EPP Domain Contacts 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: Wed, 04 Dec 2013 06:36:08 -0000 --Apple-Mail=_2F9B51B0-CA39-4B2F-ACFB-197A19B74461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 04 Dec 2013, at 7:26 AM, Corey Goldfeder = wrote: > We at Charleston Road Registry return a 2306 for contacts without = type. (In other words, we enforce type as a required attribute by policy = rather than by schema). Agreed - I've put a policy check in place to prevent it. I just wonder = if the spec should be slightly clearer about the type usage.=20 > On Tue, Dec 3, 2013 at 9:13 PM, Mike O'Connell = wrote: > All, >=20 > I came across an issue the other day around Domain Contacts, = specifically, the domain contact element contains an optional attribute = 'type' which can be one of [tech, billing, admin]. The problem here is = that the attribute is optional with no assumed default.=20 >=20 > Does anybody use the domain contact element without the 'type' = attribute?=20 > Does anybody use a default value for the 'type' attribute when it is = not provided? >=20 > Apologies if this is a old/duplicate topic. >=20 > Regards, >=20 > Mike >=20 > -- >=20 > If you don't know where you are going, any road will get you there. >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 --Apple-Mail=_2F9B51B0-CA39-4B2F-ACFB-197A19B74461 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 04 Dec 2013, at 7:26 AM, Corey Goldfeder <cgoldfeder@google.com> wrote:

We at Charleston Road Registry return a 2306 for contacts without type. (In other words, we enforce type as a required attribute by policy rather than by schema).

Agreed - I've put a policy check in place to prevent it. I just wonder if the spec should be slightly clearer about the type usage. 


On Tue, Dec 3, 2013 at 9:13 PM, Mike O'Connell <mcanix@gmail.com> wrote:
All,

I came across an issue the other day around Domain Contacts, specifically, the domain contact element contains an optional attribute 'type' which can be one of [tech, billing, admin]. The problem here is that the attribute is optional with no assumed default. 

  1. Does anybody use the domain contact element without the 'type' attribute? 
  2. Does anybody use a default value for the 'type' attribute when it is not provided?

Apologies if this is a old/duplicate topic.

Regards,

Mike

--

If you don't know where you are going, any road will get you there.


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



--Apple-Mail=_2F9B51B0-CA39-4B2F-ACFB-197A19B74461-- From alexander.mayrhofer@nic.at Tue Dec 3 23:55:18 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 7B8301AE070 for ; Tue, 3 Dec 2013 23:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.731 X-Spam-Level: X-Spam-Status: No, score=-5.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 oFfPPL2NesVs for ; Tue, 3 Dec 2013 23:55:16 -0800 (PST) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 867071AE03C for ; Tue, 3 Dec 2013 23:55:14 -0800 (PST) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Wed, 4 Dec 2013 08:55:11 +0100 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 08:55:08 +0100 From: Alexander Mayrhofer To: Mike O'Connell , "provreg@ietf.org" Thread-Topic: [provreg] EPP Domain Contacts Thread-Index: AQHO8K+SVURXwgYRaU+hIJnaX0G7o5pDqqdg Date: Wed, 4 Dec 2013 07:55:06 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750A3C7274@NICS-EXCH2.sbg.nic.at> References: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> In-Reply-To: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE0750A3C7274NICSEXCH2sbgnic_" MIME-Version: 1.0 X-XWALL-BCKS: auto Subject: Re: [provreg] EPP Domain Contacts 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: Wed, 04 Dec 2013 07:55:18 -0000 --_000_19F54F2956911544A32543B8A9BDE0750A3C7274NICSEXCH2sbgnic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the gTLD configuration of our Registry, we do require the contact type t= o be either "tech" or "admin". We don't allow for "billing" type contacts,= since any billing goes via the registrar. Alex Von: provreg [mailto:provreg-bounces@ietf.org] Im Auftrag von Mike O'Connel= l Gesendet: Mittwoch, 04. Dezember 2013 06:13 An: provreg@ietf.org Betreff: [provreg] EPP Domain Contacts All, I came across an issue the other day around Domain Contacts, specifically, = the domain contact element contains an optional attribute 'type' which can = be one of [tech, billing, admin]. The problem here is that the attribute is= optional with no assumed default. 1. Does anybody use the domain contact element without the 'type' attrib= ute? 2. Does anybody use a default value for the 'type' attribute when it is = not provided? Apologies if this is a old/duplicate topic. Regards, Mike -- If you don't know where you are going, any road will get you there. --_000_19F54F2956911544A32543B8A9BDE0750A3C7274NICSEXCH2sbgnic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the gTL= D configuration of our Registry, we do require the contact type to be eithe= r  „tech“ or „admin“. We don’t allow for= “billing” type contacts, since any billing goes via the registrar.

 = ;

Alex<= /o:p>

 = ;

 = ;

Von: provreg [mailto:provreg-bounces@ietf.org] Im Auftrag von Mike O'Connell
Gesendet: Mittwoch, 04. Dezember 2013 06:13
An: provreg@ietf.org
Betreff: [provreg] EPP Domain Contacts

 

All,

 

I came across an issue the other day around Domain C= ontacts, specifically, the domain contact element contains an optional attr= ibute 'type' which can be one of [tech, billing, admin]. The problem here i= s that the attribute is optional with no assumed default. 

 

  1. Does anybody use the domain contact element without the 'type' attribute?&n= bsp;
  2. Does anybody use a default value for the 'type' attribute when it is not pr= ovided?

 

Apologies if this is a old/duplicate topic.

 

Regards,

 

Mike

 

--

 

If you don't know where you are going, any road will= get you there.

 

--_000_19F54F2956911544A32543B8A9BDE0750A3C7274NICSEXCH2sbgnic_-- From paf@frobbit.se Wed Dec 4 00:31:33 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 29F6F1AE090 for ; Wed, 4 Dec 2013 00:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxrsobfVrGMN for ; Wed, 4 Dec 2013 00:31:32 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ietfa.amsl.com (Postfix) with ESMTP id CE87E1AE086 for ; Wed, 4 Dec 2013 00:31:31 -0800 (PST) Received: from [IPv6:2a01:3f0:1::e44c:669d:5d21:7aba] (unknown [IPv6:2a01:3f0:1:0:e44c:669d:5d21:7aba]) by mail.frobbit.se (Postfix) with ESMTPSA id 9CE8B2278D; Wed, 4 Dec 2013 09:31:27 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_A5347BB8-6B46-4D9B-ADC8-C7C6E83B3500"; 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: <19F54F2956911544A32543B8A9BDE0750A3C7274@NICS-EXCH2.sbg.nic.at> Date: Wed, 4 Dec 2013 09:31:26 +0100 Message-Id: <9EE951A3-EB14-48A9-AC17-DFC73A1FD63F@frobbit.se> References: <07F9FB60-1BAE-4AB9-A6DC-5BA2F3283096@gmail.com> <19F54F2956911544A32543B8A9BDE0750A3C7274@NICS-EXCH2.sbg.nic.at> To: Alexander Mayrhofer X-Mailer: Apple Mail (2.1822) Cc: "provreg@ietf.org" Subject: Re: [provreg] EPP Domain Contacts 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: Wed, 04 Dec 2013 08:31:33 -0000 --Apple-Mail=_A5347BB8-6B46-4D9B-ADC8-C7C6E83B3500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Without saying it being good or bad, as Frobbit that I work with is not = a registrar to .AT, in general as a registrar I would like to be able to = register billing contact as well (or rather, I would like to be able to = fetch billing info). The downside with your policy is that if the domain = is transferred from one registrar to another, the information on billing = info must be moved out of band of the actual transfer (that is via the = registry). Patrik On 4 dec 2013, at 08:55, Alexander Mayrhofer = wrote: > In the gTLD configuration of our Registry, we do require the contact = type to be either =84tech=93 or =84admin=93. We don=92t allow for = =93billing=94 type contacts, since any billing goes via the registrar. > =20 > Alex > =20 > =20 > Von: provreg [mailto:provreg-bounces@ietf.org] Im Auftrag von Mike = O'Connell > Gesendet: Mittwoch, 04. Dezember 2013 06:13 > An: provreg@ietf.org > Betreff: [provreg] EPP Domain Contacts > =20 > All, > =20 > I came across an issue the other day around Domain Contacts, = specifically, the domain contact element contains an optional attribute = 'type' which can be one of [tech, billing, admin]. The problem here is = that the attribute is optional with no assumed default.=20 > =20 > =95 Does anybody use the domain contact element without the = 'type' attribute?=20 > =95 Does anybody use a default value for the 'type' attribute = when it is not provided? > =20 > Apologies if this is a old/duplicate topic. > =20 > Regards, > =20 > Mike > =20 > -- > =20 > If you don't know where you are going, any road will get you there. > =20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --Apple-Mail=_A5347BB8-6B46-4D9B-ADC8-C7C6E83B3500 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 iD8DBQFSnuherMabGguI180RAvYSAJ0USaFJTNbC91JLHsz8ZPXjuK/uIQCcCjdk qT2kkGS+GF0CYsSNHbvaIoI= =e7zc -----END PGP SIGNATURE----- --Apple-Mail=_A5347BB8-6B46-4D9B-ADC8-C7C6E83B3500-- From gavin.brown@centralnic.com Mon Dec 9 10:18:21 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 DF7851AE40D for ; Mon, 9 Dec 2013 10:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 2QCW69Sp-3nK for ; Mon, 9 Dec 2013 10:18:19 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 93D211AE055 for ; Mon, 9 Dec 2013 10:18:19 -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 AA9C97206BD for ; Mon, 9 Dec 2013 18:18:13 +0000 (UTC) Message-ID: <52A60965.9000408@centralnic.com> Date: Mon, 09 Dec 2013 18:18: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.1 MIME-Version: 1.0 To: provreg@ietf.org References: <20131209175847.18411.83677.idtracker@ietfa.amsl.com> In-Reply-To: <20131209175847.18411.83677.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131209175847.18411.83677.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-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:18:22 -0000 Changes since the last version: 1. Restore the command extension; either or can be used. 2. added extension elements for , , and so that the server can reject the command if the fee is incorrect. G. -------- Original Message -------- Subject: New Version Notification for draft-brown-epp-fees-01.txt Date: Mon, 09 Dec 2013 09:58:47 -0800 From: internet-drafts@ietf.org To: Gavin Brown A new version of I-D, draft-brown-epp-fees-01.txt has been successfully submitted by Gavin Brown and posted to the IETF repository. Filename: draft-brown-epp-fees Revision: 01 Title: Registry Fee Extension for the Extensible Provisioning Protocol (EPP) Creation date: 2013-12-09 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-brown-epp-fees-01.txt Status: http://datatracker.ietf.org/doc/draft-brown-epp-fees Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-01 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 presnick@qti.qualcomm.com Thu Dec 12 15:38:13 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 0FBBF1AE0B5 for ; Thu, 12 Dec 2013 15:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 FP_lZEybXHFD for ; Thu, 12 Dec 2013 15:38:09 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 08EFD1AE551 for ; Thu, 12 Dec 2013 15:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1386891483; x=1418427483; h=message-id:date:from:mime-version:to:subject; bh=o+2/PaLkIiFye/ReP4FUoqP8Zx+7eZnpti7cLXUDupw=; b=AcktziUpAB5AuqPcM7nSAh2bq3eekJmOQY5WjdzJre7k26iMfF9YtOX6 rJqJ5G2oUmOIrdzPRcIebNf/ckOTpNTIjJAm0Xn94iRZskfZB5b8Z430m eRWn/1TDh6wawyNxfTEfiSMtPzx8j7/w4ICHpmFysxHlNgxaHS+3jpI0g Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7287"; a="56521537" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 12 Dec 2013 15:38:02 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7287"; a="24285006" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Dec 2013 15:38:02 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 15:38:02 -0800 Message-ID: <52AA48D7.30303@qti.qualcomm.com> Date: Thu, 12 Dec 2013 17:37:59 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------010005000201090106010701" X-Originating-IP: [172.30.39.5] Subject: [provreg] Fwd: WG Action: Formed 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: Thu, 12 Dec 2013 23:38:13 -0000 --------------010005000201090106010701 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: WG Action: Formed Extensible Provisioning Protocol Extensions (eppext) Resent-From: Date: Thu, 12 Dec 2013 15:24:52 -0800 From: The IESG Reply-To: To: IETF-Announce CC: eppext WG A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Extensible Provisioning Protocol Extensions (eppext) ------------------------------------------------ Current Status: Proposed WG Chairs: James Galvin Antoin Verschuren Assigned Area Director: Pete Resnick Mailing list Address: eppext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eppext Archive: http://www.ietf.org/mail-archive/web/eppext/ 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 --------------010005000201090106010701 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: WG Action: Formed Extensible Provisioning Protocol Extensions (eppext)
Resent-From: <presnick@qti.qualcomm.com>
Date: Thu, 12 Dec 2013 15:24:52 -0800
From: The IESG <iesg-secretary@ietf.org>
Reply-To: <ietf@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: eppext WG <eppext@ietf.org>


A new IETF working group has been formed in the Applications Area. For
additional information please contact the Area Directors or the WG
Chairs.

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

Chairs:
  James Galvin <jgalvin@afilias.info>
  Antoin Verschuren <antoin.verschuren@sidn.nl>

Assigned Area Director:
  Pete Resnick <presnick@qti.qualcomm.com>

Mailing list
  Address: eppext@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/eppext
  Archive: http://www.ietf.org/mail-archive/web/eppext/

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


--------------010005000201090106010701-- From shollenbeck@verisign.com Thu Dec 12 18:55:41 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 20C671AE5EB for ; Thu, 12 Dec 2013 18:55:41 -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 47dLvNLJ5oOW for ; Thu, 12 Dec 2013 18:55:37 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 83C371AE029 for ; Thu, 12 Dec 2013 18:55:36 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUqp3Ig2ESohM/7ssVzDUVR0HRhLyK9cY@postini.com; Thu, 12 Dec 2013 18:55:31 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 rBD2tTdD018110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 21:55:29 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 12 Dec 2013 21:55:29 -0500 From: "Hollenbeck, Scott" To: Pete Resnick Thread-Topic: [provreg] Fwd: WG Action: Formed Extensible Provisioning Protocol Extensions (eppext) Thread-Index: AQHO95M5NmO7uj0xZEuSBdWc6uXtFZpRbmiq Date: Fri, 13 Dec 2013 02:55:28 +0000 Message-ID: <0B3E737A-3402-40A6-9AD8-38A8A6878B29@verisign.com> References: <52AA48D7.30303@qti.qualcomm.com> In-Reply-To: <52AA48D7.30303@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0B3E737A340240A69AD838A8A6878B29verisigncom_" MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Fwd: WG Action: Formed 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, 13 Dec 2013 02:55:41 -0000 --_000_0B3E737A340240A69AD838A8A6878B29verisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Pete! Scott On Dec 12, 2013, at 6:38 PM, "Pete Resnick" > wrote: -------- Original Message -------- Subject: WG Action: Formed Extensible Provisioning Protocol Extensio= ns (eppext) Resent-From: Date: Thu, 12 Dec 2013 15:24:52 -0800 From: The IESG Reply-To: To: IETF-Announce CC: eppext WG A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. Extensible Provisioning Protocol Extensions (eppext) ------------------------------------------------ Current Status: Proposed WG Chairs: James Galvin Antoin Verschuren Assigned Area Director: Pete Resnick Mailing list Address: eppext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eppext Archive: http://www.ietf.org/mail-archive/web/eppext/ 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_0B3E737A340240A69AD838A8A6878B29verisigncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks, Pete!

Scott

On Dec 12, 2013, at 6:38 PM, "Pete Resnick" <presnick@qti.qualcomm.com> wrote:



-------- Original Message --------
Subject: WG Action: Formed Extensible Provisioning Protocol Extensions (eppext)<= /td>
Resent-From: <presnick@qti.qualcomm.com>
Date: Thu, 12 Dec 2013 15:24:52 -0800
From: The IESG <iesg-secretary@ietf.org>
Reply-To: <ie= tf@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: eppext WG <eppext@ietf.org>


A new IETF working group has been formed in the Applications Area. For
additional information please contact the Area Directors or the WG
Chairs.

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

Chairs:
  James Galvin <jgalvin@afilias.info>
  Antoin Verschuren <antoin.verschuren@sidn.nl>

Assigned Area Director:
  Pete Resnick <presnick@qti.qualcomm.com>

Mailing list
  Address: eppext@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/eppext<=
/a>
  Archive: http://www.ietf.org/mail-archive/web/eppext/

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 "o=
ne
size fits all" provisioning protocol, so the provreg working group mad=
e 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 w=
ere
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-holl=
enbeck-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-e=
pp-keyrelay/)

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

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-tmc=
h-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


_______________________________________________
provreg mailing list
provreg@ietf.org
https://www= .ietf.org/mailman/listinfo/provreg
--_000_0B3E737A340240A69AD838A8A6878B29verisigncom_-- From bruno.premont@restena.lu Thu Dec 19 00:16:42 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 31E971AE295 for ; Thu, 19 Dec 2013 00:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] 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 XegTe_tDZqvo for ; Thu, 19 Dec 2013 00:16:37 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 496691AE1EC for ; Thu, 19 Dec 2013 00:16:37 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id ABAC810580; Thu, 19 Dec 2013 09:16:34 +0100 (CET) Received: from pluto.restena.lu (pluto.restena.lu [IPv6:2001:a18:1:8::156]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8D83F1057E; Thu, 19 Dec 2013 09:16:34 +0100 (CET) Date: Thu, 19 Dec 2013 09:16:30 +0100 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= To: Gavin Brown Message-ID: <20131219091630.34e2855a@pluto.restena.lu> In-Reply-To: <52A60965.9000408@centralnic.com> References: <20131209175847.18411.83677.idtracker@ietfa.amsl.com> <52A60965.9000408@centralnic.com> Organization: Fondation RESTENA X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Ps=6.5T7DwuS4zIny5SKAMM"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV Cc: provreg@ietf.org Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 08:16:42 -0000 --Sig_/Ps=6.5T7DwuS4zIny5SKAMM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 09 Dec 2013 18:18:13 +0000 Gavin Brown wrote: > Changes since the last version: >=20 > 1. Restore the command extension; either or > can be used. >=20 > 2. added extension elements for , , and > so that the server can reject the command if the fee is > incorrect. We have some registrars who wish to be able to check their account credit balance via EPP. Would it make sense to include their balance in these fee responses? e.g. ... EUR 5.00 1500.50 ... In addition it might be worth allowing inclusion of information about taxes (VAT within EU). Bruno > G. >=20 > -------- Original Message -------- > Subject: New Version Notification for draft-brown-epp-fees-01.txt > Date: Mon, 09 Dec 2013 09:58:47 -0800 > From: internet-drafts@ietf.org > To: Gavin Brown >=20 >=20 > A new version of I-D, draft-brown-epp-fees-01.txt > has been successfully submitted by Gavin Brown and posted to the > IETF repository. >=20 > Filename: draft-brown-epp-fees > Revision: 01 > Title: Registry Fee Extension for the Extensible Provisioning Protocol > (EPP) > Creation date: 2013-12-09 > Group: Individual Submission > Number of pages: 27 > URL: > http://www.ietf.org/internet-drafts/draft-brown-epp-fees-01.txt > Status: http://datatracker.ietf.org/doc/draft-brown-epp-fees > Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-= 01 >=20 > Abstract: > This document describes an Extensible Provisioning Protocol (EPP) > extension mapping for registry fees. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --=20 Bruno Pr=C3=A9mont Ing=C3=A9nieur syst=C3=A8me et d=C3=A9veloppements Fondation RESTENA 6, rue Coudenhove-Kalergi L-1359 Luxembourg T=C3=A9l: (+352) 424409 Fax: (+352) 422473 http://www.restena.lu http://www.dns.lu --Sig_/Ps=6.5T7DwuS4zIny5SKAMM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKyq2IACgkQc2cOy4nMX1YyTACfYoB3EhLKLX7BaCwSqH4SIC8h Er0An1eK1eG9TygeJCZRrROlYmOpRAar =Qdpr -----END PGP SIGNATURE----- --Sig_/Ps=6.5T7DwuS4zIny5SKAMM-- From gavin.brown@centralnic.com Thu Dec 19 01:37:12 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 DB68A1AE2AD for ; Thu, 19 Dec 2013 01:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, 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 AiEEXJvzxYfQ for ; Thu, 19 Dec 2013 01:37:10 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5725A1AE265 for ; Thu, 19 Dec 2013 01:37:10 -0800 (PST) Received: from CNIC-MBP-200117.local (unknown [31.68.193.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 271207207AB; Thu, 19 Dec 2013 09:37:06 +0000 (UTC) Message-ID: <52B2BE2F.3070009@centralnic.com> Date: Thu, 19 Dec 2013 09:36:47 +0000 From: Gavin Brown User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: =?UTF-8?B?QnJ1bm8gUHLDqW1vbnQ=?= References: <20131209175847.18411.83677.idtracker@ietfa.amsl.com> <52A60965.9000408@centralnic.com> <20131219091630.34e2855a@pluto.restena.lu> In-Reply-To: <20131219091630.34e2855a@pluto.restena.lu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: provreg@ietf.org Subject: Re: [provreg] Fwd: New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 09:37:13 -0000 Hi Bruno, It may make sense to allow a object in transform command responses - I'll consider this for the next version. However, there are existing extensions for account balance querying. Unfortunately they have not been published as I-Ds yet, but I am working on persuading the authors to do so. G. On 19/12/2013 08:16, Bruno Prémont wrote: > On Mon, 09 Dec 2013 18:18:13 +0000 Gavin Brown wrote: >> Changes since the last version: >> >> 1. Restore the command extension; either or >> can be used. >> >> 2. added extension elements for , , and >> so that the server can reject the command if the fee is >> incorrect. > > We have some registrars who wish to be able to check their account > credit balance via EPP. > Would it make sense to include their balance in these fee responses? > > e.g. ... > EUR > 5.00 > 1500.50 > ... > > In addition it might be worth allowing inclusion of information > about taxes (VAT within EU). > > Bruno > >> G. >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-brown-epp-fees-01.txt >> Date: Mon, 09 Dec 2013 09:58:47 -0800 >> From: internet-drafts@ietf.org >> To: Gavin Brown >> >> >> A new version of I-D, draft-brown-epp-fees-01.txt >> has been successfully submitted by Gavin Brown and posted to the >> IETF repository. >> >> Filename: draft-brown-epp-fees >> Revision: 01 >> Title: Registry Fee Extension for the Extensible Provisioning Protocol >> (EPP) >> Creation date: 2013-12-09 >> Group: Individual Submission >> Number of pages: 27 >> URL: >> http://www.ietf.org/internet-drafts/draft-brown-epp-fees-01.txt >> Status: http://datatracker.ietf.org/doc/draft-brown-epp-fees >> Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-01 >> >> 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 lem@isc.org Thu Dec 19 06:38:26 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 120D01ADF60 for ; Thu, 19 Dec 2013 06:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, 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 Ds10WoqJz7GG for ; Thu, 19 Dec 2013 06:38:24 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B434F1ADF53 for ; Thu, 19 Dec 2013 06:38:24 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 527ABC95AD; Thu, 19 Dec 2013 14:38:13 +0000 (UTC) (envelope-from lem@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1387463903; bh=zTxTKCg/pFJloYJNcaUC7rak87mOPg9HH8X8BMqgOHU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kOvZQ94UPUsSoxcwVXPeem7lOucK6VmdvOtTa/jvRNor8Lf1b/VWqxXocyLCaM0T0 oXAKRvt67EDYcThXxnmE5eAYVmnGTtPiPJzhmsX4c9EgaBp6uRIPaIoDetEVfBYwBU 5ZAM5OxB8aOg3zUs/HudeFExugxIYxXpk3Q5fE6o= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 19 Dec 2013 14:38:13 +0000 (UTC) (envelope-from lem@isc.org) Received: from [192.168.0.129] (z65-50-116-97.ips.direcpath.com [65.50.116.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DD02E216C1E; Thu, 19 Dec 2013 14:38:12 +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: <52B2BE2F.3070009@centralnic.com> Date: Thu, 19 Dec 2013 09:38:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0D754068-9BA3-497C-9038-16A5839E820D@isc.org> References: <20131209175847.18411.83677.idtracker@ietfa.amsl.com> <52A60965.9000408@centralnic.com> <20131219091630.34e2855a@pluto.restena.lu> <52B2BE2F.3070009@centralnic.com> To: Gavin Brown X-Mailer: Apple Mail (2.1283) X-DCC--Metrics: post.isc.org; whitelist Cc: provreg@ietf.org Subject: Re: [provreg] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:38:26 -0000 On Dec 19, 2013, at 4:36 AM, Gavin Brown wrote: > It may make sense to allow a object in transform command > responses - I'll consider this for the next version. This should be optional so that Registries can choose to add that task = to the processing of the transform command or not depending on their = specific implementations. Best regards -lem From gavin.brown@centralnic.com Thu Dec 19 06:45:45 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 A22581ADF7E for ; Thu, 19 Dec 2013 06:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, 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 IMDEaugJLgNh for ; Thu, 19 Dec 2013 06:45:44 -0800 (PST) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id D8B821ADF5B for ; Thu, 19 Dec 2013 06:45:43 -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 897BA72079A; Thu, 19 Dec 2013 14:45:40 +0000 (UTC) Message-ID: <52B30686.2020406@centralnic.com> Date: Thu, 19 Dec 2013 14:45:26 +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.2.0 MIME-Version: 1.0 To: =?UTF-8?B?THVpcyBNdcOxb3o=?= References: <20131209175847.18411.83677.idtracker@ietfa.amsl.com> <52A60965.9000408@centralnic.com> <20131219091630.34e2855a@pluto.restena.lu> <52B2BE2F.3070009@centralnic.com> <0D754068-9BA3-497C-9038-16A5839E820D@isc.org> In-Reply-To: <0D754068-9BA3-497C-9038-16A5839E820D@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] New Version Notification for draft-brown-epp-fees-01.txt X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 14:45:45 -0000 Agreed. On 19/12/2013 14:38, Luis Muñoz wrote: > > On Dec 19, 2013, at 4:36 AM, Gavin Brown wrote: > >> It may make sense to allow a object in transform command >> responses - I'll consider this for the next version. > > This should be optional so that Registries can choose to add that task to the processing of the transform command or not depending on their specific implementations. > > Best regards > > -lem > -- 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.