Subject: [email-masked] Pharmacy � Official Site -54%

From: [email-masked]
Date: Wed, 30 Jun 2010 09:28:39 -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 o5OFjDRJ026815 for ; Thu, 24 Jun 2010 17:45:13 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5OFjDge008007 for ietf-provreg-outgoing; Thu, 24 Jun 2010 17:45:13 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o5OFjC6O005735 for ; Thu, 24 Jun 2010 17:45:13 +0200 (MEST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9C5FF1ECB408 for ; Thu, 24 Jun 2010 15:45:11 +0000 (UTC)
Date: Thu, 24 Jun 2010 11:45:09 -0400
From: Andrew Sullivan
To: "'EPP Provreg'"
Subject: Re: [ietf-provreg] Presentation on EPP present and future
Message-ID: <[email-masked]>
Mail-Followup-To: Andrew Sullivan , 'EPP Provreg'
References: <[email-masked]> <[email-masked]> <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email-masked]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: [email-masked]
Precedence: bulk

On Thu, Jun 24, 2010 at 09:30:17AM +0200, Ulrich Wisser wrote:
> The nice thing about all the extensions in the wild is, that we are now
> seeing real world business needs for EPP. We could try to filter out a
> common set of extensions needs and create one or more new standard
> extensions.

One way to tackle this would be for someone to put together
draft-epp-common-profile that would outline the extensions (including
-- or not -- the base domain, host, contact extensions) that support
the widest interoperation. That is not actually a change to the
protocol as such, though it is of course an overall change to the
operating protocol as deployed.

I think it would be very helpful to have a draft that one could
discuss, however. But since I work for neither a registry nor a
(real) registrar, I'm not offering to write it.

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o5OFSmpZ003917 for ; Thu, 24 Jun 2010 17:28:48 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5OFSmIB018796 for ietf-provreg-outgoing; Thu, 24 Jun 2010 17:28:48 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o5OFSkbG016716 for ; Thu, 24 Jun 2010 17:28:47 +0200 (MEST)
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o5OF4qsb032721; Thu, 24 Jun 2010 11:04:52 -0400
Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 11:28:33 -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, 24 Jun 2010 15:26:58 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Thu, 24 Jun 2010 11:28:36 -0400
Subject: Re: [ietf-provreg] Presentation on EPP present and future
From: James Gould
To: Ulrich Wisser , EPP Provreg
Message-ID:
Thread-Topic: [ietf-provreg] Presentation on EPP present and future
Thread-Index: AcsTcqPwa5SZa/oWTDK91OUbagdEjgAP0Wxi
In-Reply-To: <[email-masked]>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3360223717_38868454"
X-OriginalArrivalTime: 24 Jun 2010 15:28:33.0533 (UTC) FILETIME=[E828FAD0:01CB13B1]
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_3360223717_38868454
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I agree with Ulrich.

I believe that it=B9s impossible for all of the registries to agree on a
single business model and a single way of doing things. Compromise had to
be made even with the standard mappings (hostObj/hostAttr, thick/thin, etc.=
)
with the use of optional features, so over time additional business ideas
will naturally result in new extensions. It is the technologist=B9s
responsibility to try to meet the business needs without causing interface
issues like updating the base mappings themselves, without creating new
mappings for the same mapping objects, and without creating required
extensions except for specific cases. Every registry has had it=B9s own
unique set of requirements. The ability of EPP to define new mappings is
extremely useful and I don=B9t believe is at issue. We could look to create
standard mappings for Registry objects like Registrar, User, Registrar
Contact, and billing if needed. It=B9s the extensions made to the standard
mappings that is of most interest for combining and standardization. I=B9m
not a fan of updating the base mappings unless there is a compelling reason
to do so, but instead focus on the set of extensions that have been created
for consolidation.=20

As stated in the EPP BOF extensions are not evil but a natural result of
using EPP for different business models. There is no way that we=B9re all
going to agree on a single business model, but it would be a useful exercis=
e
to work on some standard set of extensions.

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

