Subject: Dear provreg-archive VIAGRA � Official Site -31%

From: [email-masked]
Date: Mon, 31 May 2010 06:38:56 -0700 (PDT)

Click here.

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o4DMFcv2006529 for ; Fri, 14 May 2010 00:15:38 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o4DMFcV9024267 for ietf-provreg-outgoing; Fri, 14 May 2010 00:15:38 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o4DMFbSM002106 for ; Fri, 14 May 2010 00:15:37 +0200 (MEST)
Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o4DMFa3B023033; Fri, 14 May 2010 00:15:36 +0200
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id o4DMFZvU023032; Fri, 14 May 2010 00:15:35 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Fri, 14 May 2010 00:15:35 +0200
From: Patrick Mevzek
To: EPP Provreg
Subject: Re: [ietf-provreg] RFC4310bis (RFC 5910) Has Been Published
Message-ID: <[email-masked]>
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To:
Organization: Dot And Co
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Fri, 14 May 2010 00:15:36 +0200 (CEST)
Sender: [email-masked]
Precedence: bulk

James Gould 2010-05-13 20:32
> I have an open question around support for RFC 5910 with the other EPP SDK¹s
> (i.e. Net::DRI, EPP-RTK). The liberty-rtk-addon supports RFC 4310 in the
> EPP-RTK, so is someone from Afilias looking to update liberty-rtk-addon to
> support RFC 5910?

Not sure to understood what was your question, at least for my case
:-)
Anyway, I've not read the RFC thoroughly yet, but support for it will
be added to Net::DRI (which supports 4310 since a long time ago, so I
will have to work out how to properly and simply handle both)
and should be available in the next public
release (which is not planned soon, so if there are other interested
parties, or people that want to help or contribute, please contact me
privately).

> Finally, please post to the list any implementation experience with RFC 5910
> so that we can all benefit.

Will do, if I have anything useful to report back.

--
Patrick Mevzek
Dot and Co
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

Return-Path:
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o4DI8DCd024220 for ; Thu, 13 May 2010 20:08:13 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o4DI8DJD000635 for ietf-provreg-outgoing; Thu, 13 May 2010 20:08:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o4DI8CAl025512 for ; Thu, 13 May 2010 20:08:12 +0200 (MEST)
Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o4DI00k0020816 for ; Thu, 13 May 2010 14:00:02 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 14:07:25 -0400
Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 May 2010 18:07:34 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Thu, 13 May 2010 14:08:04 -0400
Subject: [ietf-provreg] RFC4310bis (RFC 5910) Has Been Published
From: James Gould
To: EPP Provreg
Message-ID:
Thread-Topic: RFC4310bis (RFC 5910) Has Been Published
Thread-Index: AcryxztABeDcgONB/U6Y1ke6n5CxVg==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3356604484_43865086"
X-OriginalArrivalTime: 13 May 2010 18:07:25.0666 (UTC) FILETIME=[24678C20:01CAF2C7]
Sender: [email-masked]
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3356604484_43865086
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

Yesterday RFC4310bis (RFC 5910) has been published. The specification can
be found at http://www.ietf.org/rfc/rfc5910.txt. I would like to thank all
of those on this list that contributed to this effort. I want to especiall=
y
thank Olafur for stepping forward to be the Document Sheppard.

The next step is implementing RFC 5910, I have updated the VeriSign Java EP=
P
SDK to support both secDNS-1.0 and secDNS-1.1. The VeriSign Java EPP SDK
also includes a Stub Server that simulates the behavior of a real server
that supports both secDNS-1.0 and secDNS-1.1. I worked on the code while
working on RFC4310bis, which helped ensure that the contents of the
RFC4310bis can be implemented in a client and a server. The biggest
challenge I had was supporting both secDNS-1.0 and secDNS-1.1 at the same
time and keying off of the EPP command elements to drive
the behavior of the command. My experience in supporting thi=
s
within the Stub Server of the VeriSign Java EPP SDK led to some of the
content in section 2 of RFC 5910. We will be releasing the VeriSign Java
EPP SDK soon (i.e. by the end of the month) and it=B9s available as open
source in the event other clients want to validate their implementations
against a local validating EPP Stub Server that supports the behavior
defined in RFC 5910 (including support for DS Data Interface and Key Data
Interface). The Stub Server can be customized to support specific client
test scenarios. =20

I have an open question around support for RFC 5910 with the other EPP SDK=B9=
s
(i.e. Net::DRI, EPP-RTK). The liberty-rtk-addon supports RFC 4310 in the
EPP-RTK, so is someone from Afilias looking to update liberty-rtk-addon to
support RFC 5910? =20

Finally, please post to the list any implementation experience with RFC 591=
0
so that we can all benefit.

Thanks,=20

--=20

JG=20

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

=20
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior writte=
n
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.

--B_3356604484_43865086
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

All,

Yesterday RFC4310bis (RFC 5910) has been published.  The specification=
can be found at http://www.ie=
tf.org/rfc/rfc5910.txt.  I would like to thank all of those on this=
list that contributed to this effort.  I want to especially thank Olaf=
ur for stepping forward to be the Document Sheppard.

The next step is implementing RFC 5910, I have updated the VeriSign Java EP=
P SDK to support both secDNS-1.0 and secDNS-1.1.  The VeriSign Java EPP=
SDK also includes a Stub Server that simulates the behavior of a real serve=
r that supports both secDNS-1.0 and secDNS-1.1.  I worked on the code w=
hile working on RFC4310bis, which helped ensure that the contents of the RFC=
4310bis can be implemented in a client and a server.  The biggest chall=
enge I had was supporting both secDNS-1.0 and secDNS-1.1 at the same time an=
d keying off of the EPP <login> command <extURI> elements to dri=
ve the behavior of the <domain:info> command.  My experience in s=
upporting this within the Stub Server of the VeriSign Java EPP SDK led to so=
me of the content in section 2 of RFC 5910.  We will be releasing the V=
eriSign Java EPP SDK soon (i.e. by the end of the month) and it’s avai=
lable as open source in the event other clients want to validate their imple=
mentations against a local validating EPP Stub Server that supports the beha=
vior defined in RFC 5910 (including support for DS Data Interface and Key Da=
ta Interface).  The Stub Server can be customized to support specific c=
lient test scenarios.

I have an open question around support for RFC 5910 with the other EPP SDK&=
#8217;s (i.e. Net::DRI, EPP-RTK).  The liberty-rtk-addon supports RFC 4=
310 in the EPP-RTK, so is someone from Afilias looking to update liberty-rtk=
-addon to support RFC 5910?

Finally, please post to the list any implementation experience with RFC 591=
0 so that we can all benefit.

Thanks,

--

JG

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

James F. Gould

Principal Software Engineer

VeriSign Naming Services

[email-masked]

Direct: 703.948.3271

Mobile: 703.628.7063

21345 Ridgetop Circle

LS2-2-1

Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet=
ary and/or Registry  Sensitive information intended solely for the reci=
pient and, thus may not be  retransmitted, reproduced or disclosed with=
out the prior written consent of  VeriSign Naming and Directory Service=
s.  If you have received  this e-mail message in error, please =
notify the sender immediately by  telephone or reply e-mail and destroy=
the original message without making a  copy.  Thank you.

--B_3356604484_43865086--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]