[wabnitz@digital-security.com: [open-eu] Open Registry Robot / EPP transport layer]

[Stephane Bortzmeyer <bortzmeyer@nic.fr>]

Sent on a public mailing list of CORE so I assume I can redistribute
it.

---

To: open-eu discuss <discuss@open-eu.org>
From: Sven-Holger Wabnitz <wabnitz@digital-security.com>
Date: 09 Aug 2002 14:05:11 +0200
Reply-To: discuss@open-eu.org
Sender: owner-discuss@open-eu.org
Subject: [open-eu] Open Registry Robot / EPP transport layer

Dear all,


to run the registry for .eu technically, we decided to build
an open source registry robot based on EPP.

In various discussions there was formed the idea of another
transport layer for EPP parallel to BEEP and Email. The
new transport layer follows the idea to use an existing document
encapsulation framework. Another advantage is the possibility
for registrars to communicate directly with the registry robot
with a http-client.

The idea is to use http and https, respectively, as an connectionles
protocol contrarious to BEEP. Attached you find a first draft
for EPP over http.

It can be discussed how the authentication, the user identification
for registrars and their resellers (a nice feature), will be handled:
via user specific URI or via http-post method.

It is very important, that the application (EPP) specific tasks
are NOT shifted to the transport layer (<creds> Element see epp 2.4).

Now one of the important things is how the response is handled:
-> the (registry)server establishes a connection to the
   (registrar)server.
   -> the hostname is known by the registry.
   -> the hostname is given by the registrar to the registry
      via EPP, see Cap. 2.6 "Extension Framework"
-> the client (registrar) polls the data. The problem here is,
   that the answer is not expicit assigned to an command. The
   answer to a poll command has the <trId> of the poll command.

Another problem of the poll command is the higher traffic. The
registrar doesn' know when to poll, there are polling in vain,
the other point is that one poll command has three times more
traffic: the poll request, the answer and the acknowledge to
the answer!
I think we have to handle a handshake (not EPP handshake) at
the underlying layer.

Please note that this is work in progress. Some comments?


Regards
Sven-Holger Wabnitz




cut --- cut --- cut --- cut --- cut --- cut --- cut --- cut --- 



         Extensible Provisioning Protocol Transport over HTTP
                       <draft-epp-http-00.txt>


Status of this Memo

  This document is an Internet-Draft and is NOT offered in
  accordance with Section 10 of RFC2026, and the author does not
  provide the IETF with any rights other than to publish as an
  Internet-Draft
  
  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as
  Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other
  documents at any time.  It is inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

Abstract
  
  This document describs how an Extensible Provisioning Protocol (EPP)
  is used over the connection-less Hypertext Transfer Protocol
  (HTTP/1.1). This mapping requires use of the Transport Layer
  Security (TLS) protocol to protect information exchanged between an
  EPP client and an EPP server.

1. Introduction
  
  This document describes how the Extensible Provisioning Protocol
  (EPP) is mapped onto client-server connections using the Hypertext
  Transfer Protocol (HTTP). Security services beyond those described 
  in EPP are provided by the Transport Layer Security (TLS) Protocol
  [RFC2246]. EPP is described in [EPP]. HTTP is described in [RFC2616].

  Both parties the EPP server and the EPP Client will act as a HTTP
  server and a HTTP client. The client will transmit an EPP command 
  by a HTTP request. The HTTP response MUST inform the client about 
  the status of the command transmission. The result code of the 
  command will be delivered over an HTTP request originated by the 
  EPP Server.

  In summary we describe a connection less communication between an
  EPP server and an EPP client without the need of polling the result
  code of the requests.

x. References

  Norminative References

  [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in
  progress.

  [RFC2246] T. Dierks and C. Allen: "The TLS Protocol Version 1.0", RFC
  2246, January 1999.

  [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
  P. Leach, T. Berners-Lee: "Hypertext Transfer Protocol -- HTTP/1.1",
  RFC2616, June 1999. 

cut --- cut --- cut --- cut --- cut --- cut --- cut --- cut --- 


-- 
___________________________________________________________________

Sven-Holger Wabnitz   DSS Gesellschaft fuer Digitale Sicherheit mbH
phone +49 2222 990-0            **             fax +49 2222 990-444
http://www.digital-security.com **            http://www.dominic.de

>From the Portland Pattern Repository (de facto home of the
extreme programming discipline), hosted by Cunningham & Cunningham.

        "Life's too short to write code that nobody wants."

Dies ist ein digital signierter Nachrichtenteil

---