Subject: RE: EPP Compliance (Was Re: lastVerified: optional vs. extension)

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 10 Dec 2002 08:43:40 -0500

> So what does it mean by implementing EPP standards by
> IETF for domain registries? Does it mean that it
> _must_ implement the following EPP "core" documents as
> is when they become RFCs?
> 
> - EPP base
> - Domain mapping
> - Contact mapping
> - Host mapping
> - TCP mapping (???)
> 
> Of course this is the minimum set of specifications.
> One can always implement additional features as
> extensions to domain/contact/host objects. 
> 
> [I don't know if TCP mapping should be included in the
> minimum set or not.]

Right now the only documents the IESG is considering for publication as
proposed standards are those that are in the WG document set as listed
above.  If a registry claims conformance to the _IETF_ standards for EPP,
the WG documents are the only documents involved.  As of right now the WG
set includes the TCP mapping document, but that could change if some other
transport document is ever completed.

It's also possible that another organization like OASIS could develop EPP
object mappings, and someone could claim to conform to the OASIS EPP
specifications.  That's cool, we have extensibility to allow this sort of
thing.  This does leave the door open for someone to develop a similar
mapping that's just different enough to prevent interoperability.  In the
ICANN world this could be resolved by negotiating requirements with
registries and registrars to conform to one set of specifications over any
other specifications to avoid interoperability issues.

-Scott-

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Dec 2002 08:16:01 -0800

Answering at my usual rate of a week late...

The IETF does not get into conformance, it gets into 
interoperability.  What this means is that we don't determine if any 
implementation is conformant to a specification.  We are focused on 
whether implementations can work together.

For EPP, the question will be:

Can BrandX client communicate with BrandY server?
Can BrandY client communicate with BrandX server?

For as many values of X and Y (X != Y) as possible.

In reality, the desire is that if RegistrarA uses BrandX client 
software, will they be able to communicate with RegistryB's BrandY 
server and RegistryC's BrandZ server, using the extensions needed for 
each environment.  Each environment means the policy of the registry.

 From the other side, can RegistryB's BrandY server communicate with 
both RegistrarA's BrandX client and RegistrarD's BrandW client 
according to the policies set forth by the registry (modulo any 
tweaks for business needs)?

As has been mentioned, BrandY's server will at best be described as 
implementing RFC's at one level of granularity.  However, I should 
caution folks to realize that RFC's are not standards - they are 
documents in a series.  (This misunderstanding is something that 
concerns me as an IETF'er, but as a WG chair, I can not to anything 
about it.)  What we want to see is BrandY's server also claim 
conformance with the Draft Standard (or Full Standard) version of EPP 
"as defined in documents RFC <etc.>."

How this works in practice is that the implementations should be 
extensible (just like the protocol) so that parts can be plugged in 
as needed.  E.g., if a BrandX client is working fine with a BrandY 
server for the environment in which they exist but I want to start 
working with BrandZ server in another environment, I may need to 
upgrade my BrandX client.  The hope is that the upgrade is possible 
and accomplishes the needed interaction.

As part of IETF activity, we don't want to get into conformance 
claims and we don't want to get into conformance enforcement.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer