[registrars] [ietf-provreg] Protocol Action: Extensible Provisioning Protocol toProposed Standard (fwd)

[Rick Wesson <wessorh@ar.com>]

EPP moves on toward becomming a standard.

-rick


---------- Forwarded message ----------
Date: Mon, 02 Jun 2003 10:50:20 -0400
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:  ;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@iab.org>,
     ietf-provreg@cafax.se
Subject: [ietf-provreg] Protocol Action: Extensible Provisioning Protocol
    to Proposed  Standard



The IESG has approved the following Internet-Drafts as Proposed
Standards:

 o Extensible Provisioning Protocol
	<draft-ietf-provreg-epp-09.txt>
 o Extensible Provisioning Protocol Domain Name Mapping
	<draft-ietf-provreg-epp-domain-07.txt>
 o Extensible Provisioning Protocol Host Mapping
	<draft-ietf-provreg-epp-host-07.txt>
 o Extensible Provisioning Protocol Contact Mapping
	<draft-ietf-provreg-epp-contact-07.txt>
 o Extensible Provisioning Protocol Transport Over TCP
	<draft-ietf-provreg-epp-tcp-06.txt>

These documents are the product of the Provisioning Registry Protocol
Working Group.  The IESG contact persons are Ned Freed and Patrik
Faltstrom.

Technical Summary

These documents describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository. Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects. Further, object definitions of a few
objects needed for domain name registration and a binding to TCP as
transport protocl is provided.


Working Group Summary

There has been discussions in the wg whether the binding to TCP should
be the only binding, whether other bindings like SMTP and Beep is
"better" or "required" and during last call whether the protcol
itself should be asynchronous or not.

Result of these discussions ended up with TCP as one extension
mechanism of many possible ones (SMTP and Beep bindings in separate
documents), and that the protocol itself should be synchronous. This
last point make the protocol simpler, but will possibly make some
bindings more complicated.

The changes had concensus in the working group, and resulted in the
version of the documents which are now approved.


Protocol Quality

The specification has been reviewed by Patrik Faltstrom for the IESG.