
From mcanix@gmail.com  Tue Dec  3 21:13:19 2013
Return-Path: <mcanix@gmail.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; Tue,  3 Dec 2013 21:13:17 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id w61so14716084wes.15 for <provreg@ietf.org>; 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 <provreg@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 21:13:13 -0800 (PST)
From: Mike O'Connell <mcanix@gmail.com>
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" <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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">All,<div><br></div><div>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.&nbsp;</div><div><br></div><div><ol class="MailOutline"><li>Does anybody use the domain contact element without the 'type' attribute?&nbsp;</li><li>Does anybody use a default value for the 'type' attribute when it is not provided?</li></ol><div><br></div><div>Apologies if this is a old/duplicate topic.</div><div><br></div><div>Regards,</div><div><br></div><div>Mike</div><div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div>--</div><div><br></div><div>If you don't know where you are going, any road will get you there.</div></span>

</div>
<br></div></body></html>
--Apple-Mail=_DE30D4A4-20A8-48A4-B437-B1FA3529211E--

From cgoldfeder@google.com  Tue Dec  3 21:26:38 2013
Return-Path: <cgoldfeder@google.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; Tue,  3 Dec 2013 21:26:36 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so6361804bkb.20 for <provreg@ietf.org>; 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 <cgoldfeder@google.com>
Date: Tue, 3 Dec 2013 21:26:12 -0800
Message-ID: <CAKbEXbKOC432jajaQxepfzf0bTnKMgm_8SsXj51N9pT3LT4B7Q@mail.gmail.com>
To: "Mike O'Connell" <mcanix@gmail.com>
Content-Type: multipart/alternative; boundary=485b3970d1eeeede3b04ecaea76f
Cc: "provreg@ietf.org" <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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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 <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
>
>

--485b3970d1eeeede3b04ecaea76f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">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).</div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">

On Tue, Dec 3, 2013 at 9:13 PM, Mike O&#39;Connell <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:mcanix@gmail.com" target=3D"_blank">mcanix@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style=3D"word-wrap:break-word">All,<div><br></div><div>I came across a=
n issue the other day around Domain Contacts, specifically, the domain cont=
act element contains an optional attribute &#39;type&#39; which can be one =
of [tech, billing, admin]. The problem here is that the attribute is option=
al with no assumed default.=A0</div>

<div><br></div><div><ol><li>Does anybody use the domain contact element wit=
hout the &#39;type&#39; attribute?=A0</li><li>Does anybody use a default va=
lue for the &#39;type&#39; attribute when it is not provided?</li></ol><div=
>

<br></div><div>Apologies if this is a old/duplicate topic.</div><div><br></=
div><div>Regards,</div><div><br></div><div>Mike</div><div><br></div><div>
<span style=3D"border-collapse:separate;border-spacing:0px"><div>--</div><d=
iv><br></div><div>If you don&#39;t know where you are going, any road will =
get you there.</div></span>

</div>
<br></div></div><br>_______________________________________________<br>
provreg mailing list<br>
<a href=3D"mailto:provreg@ietf.org">provreg@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/provreg" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/provreg</a><br>
<br></blockquote></div><br></div>

--485b3970d1eeeede3b04ecaea76f--

From mcanix@gmail.com  Tue Dec  3 22:36:08 2013
Return-Path: <mcanix@gmail.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; Tue,  3 Dec 2013 22:36:06 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id cc10so7655715wib.16 for <provreg@ietf.org>; 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 <multiple recipients> (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 <mcanix@gmail.com>
In-Reply-To: <CAKbEXbKOC432jajaQxepfzf0bTnKMgm_8SsXj51N9pT3LT4B7Q@mail.gmail.com>
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> <CAKbEXbKOC432jajaQxepfzf0bTnKMgm_8SsXj51N9pT3LT4B7Q@mail.gmail.com>
To: Corey Goldfeder <cgoldfeder@google.com>
X-Mailer: Apple Mail (2.1510)
Cc: "provreg@ietf.org" <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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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 <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.=20


> On Tue, Dec 3, 2013 at 9:13 PM, Mike O'Connell <mcanix@gmail.com> =
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

<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 04 Dec 2013, at 7:26 AM, Corey Goldfeder &lt;<a href="mailto:cgoldfeder@google.com">cgoldfeder@google.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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).</div></blockquote><div><br></div>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.&nbsp;<br><div><br></div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">

On Tue, Dec 3, 2013 at 9:13 PM, Mike O'Connell <span dir="ltr">&lt;<a href="mailto:mcanix@gmail.com" target="_blank">mcanix@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">All,<div><br></div><div>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.&nbsp;</div>