From: Ulrich Wisser
Date: Thu, 24 Jun 2010 03:30:17 -0400
To: EPP Provreg
Subject: Re: [ietf-provreg] Presentation on EPP present and future

Hello,

EPP is in fact *very* extensible. The problem (in my opinion) is that
most registry are really new to EPP when they start to develop an EPP
server. At that point it is very easy to get lost in an extension
frenzy. And once the whole server is build around the new schema it
almost impossible to revert to standard schema.

Then there is the part that EPP does not support business objects. There
are no accounts, no registrar objects, no billing data, ...

EPP has no way of specifying registry rules, e.g. max. number of ns per
domain, ...

The nice thing about all the extensions in the wild is, that we are now
seeing real world business needs for EPP. We could try to filter out a
common set of extensions needs and create one or more new standard
extensions.

I can see a bunch of work for a WG here.

/Ulrich

--
Help building the worlds most comprehensive list of judo dojos.
Put your dojo on the list at http://JudoWorldMap.com
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
List run by majordomo software. For (Un-)subscription and similar details
send "help" to [email-masked]

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

I agree with Ulrich.

I believe that it’s impossible for all of the registries to agree on =
a single business model and a single way of doing things.  Compromise h=
ad to be made even with the standard mappings (hostObj/hostAttr, thick/thin,=
etc.) with the use of optional features, so over time additional business i=
deas will naturally result in new extensions.  It is the technologist&#=
8217;s responsibility to try to meet the business needs without causing inte=
rface issues like updating the base mappings themselves, without creating ne=
w mappings for the same mapping objects, and without creating required exten=
sions except for specific cases.  Every registry has had it’s own=
unique set of requirements.  The ability of EPP to define new mappings=
is extremely useful and I don’t believe is at issue.  We could l=
ook to create standard mappings for Registry objects like Registrar, User, R=
egistrar Contact, and billing if needed.  It’s the extensions mad=
e to the standard mappings that is of most interest for combining and standa=
rdization.   I’m not a fan of updating the base mappings unl=
ess there is a compelling reason to do so, but instead focus on the set of e=
xtensions that have been created for consolidation.

As stated in the EPP BOF extensions are not evil but a natural result of us=
ing EPP for different business models.  There is no way that we’r=
e all going to agree on a single business model, but it would be a useful ex=
ercise to work on some standard set of extensions.

--

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.

From: Ulrich Wisser <[email-masked]>

Date: Thu, 24 Jun 2010 03:30:17 -0400

To: EPP Provreg <ietf-provreg@caf=
ax.se>

Subject: Re: [ietf-provreg] Presentation on EPP present and future

Hello,

EPP is in fact *very* extensible. The problem (in my opinion) is that

most registry are really new to EPP when they start to develop an EPP

server. At that point it is very easy to get lost in an extension

frenzy. And once the whole server is build around the new schema it

almost impossible to revert to standard schema.

Then there is the part that EPP does not support business objects. There
are no accounts, no registrar objects, no billing data, ...

EPP has no way of specifying registry rules, e.g. max. number of ns per

domain, ...

The nice thing about all the extensions in the wild is, that we are now

seeing real world business needs for EPP. We could try to filter out a

common set of extensions needs and create one or more new standard

extensions.

I can see a bunch of work for a WG here.

/Ulrich

--

Help building the worlds most comprehensive list of judo dojos.

Put your dojo on the list at http://JudoW=
orldMap.com

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=

List run by majordomo software.  For (Un-)subscription and similar det=
ails

send "help" to ietf-provr=
[email-masked]

