From wil@cloudregistry.net Mon Sep 10 19:38:52 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F4521F857E for ; Mon, 10 Sep 2012 19:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUbRmqv83gIa for ; Mon, 10 Sep 2012 19:38:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BC21F857D for ; Mon, 10 Sep 2012 19:38:51 -0700 (PDT) Received: by iabz21 with SMTP id z21so16331iab.31 for ; Mon, 10 Sep 2012 19:38:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=A09b1LGaUdFgQTzeQGDZvm6CMlj9A7JyUj8XiUL7T4g=; b=f1xF8U9UTlJ/wyCmhaUNQS6BeaQ68d/tZZ0NqO1ApSyqj2eFzNPUFmR7b1OqxC3ZQn LIgPjSwQjCCZ90bzAWw344xMW8QFzriym+YHz6jxUsO6jA5c5Mv6O68j9lRyTf1ThAIu XIi4BlB2uO04aW+HlCdotin8Lca036n4NnepiIv5Ol3dA1QLjzz27K5y3jgTdHmKykFe QWCO1HBNfkqqn90AK6wsVEpmrqOQGRjtNBlO/oC9bpG5AsrF5/XBoRZeroqGZViXSrMo 3OTC3w39T2b59koxuEzFIicL5MyTd2RIl+vMd15pJKQTRGyAgkGBiEejWg9LshfFiGJh j6kQ== Received: by 10.50.168.70 with SMTP id zu6mr14053331igb.44.1347331131290; Mon, 10 Sep 2012 19:38:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.37.168 with HTTP; Mon, 10 Sep 2012 19:38:10 -0700 (PDT) From: Wil Tan Date: Tue, 11 Sep 2012 12:38:10 +1000 Message-ID: To: Keith Gaughan Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlJ/zyGlBeDRQVg4zjcLhuwRpnZqlR4gwWBRIIL4bZwwAPuKsFWPhBJ31a5hOzP4BTxRyyh Cc: provreg@ietf.org Subject: [provreg] Result Codes (Re: Standard Extensions) X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 02:38:52 -0000 I wonder if there's any value in some of us getting together to author an informational draft documenting existing behaviours surrounding the use of result codes. Specifically, we could list the error conditions and the corresponding result codes that are returned by servers "in the wild". This would help future implementers, both from a client's and server's perspective, to at least not diverge further. Furthermore, it would perhaps become apparent if an extension is needed. .wil On Fri, Aug 24, 2012 at 8:03 AM, Keith Gaughan wrote: > Or maybe it's the way that some registries return 1001 (pending) as the > status for a pending transfer and some return 1000 (completed) but with > the element in the body set to 'pending'. Then there's the > crapshoot as to whether the registrar supports/allows/requires > international address types, local address types, or both, which often > goes undocumented. > > There's surprisingly little agreement on the actual meaning of 2201 > (authorisation error) and 2202 (invalid authorisation information), > when they should be used, and how the registrar should react to them. > I've even seen 2306 (parameter value policy error) cropping up where > I'd expect either 2201 or 2202. > > Ditto goes for confusion around the use of the 200[1-5] series of status > codes. > Also earlier: On Wed, Jan 25, 2012 at 11:01 AM, Patrick Mevzek wrote: > Hollenbeck, Scott 2012-01-24 13:01 >> How many registries are using custom result codes and status values? > > Indeed, I rewrote myself saying almost any registry, because I had in > mind VeriSign which does not need custom codes. > > However as an EPP client implementor I've seen registries using their > own result codes/status values in such ways: > - either just adding items to the associated lists, breaking the EPP > XML Schema validation (for the brave souls doing it live) > - or adding "sub" values, that is besides standard ones > - or creating a true EPP extension, in the RFC 3735 sense, with new > values. > > > Looking at my code I see at least the following: > .FR > .AT / IENUMAT > .BE > .EU > .LU > .NO > .NL > .CA > > but I'm not really keeping track of list of specific statuses, so > there may be some more, maybe some registrars could provide more info. > From fobispo@isc.org Mon Sep 10 19:46:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486CA21F865B for ; Mon, 10 Sep 2012 19:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdvvxekowWeU for ; Mon, 10 Sep 2012 19:46:00 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 622C621F8653 for ; Mon, 10 Sep 2012 19:46:00 -0700 (PDT) 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 id 2CF5AC9594; Tue, 11 Sep 2012 02:45:50 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:470:1f05:1326:5502:21c1:217e:40d3] (unknown [IPv6:2001:470:1f05:1326:5502:21c1:217e:40d3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F1B7D216C25; Tue, 11 Sep 2012 02:45:49 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: Date: Mon, 10 Sep 2012 19:45:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <983BADB0-EA1B-44AF-B0D8-E5F54AE8E533@isc.org> References: To: Wil Tan X-Mailer: Apple Mail (2.1486) Cc: provreg@ietf.org Subject: Re: [provreg] Result Codes (Re: Standard Extensions) X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 02:46:01 -0000 Hi Wil, I don't think that this solution will prevent people from doing the = wrong thing. The real problem seems like the lack of RFC compliance or even common = sense. Registries that are not bound to ICANN regulations (ccTLDs, etc.) = will implement their own interfaces/extensions and registrars wanting to = deal with them will have to adapt to those cases if they want to sell = domain names. Is it optimal? no, but trying to normalize that is similar = to try to normalize registry policies across all ccTLDs (or even *TLDs). One of the things I want to work on, is an EPP RFC compliance tool, = which will basically look at the use cases stated in the RFCs, run a = test against a server and see if the response makes sense or not. Having = such tool should help registries pinpoint implementation problems and = hopefully fix them. If any of you guys feel like a tool such as the one I'm describing is = useful, contact me in private to see where it can go. Francisco On Sep 10, 2012, at 7:38 PM, Wil Tan wrote: > I wonder if there's any value in some of us getting together to author > an informational draft documenting existing behaviours surrounding the > use of result codes. Specifically, we could list the error conditions > and the corresponding result codes that are returned by servers "in > the wild". This would help future implementers, both from a client's > and server's perspective, to at least not diverge further. > Furthermore, it would perhaps become apparent if an extension is > needed. >=20 > .wil >=20 > On Fri, Aug 24, 2012 at 8:03 AM, Keith Gaughan = wrote: >=20 >> Or maybe it's the way that some registries return 1001 (pending) as = the >> status for a pending transfer and some return 1000 (completed) but = with >> the element in the body set to 'pending'. Then there's the >> crapshoot as to whether the registrar supports/allows/requires >> international address types, local address types, or both, which = often >> goes undocumented. >>=20 >> There's surprisingly little agreement on the actual meaning of 2201 >> (authorisation error) and 2202 (invalid authorisation information), >> when they should be used, and how the registrar should react to them. >> I've even seen 2306 (parameter value policy error) cropping up where >> I'd expect either 2201 or 2202. >>=20 >> Ditto goes for confusion around the use of the 200[1-5] series of = status >> codes. >>=20 >=20 >=20 > Also earlier: >=20 >=20 > On Wed, Jan 25, 2012 at 11:01 AM, Patrick Mevzek > wrote: >> Hollenbeck, Scott 2012-01-24 13:01 >>> How many registries are using custom result codes and status values? >>=20 >> Indeed, I rewrote myself saying almost any registry, because I had in >> mind VeriSign which does not need custom codes. >>=20 >> However as an EPP client implementor I've seen registries using their >> own result codes/status values in such ways: >> - either just adding items to the associated lists, breaking the EPP >> XML Schema validation (for the brave souls doing it live) >> - or adding "sub" values, that is besides standard ones >> - or creating a true EPP extension, in the RFC 3735 sense, with new >> values. >>=20 >>=20 >> Looking at my code I see at least the following: >> .FR >> .AT / IENUMAT >> .BE >> .EU >> .LU >> .NO >> .NL >> .CA >>=20 >> but I'm not really keeping track of list of specific statuses, so >> there may be some more, maybe some registrars could provide more = info. >>=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From michael@mwyoung.ca Mon Sep 10 20:48:09 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3406021F8557 for ; Mon, 10 Sep 2012 20:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2RS4to21h+V for ; Mon, 10 Sep 2012 20:48:08 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0ED21F8766 for ; Mon, 10 Sep 2012 20:48:08 -0700 (PDT) Received: by ieak13 with SMTP id k13so126317iea.31 for ; Mon, 10 Sep 2012 20:48:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=BsgG0+OfunhVh+cANA/zsXruxIKBimVlAJtyahq5wCI=; b=Vyn1RvZXtRxUB7ZPhP9hvAs6JYXtkbmggqoPdpbym+twUWEr52fkoKYfyFEfDlPpXe x8j6k0/PdmDQSMl70zpT+CZWrOmCbXilBMJ85R2w3LgTiDh+Q+ERVZltxpjqE4KLa0qh 9aaMJPEppTJRCgDuRzz91yZKMODY/vJXIaj95Zjr0Y6Dh7o7tILuKpvTs4F5Pqz+cgHj JYphmcCK1O23XstrikSkXMPuxnn61L1vYbgOi+4PbqWL7w6ocDNwhVm0qEJ/cgKQhbEP CMyTBF/EB8RdJGxZwMos3ktBxLuh9iHX03EvJOKwSl6HYeW4956y/JgbaNxZNe7iRu53 wKOA== Received: by 10.50.40.132 with SMTP id x4mr13784264igk.48.1347335287703; Mon, 10 Sep 2012 20:48:07 -0700 (PDT) Received: from [172.16.1.26] (CPE7073cbb4404e-CM78cd8ece2635.cpe.net.cable.rogers.com. [99.226.143.17]) by mx.google.com with ESMTPS id ua2sm621006igb.7.2012.09.10.20.48.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Sep 2012 20:48:06 -0700 (PDT) References: <983BADB0-EA1B-44AF-B0D8-E5F54AE8E533@isc.org> In-Reply-To: <983BADB0-EA1B-44AF-B0D8-E5F54AE8E533@isc.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6159567C-A5FF-474A-B4BE-DD2DB6A19BCE@mwyoung.ca> X-Mailer: iPhone Mail (9B206) From: Michael Young Date: Mon, 10 Sep 2012 23:48:04 -0400 To: Francisco Obispo X-Gm-Message-State: ALoCoQlbYEr2YQX8Vn0hNlxZ2Rzzt830hGx0g1J2Mq3fwY+2bYVA9YRFmou9imKzjTnmOeQvULoq Cc: "provreg@ietf.org" Subject: Re: [provreg] Result Codes (Re: Standard Extensions) X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 03:48:09 -0000 Hi Francisco, Its pretty common for registry service providers to have an automated basic e= pp test available for accrediting registrars. They generally run separate te= st suites for extensions. The basic epp test server can be setup to reflect v= arious TLD policies.=20 I think there's likely a great deal of existing work that folks could contri= bute towards your goal if they are interested in doing so. Michael Young M:647-289-1220 On 2012-09-10, at 22:45, Francisco Obispo wrote: > Hi Wil, >=20 > I don't think that this solution will prevent people from doing the wrong t= hing. >=20 > The real problem seems like the lack of RFC compliance or even common sens= e. Registries that are not bound to ICANN regulations (ccTLDs, etc.) will im= plement their own interfaces/extensions and registrars wanting to deal with t= hem will have to adapt to those cases if they want to sell domain names. Is i= t optimal? no, but trying to normalize that is similar to try to normalize r= egistry policies across all ccTLDs (or even *TLDs). >=20 > One of the things I want to work on, is an EPP RFC compliance tool, which w= ill basically look at the use cases stated in the RFCs, run a test against a= server and see if the response makes sense or not. Having such tool should h= elp registries pinpoint implementation problems and hopefully fix them. >=20 > If any of you guys feel like a tool such as the one I'm describing is usef= ul, contact me in private to see where it can go. >=20 > Francisco >=20 >=20 >=20 > On Sep 10, 2012, at 7:38 PM, Wil Tan wrote: >=20 >> I wonder if there's any value in some of us getting together to author >> an informational draft documenting existing behaviours surrounding the >> use of result codes. Specifically, we could list the error conditions >> and the corresponding result codes that are returned by servers "in >> the wild". This would help future implementers, both from a client's >> and server's perspective, to at least not diverge further. >> Furthermore, it would perhaps become apparent if an extension is >> needed. >>=20 >> .wil >>=20 >> On Fri, Aug 24, 2012 at 8:03 AM, Keith Gaughan wro= te: >>=20 >>> Or maybe it's the way that some registries return 1001 (pending) as the >>> status for a pending transfer and some return 1000 (completed) but with >>> the element in the body set to 'pending'. Then there's the >>> crapshoot as to whether the registrar supports/allows/requires >>> international address types, local address types, or both, which often >>> goes undocumented. >>>=20 >>> There's surprisingly little agreement on the actual meaning of 2201 >>> (authorisation error) and 2202 (invalid authorisation information), >>> when they should be used, and how the registrar should react to them. >>> I've even seen 2306 (parameter value policy error) cropping up where >>> I'd expect either 2201 or 2202. >>>=20 >>> Ditto goes for confusion around the use of the 200[1-5] series of status= >>> codes. >>>=20 >>=20 >>=20 >> Also earlier: >>=20 >>=20 >> On Wed, Jan 25, 2012 at 11:01 AM, Patrick Mevzek >> wrote: >>> Hollenbeck, Scott 2012-01-24 13:01 >>>> How many registries are using custom result codes and status values? >>>=20 >>> Indeed, I rewrote myself saying almost any registry, because I had in >>> mind VeriSign which does not need custom codes. >>>=20 >>> However as an EPP client implementor I've seen registries using their >>> own result codes/status values in such ways: >>> - either just adding items to the associated lists, breaking the EPP >>> XML Schema validation (for the brave souls doing it live) >>> - or adding "sub" values, that is besides standard ones >>> - or creating a true EPP extension, in the RFC 3735 sense, with new >>> values. >>>=20 >>>=20 >>> Looking at my code I see at least the following: >>> .FR >>> .AT / IENUMAT >>> .BE >>> .EU >>> .LU >>> .NO >>> .NL >>> .CA >>>=20 >>> but I'm not really keeping track of list of specific statuses, so >>> there may be some more, maybe some registrars could provide more info. >>>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >=20 > Francisco Obispo=20 > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From bernie@ietf.hoeneisen.ch Tue Sep 11 01:03:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6777C21F87A0 for ; Tue, 11 Sep 2012 01:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSZj16Czdo3T for ; Tue, 11 Sep 2012 01:03:48 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5E21F879F for ; Tue, 11 Sep 2012 01:03:47 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1TBLRW-00060Z-TS; Tue, 11 Sep 2012 10:03:35 +0200 Date: Tue, 11 Sep 2012 10:03:34 +0200 (CEST) From: "Ucom.ch - Bernie Hoeneisen" X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Wil Tan In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF Provreg Mailing List Subject: Re: [provreg] Result Codes (Re: Standard Extensions) X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:03:49 -0000 On Tue, 11 Sep 2012, Wil Tan wrote: > I wonder if there's any value in some of us getting together to author > an informational draft documenting existing behaviours surrounding the > use of result codes. Specifically, we could list the error conditions > and the corresponding result codes that are returned by servers "in > the wild". This would help future implementers, both from a client's > and server's perspective, to at least not diverge further. > Furthermore, it would perhaps become apparent if an extension is > needed. This certainly helps, but does not solve the basic issue, which I'd call a flaw in the main EPP specs. Those specify a limited set of status codes, restricted by XML schema. Any _clean_ extension would require a change in a rather core EPP XML schema, which nobody likes to touch (for good reasons). At next revision of EPP core specs, that affected XML shemata should be relaxed to allow any 4 digit code as status code. Along with this, guidelines should be defined for registration of additional status codes with IANA (e.g. Expert Review policy). Comments? cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Technology From fobispo@isc.org Tue Sep 11 13:40:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498C021F873C for ; Tue, 11 Sep 2012 13:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqAom2tjYeMa for ; Tue, 11 Sep 2012 13:40:43 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B97BB21F873A for ; Tue, 11 Sep 2012 13:40:43 -0700 (PDT) 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.ams1.isc.org (Postfix) with ESMTPS id A68FA5F98A6; Tue, 11 Sep 2012 20:40:33 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:d6:4f67:9728:c5b] (unknown [IPv6:2001:4f8:3:64:d6:4f67:9728:c5b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F0AB0216C70; Tue, 11 Sep 2012 20:40:31 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Francisco Obispo In-Reply-To: <6159567C-A5FF-474A-B4BE-DD2DB6A19BCE@mwyoung.ca> Date: Tue, 11 Sep 2012 13:40:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <983BADB0-EA1B-44AF-B0D8-E5F54AE8E533@isc.org> <6159567C-A5FF-474A-B4BE-DD2DB6A19BCE@mwyoung.ca> To: Michael Young X-Mailer: Apple Mail (2.1486) Cc: "provreg@ietf.org" Subject: Re: [provreg] Result Codes (Re: Standard Extensions) X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:40:44 -0000 On Sep 10, 2012, at 8:48 PM, Michael Young wrote: > Hi Francisco, >=20 > Its pretty common for registry service providers to have an automated = basic epp test available for accrediting registrars. They generally run = separate test suites for extensions. The basic epp test server can be = setup to reflect various TLD policies.=20 >=20 Yes, > I think there's likely a great deal of existing work that folks could = contribute towards your goal if they are interested in doing so. >=20 This is why I think it will be useful to have a team of people work on = it, so that we can reuse some of it. I'll try to put something together and hopefully we will attract some = interest. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From JGould@verisign.com Wed Sep 12 06:27:31 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6AD21F8499 for ; Wed, 12 Sep 2012 06:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E277dR8WUQbB for ; Wed, 12 Sep 2012 06:27:30 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id E3B7021F84A6 for ; Wed, 12 Sep 2012 06:27:29 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUFCNwVNurWc6VPEQUsrOQ4xBFvZ9Gk4D@postini.com; Wed, 12 Sep 2012 06:27:30 PDT 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 q8CDROOT026567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Sep 2012 09:27:28 -0400 Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 09:27:24 -0400 From: "Gould, James" To: "provreg@ietf.org" Thread-Topic: Launch Phase EPP Extension Version 03 Posted Thread-Index: AQHNkOpYy+6kkbBRiUWfdp5HIruH3A== Date: Wed, 12 Sep 2012 13:27:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_C41D7AF7FCECBE44940E9477E8E70D7A0D6E40CEBRN1WNEXMBX02vc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [provreg] Launch Phase EPP Extension Version 03 Posted X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:27:31 -0000 --_004_C41D7AF7FCECBE44940E9477E8E70D7A0D6E40CEBRN1WNEXMBX02vc_ Content-Type: multipart/alternative; boundary="_000_C41D7AF7FCECBE44940E9477E8E70D7A0D6E40CEBRN1WNEXMBX02vc_" --_000_C41D7AF7FCECBE44940E9477E8E70D7A0D6E40CEBRN1WNEXMBX02vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapp= ing that includes the following changes from 02 to 03. The mapping extensi= on supports the two launch models (ICANN and ARI/Neustar) along with the mo= dels that were previously defined in the Launch Phase EPP Extension Version= 01. You can find the draft at the URL http://tools.ietf.org/html/draft-t= an-epp-launchphase-03. I'm going to post a message on the tmch-tech list a= s well. The changes between the 02 and 03 versions of the draft include: 1. Removed XSI namespace per Keith Gaughan's suggestion on the provreg l= ist 2. Added extensibility to the launch:status element and added the pendin= gAuction status per Trung Tran's feedback on the provreg list. 3. Added support for the Claims Check Command, updated the location and = contents of the signedNotice, and replaced most references of Claim to Mark= based on the work being done on the ARI/Neustar launch model. If you have any feedback please post them to the list for discussion. Thanks, -- JG [cid:736749C2-5A55-4A18-A302-EB1FE3844DA4] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com --_000_C41D7AF7FCECBE44940E9477E8E70D7A0D6E40CEBRN1WNEXMBX02vc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension= Mapping that includes the following changes from 02 to 03.  The mappi= ng extension supports the two launch models (ICANN and ARI/Neustar) along w= ith the models that were previously defined in the Launch Phase EPP Extension Version 01.  You can find the draft= at the URL  http://tools.ietf.org/html/draft-tan-epp-launchphase-03.&nbs= p; I'm going to post a message on the tmch-tech list as well.  The changes between the 02 and 03 versions of the draft inc= lude:

  1. Removed XSI namespace per Keith Gaughan's suggestion on the provreg lis= t
  2. Added extensibility to the launch:status element and added the pe= ndingAuction status per Trung Tran's feedback on the provreg list.
  3. = Added support for the Claims Check Command, updated the location and conten= ts of the signedNotice, and replaced most references of Claim to Mark based= on the work being done on the ARI/Neustar launch model.    
    4. =
If you have any feedback please post them to the list for discussion.<= /div>

Thanks,
  

--<= /p>

  

JG<= /p>

 

 

James Gould

Principal Software Engineer

jgould@verisign.= com=

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com


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