<div><br></div><div><ol><li>Does anybody use the domain contact element without the 'type' attribute?&nbsp;</li><li>Does anybody use a default value for the 'type' attribute when it is not provided?</li></ol><div>

<br></div><div>Apologies if this is a old/duplicate topic.</div><div><br></div><div>Regards,</div><div><br></div><div>Mike</div><div><br></div><div>
<span style="border-collapse:separate;border-spacing:0px"><div>--</div><div><br></div><div>If you don't know where you are going, any road will get you there.</div></span>

</div>
<br></div></div><br>_______________________________________________<br>
provreg mailing list<br>
<a href="mailto:provreg@ietf.org">provreg@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/provreg" target="_blank">https://www.ietf.org/mailman/listinfo/provreg</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></body></html>
--Apple-Mail=_2F9B51B0-CA39-4B2F-ACFB-197A19B74461--

From alexander.mayrhofer@nic.at  Tue Dec  3 23:55:18 2013
Return-Path: <alexander.mayrhofer@nic.at>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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 <alexander.mayrhofer@nic.at>
To: Mike O'Connell <mcanix@gmail.com>, "provreg@ietf.org" <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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.E-MailFormatvorlage18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1546869655;
	mso-list-template-ids:-523700794;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE-AT" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In the gTL=
D configuration of our Registry, we do require the contact type to be eithe=
r &nbsp;&#8222;tech&#8220; or &#8222;admin&#8220;. We don&#8217;t allow for=
 &#8220;billing&#8221; type contacts,
 since any billing goes via the registrar.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Alex<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"DE" style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">Von:</span></b><span lang=
=3D"DE" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans=
-serif&quot;"> provreg [mailto:provreg-bounces@ietf.org]
<b>Im Auftrag von </b>Mike O'Connell<br>
<b>Gesendet:</b> Mittwoch, 04. Dezember 2013 06:13<br>
<b>An:</b> provreg@ietf.org<br>
<b>Betreff:</b> [provreg] EPP Domain Contacts<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">All,<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">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.&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<ol start=3D"1" type=3D"1">
<li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-=
alt:auto;mso-list:l0 level1 lfo1">
Does anybody use the domain contact element without the 'type' attribute?&n=
bsp;<o:p></o:p></li><li class=3D"MsoNormal" style=3D"mso-margin-top-alt:aut=
o;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Does anybody use a default value for the 'type' attribute when it is not pr=
ovided?<o:p></o:p></li></ol>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Apologies if this is a old/duplicate topic.<o:p></o:=
p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Mike<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<div>
<p class=3D"MsoNormal">--<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">If you don't know where you are going, any road will=
 get you there.<o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_19F54F2956911544A32543B8A9BDE0750A3C7274NICSEXCH2sbgnic_--

From paf@frobbit.se  Wed Dec  4 00:31:33 2013
Return-Path: <paf@frobbit.se>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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?= <paf@frobbit.se>
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 <alexander.mayrhofer@nic.at>
X-Mailer: Apple Mail (2.1822)
Cc: "provreg@ietf.org" <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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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 =
<alexander.mayrhofer@nic.at> 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: <gavin.brown@centralnic.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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 <provreg@ietf.org>; 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 <gavin.brown@centralnic.com>
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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 18:18:22 -0000

Changes since the last version:

   1.  Restore the <check> command extension; either <check> or <info>
       can be used.

   2.  added extension elements for <create>, <renew>, <transfer> and
       <update> 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 <gavin.brown@centralnic.com>


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: <presnick@qti.qualcomm.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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 <presnick@qti.qualcomm.com>
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: <provreg@ietf.org>
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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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: 	<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
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
 cellspacing="0">
  <tbody>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
      <td>WG Action: Formed Extensible Provisioning Protocol Extensions
(eppext)</td>
    </tr>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Resent-From: </th>
      <td><a class="moz-txt-link-rfc2396E" href="mailto:presnick@qti.qualcomm.com">&lt;presnick@qti.qualcomm.com&gt;</a></td>
    </tr>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
      <td>Thu, 12 Dec 2013 15:24:52 -0800</td>
    </tr>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
      <td>The IESG <a class="moz-txt-link-rfc2396E" href="mailto:iesg-secretary@ietf.org">&lt;iesg-secretary@ietf.org&gt;</a></td>
    </tr>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Reply-To: </th>
      <td><a class="moz-txt-link-rfc2396E" href="mailto:ietf@ietf.org">&lt;ietf@ietf.org&gt;</a></td>
    </tr>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
      <td>IETF-Announce <a class="moz-txt-link-rfc2396E" href="mailto:ietf-announce@ietf.org">&lt;ietf-announce@ietf.org&gt;</a></td>
    </tr>
    <tr>
      <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
      <td>eppext WG <a class="moz-txt-link-rfc2396E" href="mailto:eppext@ietf.org">&lt;eppext@ietf.org&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>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 <a class="moz-txt-link-rfc2396E" href="mailto:jgalvin@afilias.info">&lt;jgalvin@afilias.info&gt;</a>
  Antoin Verschuren <a class="moz-txt-link-rfc2396E" href="mailto:antoin.verschuren@sidn.nl">&lt;antoin.verschuren@sidn.nl&gt;</a>