--B_3360223717_38868454--

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o5O7UsPm007070 for ; Thu, 24 Jun 2010 09:30:54 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5O7UswM018245 for ietf-provreg-outgoing; Thu, 24 Jun 2010 09:30:54 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from lvps87-230-32-221.dedicated.hosteurope.de (mail.publisher.de [87.230.32.221]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o5O7UsLR018808 for ; Thu, 24 Jun 2010 09:30:54 +0200 (MEST)
Received: (qmail 26399 invoked from network); 24 Jun 2010 07:30:18 +0000
Received: from gw.iis.se (HELO ulrich-wissers-macbook-pro.local) (212.247.14.38) by mail.publisher.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jun 2010 07:30:18 +0000
Message-ID: <[email-masked]>
Date: Thu, 24 Jun 2010 09:30:17 +0200
From: Ulrich Wisser
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5
MIME-Version: 1.0
To: "'EPP Provreg'"
Subject: Re: [ietf-provreg] Presentation on EPP present and future
References: <[email-masked]> <[email-masked]>
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk

Hello,

EPP is in fact *very* extensible. The problem (in my opinion) is that
most registry are really new to EPP when they start to develop an EPP
server. At that point it is very easy to get lost in an extension
frenzy. And once the whole server is build around the new schema it
almost impossible to revert to standard schema.

Then there is the part that EPP does not support business objects. There
are no accounts, no registrar objects, no billing data, ...

EPP has no way of specifying registry rules, e.g. max. number of ns per
domain, ...

The nice thing about all the extensions in the wild is, that we are now
seeing real world business needs for EPP. We could try to filter out a
common set of extensions needs and create one or more new standard
extensions.

I can see a bunch of work for a WG here.

/Ulrich

--
Help building the worlds most comprehensive list of judo dojos.
Put your dojo on the list at http://JudoWorldMap.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o5O5hbV1028456 for ; Thu, 24 Jun 2010 07:43:37 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5O5hbxP022428 for ietf-provreg-outgoing; Thu, 24 Jun 2010 07:43:37 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o5O5hZDU025382 for ; Thu, 24 Jun 2010 07:43:36 +0200 (MEST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: PGP.sig : 186
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAImNIkxAZnwM/2dsb2JhbACfNnGmOppChRsE
X-IronPort-AV: E=Sophos;i="4.53,472,1272844800"; d="sig'?scan'208";a="124870819"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Jun 2010 05:43:34 +0000
Received: from ams3-vpn-dhcp5472.cisco.com (ams3-vpn-dhcp5472.cisco.com [10.61.85.95]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5O5hXMi019393; Thu, 24 Jun 2010 05:43:33 GMT
Subject: Re: [ietf-provreg] Presentation on EPP present and future
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-231-550784745"
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=
In-Reply-To: <[email-masked]>
Date: Thu, 24 Jun 2010 07:43:31 +0200
Cc: "'Patrick Mevzek'" , "'EPP Provreg'"
Content-Transfer-Encoding: 7bit
Message-Id:
References: <[email-masked]> <[email-masked]>
To: Michael Young
X-Pgp-Agent: GPGMail 1.2.3
X-Mailer: Apple Mail (2.1081)
Sender: [email-masked]
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-231-550784745
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii

On 24 jun 2010, at 01.20, Michael Young wrote:

> Its been said before, but I'll say it again, EPP is an Extensible =
protocol.
> Given its flexibility, I have yet to hear an argument as to why =
existing
> issues cannot be addressed using the extension system.

The overall problem is that it is extensible. The amount of new code =
that has to be written for each registry is a royal pain, and an =
indication the protocol in reality is not interoperable at all.

So, I think the big question is:

- Is there a goal to get interoperable implementations?

If so, the ability to extend must be _decreased_ a lot.

Example of things that must be agreed upon:

- The format accepted for various attribute values (telephone numbers, =
names etc)

- What happens in detail with various related records when a domain is =
transferred

...

Just look at the number of special hacks in the perl library for =
example.

If that is not a goal, so that code has to be rewritten for each =
registry, then of course we have a base protocol that "works".

Patrik

--Apple-Mail-231-550784745
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFMIvCEvHlR2X0luNwRAtCfAKDbRUnp8sTgcwcJGZJWACVcVomkXgCdGPmB
NXS4xWy1wcspSXnoorHxXd4=
=EI8w
-----END PGP SIGNATURE-----

--Apple-Mail-231-550784745--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o5O0VYeq016615 for ; Thu, 24 Jun 2010 02:31:34 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5O0VYB6009357 for ietf-provreg-outgoing; Thu, 24 Jun 2010 02:31:34 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o5O0VWbD005097 for ; Thu, 24 Jun 2010 02:31:33 +0200 (MEST)
Received: by gwb11 with SMTP id 11so1681740gwb.27 for ; Wed, 23 Jun 2010 17:31:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.76.11 with SMTP id d11mr8468898ybl.204.1277339489483; Wed, 23 Jun 2010 17:31:29 -0700 (PDT)
Received: by 10.151.8.8 with HTTP; Wed, 23 Jun 2010 17:31:29 -0700 (PDT)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Thu, 24 Jun 2010 10:31:29 +1000
Message-ID:
Subject: Re: [ietf-provreg] Presentation on EPP present and future
From: Wil Tan
To: Michael Young
Cc: Patrick Mevzek , EPP Provreg
Content-Type: multipart/alternative; boundary=000e0cd70dda873bb60489bbc6ae
Sender: [email-masked]
Precedence: bulk

--000e0cd70dda873bb60489bbc6ae
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 24, 2010 at 9:20 AM, Michael Young wrote:

> As far as I understand the process to initiate further EPP work in the IETF
> would focus on a) defining a problem and subsequent scope of work b)
> garnering support from the relevant area director c) following the process
> of initiating a working group - mailing list where clear efforts are
> demonstrated, BOF, etc OR another option is to file an informational RFC.
>
>
I missed Patrick's presentation at the ccNSO tech day, but did read the
draft that he circulated a while ago.

