From: Stephane Bortzmeyer <firstname.lastname@example.org>
Date: Mon, 12 Aug 2002 16:26:37 +0200
Subject: [email@example.com: [open-eu] Open Registry Robot / EPP transport layer]
Sent on a public mailing list of CORE so I assume I can redistribute it.
To: open-eu discuss <firstname.lastname@example.org>
From: Sven-Holger Wabnitz <email@example.com>
Date: 09 Aug 2002 14:05:11 +0200
Subject: [open-eu] Open Registry Robot / EPP transport layerDear 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