Assigned Area Director:
  Pete Resnick <a class="moz-txt-link-rfc2396E" href="mailto:presnick@qti.qualcomm.com">&lt;presnick@qti.qualcomm.com&gt;</a>

Mailing list
  Address: <a class="moz-txt-link-abbreviated" href="mailto:eppext@ietf.org">eppext@ietf.org</a>
  To Subscribe: <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/eppext">https://www.ietf.org/mailman/listinfo/eppext</a>
  Archive: <a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/eppext/">http://www.ietf.org/mail-archive/web/eppext/</a>

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
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/">https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/</a>.

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
(<a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/">http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/</a>)

Internationalized domain names: draft-obispo-epp-idn
(<a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/doc/draft-obispo-epp-idn/">http://datatracker.ietf.org/doc/draft-obispo-epp-idn/</a>)

New TLD launch phases: draft-tan-epp-launchphase
(<a class="moz-txt-link-freetext" href="http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/">http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/</a>)

Trademark Clearinghouse: draft-lozano-tmch-smd
(<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/">https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/</a>)

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


</pre>
</body>
</html>

--------------010005000201090106010701--

From shollenbeck@verisign.com  Thu Dec 12 18:55:41 2013
Return-Path: <shollenbeck@verisign.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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" <shollenbeck@verisign.com>
To: Pete Resnick <presnick@qti.qualcomm.com>
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" <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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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" <presnick@qti.qualcomm.com<mail=
to:presnick@qti.qualcomm.com>> wrote:



-------- Original Message --------
Subject:        WG Action: Formed Extensible Provisioning Protocol Extensio=
ns (eppext)
Resent-From:    <presnick@qti.qualcomm.com><mailto:presnick@qti.qualcomm.co=
m>
Date:   Thu, 12 Dec 2013 15:24:52 -0800
From:   The IESG <iesg-secretary@ietf.org><mailto:iesg-secretary@ietf.org>
Reply-To:       <ietf@ietf.org><mailto:ietf@ietf.org>
To:     IETF-Announce <ietf-announce@ietf.org><mailto:ietf-announce@ietf.or=
g>
CC:     eppext WG <eppext@ietf.org><mailto: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><mailto:jgalvin@afilias.info>
  Antoin Verschuren <antoin.verschuren@sidn.nl><mailto:antoin.verschuren@si=
dn.nl>

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

Mailing list
  Address: eppext@ietf.org<mailto: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<mailto:provreg@ietf.org>
https://www.ietf.org/mailman/listinfo/provreg

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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body dir=3D"auto">
<div>Thanks, Pete!<br>
<br>
Scott</div>
<div><br>
On Dec 12, 2013, at 6:38 PM, &quot;Pete Resnick&quot; &lt;<a href=3D"mailto=
:presnick@qti.qualcomm.com">presnick@qti.qualcomm.com</a>&gt; wrote:<br>
<br>
</div>
<blockquote type=3D"cite">
<div><br>
<br>
-------- Original Message --------
<table class=3D"moz-email-headers-table" border=3D"0" cellpadding=3D"0" cel=
lspacing=3D"0">
<tbody>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">Subject: </th>
<td>WG Action: Formed Extensible Provisioning Protocol Extensions (eppext)<=
/td>
</tr>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">Resent-From: </th=
>
<td><a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:presnick@qti.qualcomm=
.com">&lt;presnick@qti.qualcomm.com&gt;</a></td>
</tr>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">Date: </th>
<td>Thu, 12 Dec 2013 15:24:52 -0800</td>
</tr>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">From: </th>
<td>The IESG <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:iesg-secreta=
ry@ietf.org">
&lt;iesg-secretary@ietf.org&gt;</a></td>
</tr>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">Reply-To: </th>
<td><a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:ietf@ietf.org">&lt;ie=
tf@ietf.org&gt;</a></td>
</tr>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">To: </th>
<td>IETF-Announce <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:ietf-an=
nounce@ietf.org">
&lt;ietf-announce@ietf.org&gt;</a></td>
</tr>
<tr>
<th align=3D"RIGHT" nowrap=3D"nowrap" valign=3D"BASELINE">CC: </th>
<td>eppext WG <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:eppext@ietf=
.org">&lt;eppext@ietf.org&gt;</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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 <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:jgalvin@af=
ilias.info">&lt;jgalvin@afilias.info&gt;</a>
  Antoin Verschuren <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:antoi=
n.verschuren@sidn.nl">&lt;antoin.verschuren@sidn.nl&gt;</a>

Assigned Area Director:
  Pete Resnick <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:presnick@q=
ti.qualcomm.com">&lt;presnick@qti.qualcomm.com&gt;</a>

Mailing list
  Address: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:eppext@ietf=
.org">eppext@ietf.org</a>
  To Subscribe: <a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf=
.org/mailman/listinfo/eppext">https://www.ietf.org/mailman/listinfo/eppext<=
/a>
  Archive: <a class=3D"moz-txt-link-freetext" href=3D"http://www.ietf.org/m=
ail-archive/web/eppext/">http://www.ietf.org/mail-archive/web/eppext/</a>

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 &quot;o=
ne
size fits all&quot; 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 &quot;as needed&quot; 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
<a class=3D"moz-txt-link-freetext" href=3D"https://datatracker.ietf.org/doc=
/draft-hollenbeck-epp-ext-reg/">https://datatracker.ietf.org/doc/draft-holl=
enbeck-epp-ext-reg/</a>.

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
(<a class=3D"moz-txt-link-freetext" href=3D"http://datatracker.ietf.org/doc=
/draft-gieben-epp-keyrelay/">http://datatracker.ietf.org/doc/draft-gieben-e=
pp-keyrelay/</a>)

Internationalized domain names: draft-obispo-epp-idn
(<a class=3D"moz-txt-link-freetext" href=3D"http://datatracker.ietf.org/doc=
/draft-obispo-epp-idn/">http://datatracker.ietf.org/doc/draft-obispo-epp-id=
n/</a>)

New TLD launch phases: draft-tan-epp-launchphase
(<a class=3D"moz-txt-link-freetext" href=3D"http://datatracker.ietf.org/doc=
/draft-tan-epp-launchphase/">http://datatracker.ietf.org/doc/draft-tan-epp-=
launchphase/</a>)

Trademark Clearinghouse: draft-lozano-tmch-smd
(<a class=3D"moz-txt-link-freetext" href=3D"https://datatracker.ietf.org/do=
c/draft-lozano-tmch-smd/">https://datatracker.ietf.org/doc/draft-lozano-tmc=
h-smd/</a>)

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


</pre>
</div>
</blockquote>
<blockquote type=3D"cite">
<div><span>_______________________________________________</span><br>
<span>provreg mailing list</span><br>
<span><a href=3D"mailto:provreg@ietf.org">provreg@ietf.org</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/provreg">https://www=
.ietf.org/mailman/listinfo/provreg</a></span><br>
</div>
</blockquote>
</body>
</html>

--_000_0B3E737A340240A69AD838A8A6878B29verisigncom_--

From bruno.premont@restena.lu  Thu Dec 19 00:16:42 2013
Return-Path: <bruno.premont@restena.lu>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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=?= <bruno.premont@restena.lu>
To: Gavin Brown <gavin.brown@centralnic.com>
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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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 <check> command extension; either <check> or <info>
>        can be used.
>=20
>    2.  added extension elements for <create>, <renew>, <transfer> and
>        <update> 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.  ...
      <fee:currency>EUR</fee:currency>
      <fee:fee>5.00</fee:fee>
      <fee:balance>1500.50</fee:balance>
      ...

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 <gavin.brown@centralnic.com>
>=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 <bruno.premont@restena.lu>
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: <gavin.brown@centralnic.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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 <gavin.brown@centralnic.com>
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=?= <bruno.premont@restena.lu>
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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2013 09:37:13 -0000

Hi Bruno,

It may make sense to allow a <fee:balance> 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 <check> command extension; either <check> or <info>
>>        can be used.
>>
>>    2.  added extension elements for <create>, <renew>, <transfer> and
>>        <update> 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.  ...
>       <fee:currency>EUR</fee:currency>
>       <fee:fee>5.00</fee:fee>
>       <fee:balance>1500.50</fee:balance>
>       ...
> 
> 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 <gavin.brown@centralnic.com>
>>
>>
>> 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: <lem@isc.org>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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?= <lem@isc.org>
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 <gavin.brown@centralnic.com>
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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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 <fee:balance> 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: <gavin.brown@centralnic.com>
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 <provreg@ietfa.amsl.com>; 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 <provreg@ietfa.amsl.com>; 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 <provreg@ietf.org>; 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 <gavin.brown@centralnic.com>
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=?= <lem@isc.org>
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 <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=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 <fee:balance> 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.