>From my perspective, the main problem with how the implementations have
evolved is a loss of interoperability. IIRC, in the case of CZNIC, complete
schemas were defined to replace the standard domain and contact mappings,
reducing EPP into not much more than a framing protocol. Not sure exactly
the rationale for doing that, though I'm sure considerable thoughts have
been put into it. It does mean that registrars could not easily reuse
existing libraries or code written for one registries to talk to another
though.

> Its been said before, but I'll say it again, EPP is an Extensible protocol.
> Given its flexibility, I have yet to hear an argument as to why existing
> issues cannot be addressed using the extension system.
>
>
See above. Also, I believe there are some minor tweaks that could be done to
the existing schema that would make less inherent assumptions about the
registry data model (by making some fields optional). However, I don't any
way to handle schema changes in a backwards compatible manner.

Working along the lines of defining new mapping encompassing common use
cases would perhaps be worth pursuing and more productive than attempting to
change the core protocol. Patrick's work would certainly come in handy in
that case.

wil.

If a valid argument can be made, I am happy to support additional efforts on
> the base protocol, as of yet, I have not seen one.
>
> Best Regards,
>
> Michael Young
>
>
> -----Original Message-----
> From: Patrick Mevzek [mailto:[email-masked]]
> Sent: June-23-10 9:01 PM
> To: EPP Provreg
> Subject: [ietf-provreg] Presentation on EPP present and future
>
> Hello,
>
> I've done last monday in the ICANN ccNSO
> tech day a presentation on my current view of EPP, based on the
> extensions seen in the wild, and what could be future works on EPP
> with some data on the 60+ extensions I've seen, and choices among EPP
> "options" (host as attribute or contact, contact data, etc.)
>
> You can find the presentation online here:
>
> http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica
> nn-brussels-ccnso-techday-201006/index.html
> or if you want just the text as PDF:
>
> http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica
>
> nn-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-tech
> day-201006.pdf
>
> While the attendance was high, there has not been any real feedback
> at that time on the relevance on working again on EPP or even, as
> stated in my presentation, to try at least to make people (from
> registries, registrars, and outside developers such as myself) to
> collaborate together, starting with extensions documentation and
> public announcements.
>
> Hope that helps.
>
> --
> Patrick Mevzek
> Dot and Co
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software. For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>

--000e0cd70dda873bb60489bbc6ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 24, 2010 at 9:20 AM, Michael=
Young <myou=
[email-masked]> wrote:

As far as I understand the process to initiate further EPP work in the IETF=

would focus on a) defining a problem and subsequent scope of work =C2=A0b)<=
br>
garnering support from the relevant area director =C2=A0c) following the pr=
ocess

of initiating a working group - mailing list where clear efforts are

demonstrated, BOF, etc OR another option is to file an informational RFC.

I missed Patrick's presentation at=
the ccNSO tech day, but did read the draft that he circulated a while ago.=

From my perspective, the main problem with how th=
e implementations have evolved is a loss of interoperability. IIRC, in the =
case of CZNIC, complete schemas were defined to replace the standard domain=
and contact mappings, reducing EPP into not much more than a framing proto=
col. Not sure exactly the rationale for doing that, though I'm sure con=
siderable thoughts have been put into it. It does mean that registrars coul=
d not easily reuse existing libraries or code written for one registries to=
talk to another though.

=C2=A0

Its been said before, but I'll say it again, EPP is an Extensible proto=
col.

Given its flexibility, I have yet to hear an argument as to why existing
issues cannot be addressed using the extension system.

See above. Also, I believe there are s=
ome minor tweaks that could be done to the existing schema that would make =
less inherent assumptions about the registry data model (by making some fie=
lds optional). However, I don't any way to handle schema changes in a b=
ackwards compatible manner.

Working along the lines of defining new mapping encompa=
ssing common use cases would perhaps be worth pursuing and more productive =
than attempting to change the core protocol. Patrick's work would certa=
inly come in handy in that case.

=C2=A0

wil.

If a valid argument can be made, I am happy to support additional efforts o=
n

the base protocol, as of yet, I have not seen one.

Best Regards,

Michael Young

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

From: Patrick Mevzek [mailto:[email-masked]]

Sent: June-23-10 9:01 PM

To: EPP Provreg

Subject: [ietf-provreg] Presentation on EPP present and future

Hello,

I've done last monday in the ICANN ccNSO

tech day a presentation on my current view of EPP, based on the

extensions seen in the wild, and what could be future works on EPP

with some data on the 60+ extensions I've seen, and choices among EPP
"options" (host as attribute or contact, contact data, etc.)

You can find the presentation online here:

http://www.d=
otandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica

nn-brussels-ccnso-techday-201006/index.html

or if you want just the text as PDF:

http://www.dotandco.com/services/software=
/Net-DRI/docs/netdri-future-epp-ica

nn-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-tec=
h

day-201006.pdf

While the attendance was high, there has not been any real feedback

at that time on the relevance on working again on EPP or even, as

stated in my presentation, to try at least to make people (from

registries, registrars, and outside developers such as myself) to

collaborate together, starting with extensions documentation and

public announcements.

Hope that helps.

--

Patrick Mevzek

Dot and Co <http:=
//www.dotandco.com/> <http://www.dotandco.net/>

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-

List run by majordomo software. =C2=A0For (Un-)subscription and similar det=
ails

send "help" to i=
[email-masked]

-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-

List run by majordomo software. =C2=A0For (Un-)subscription and similar det=
ails

send "help" to i=
[email-masked]

--000e0cd70dda873bb60489bbc6ae--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o5NNKxHa002082 for ; Thu, 24 Jun 2010 01:20:59 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5NNKx5R003594 for ietf-provreg-outgoing; Thu, 24 Jun 2010 01:20:59 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [email-masked] using -f
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by nic.cafax.se (8.13.7/8.12.11) with ESMTP id o5NNKwrT014218 for ; Thu, 24 Jun 2010 01:20:59 +0200 (MEST)
From: "Michael Young"
To: "'Patrick Mevzek'" , "'EPP Provreg'"
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: RE: [ietf-provreg] Presentation on EPP present and future
Date: Thu, 24 Jun 2010 01:20:46 +0200
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcsTH/VECbD7PToOTxqbiFuqi7C4OgACTEYw
Content-Language: en-ca
X-Authenticated: True
Sender: [email-masked]
Precedence: bulk

As far as I understand the process to initiate further EPP work in the IETF
would focus on a) defining a problem and subsequent scope of work b)
garnering support from the relevant area director c) following the process
of initiating a working group - mailing list where clear efforts are
demonstrated, BOF, etc OR another option is to file an informational RFC.

Its been said before, but I'll say it again, EPP is an Extensible protocol.
Given its flexibility, I have yet to hear an argument as to why existing
issues cannot be addressed using the extension system.

If a valid argument can be made, I am happy to support additional efforts on
the base protocol, as of yet, I have not seen one.

Best Regards,

Michael Young

-----Original Message-----
From: Patrick Mevzek [mailto:[email-masked]]
Sent: June-23-10 9:01 PM
To: EPP Provreg
Subject: [ietf-provreg] Presentation on EPP present and future

Hello,

I've done last monday in the ICANN ccNSO
tech day a presentation on my current view of EPP, based on the
extensions seen in the wild, and what could be future works on EPP
with some data on the 60+ extensions I've seen, and choices among EPP
"options" (host as attribute or contact, contact data, etc.)

You can find the presentation online here:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica
nn-brussels-ccnso-techday-201006/index.html
or if you want just the text as PDF:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-ica
nn-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-tech
day-201006.pdf

While the attendance was high, there has not been any real feedback
at that time on the relevance on working again on EPP or even, as
stated in my presentation, to try at least to make people (from
registries, registrars, and outside developers such as myself) to
collaborate together, starting with extensions documentation and
public announcements.

Hope that helps.

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

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 o5NJ10sj013632 for ; Wed, 23 Jun 2010 21:01:00 +0200 (MEST)
Received: (from majordom@localhost) by nic.cafax.se (8.13.7/8.12.11/Submit) id o5NJ10sm011326 for ietf-provreg-outgoing; Wed, 23 Jun 2010 21:01:00 +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 o5NJ0xU2022151 for ; Wed, 23 Jun 2010 21:00:59 +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 o5NJ0xkE011426; Wed, 23 Jun 2010 21:00:59 +0200
Received: from localhost (localhost [[UNIX: localhost]]) by triglav.dotandco.com (8.13.8/8.13.8/Submit) id o5NJ0xFU011425; Wed, 23 Jun 2010 21:00:59 +0200
X-Authentication-Warning: triglav.dotandco.com: patrick set sender to [email-masked] using -f
Date: Wed, 23 Jun 2010 21:00:57 +0200
From: Patrick Mevzek
To: EPP Provreg
Subject: [ietf-provreg] Presentation on EPP present and future
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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]); Wed, 23 Jun 2010 21:00:59 +0200 (CEST)
Sender: [email-masked]
Precedence: bulk

Hello,

I've done last monday in the ICANN ccNSO
tech day a presentation on my current view of EPP, based on the
extensions seen in the wild, and what could be future works on EPP
with some data on the 60+ extensions I've seen, and choices among EPP
"options" (host as attribute or contact, contact data, etc.)

You can find the presentation online here:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/index.html
or if you want just the text as PDF:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-techday-201006.pdf

While the attendance was high, there has not been any real feedback
at that time on the relevance on working again on EPP or even, as
stated in my presentation, to try at least to make people (from
registries, registrars, and outside developers such as myself) to
collaborate together, starting with extensions documentation and
public announcements.

Hope that helps.

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