Subject: [provreg] draft-wullink-restful-epp-00.txt

From: Miek Gieben <[email-masked]>
Date: Mon, 23 Apr 2012 12:51:48 +0200

Hello,

[I've cross posted this also to [email-masked]]

SIDN, being the registry for .nl, employs EPP as the primary interface for
registrars to submit or manipulate domain names. Even though the protocol is
working quite well, at SIDN Labs we believed there was room for improvement.

Experience over the years revealed certain operational shortcomings in EPP,
mainly related to the stateful nature of the protocol:

* EPP may pose challenges in load-balanced environments, when a active session
  has to be switched from one EPP server to another and state is kept on a per
  server basis.

* EPP sessions can wind up in a state where they are no longer linked to an
  active TCP connection. This may raise problems in situations where session
  limits are enforced.

Our draft http://www.ietf.org/id/draft-wullink-restful-epp-00.txt
aims to solve these issues, by proposing a RESTful EPP interface.

The Abstract reads:

       This document specifies a 'RESTful interface for EPP' (REPP) with the    
       aim to improve efficiency and interoperability of EPP systems.           

       This document includes a new EPP Protocol Extension as well as a mapping 
       of [RFC5730] XML-commands to an HTTP based (RESTful) interface. Existing 
       semantics and mappings as defined in [RFC5731], [RFC5732] and [RFC5733]  
       are largely retained and reusable in RESTful EPP.                        

       With REPP, no session is created on the EPP server. Each request from    
       client to server will contain all of the information necessary to        
       understand the request. The server will close the connection after each  
       HTTP request.                                                            

As the provreg WG is dormant, we have submitted our draft as an individual
submission.

Since the provreg mailinglist is still very much alive, we are kindly requesting
its subscribers to provide us with feedback on our proposal.

Kind regards,

--

 Miek Gieben
 SIDN Labs

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Apr 2012 11:09:39 +0000

Miek,

As I said in our off-list email exchange a few weeks ago, this document describes something that is "EPP-like" as opposed to an extension of EPP.  The document should make that point clear.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Miek Gieben
> Sent: Monday, April 23, 2012 6:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [provreg] draft-wullink-restful-epp-00.txt
> 
> Hello,
> 
> SIDN, being the registry for .nl, employs EPP as the primary interface
> for registrars to submit or manipulate domain names. Even though the
> protocol is working quite well, at SIDN Labs we believed there was room
> for improvement.
> 
> Experience over the years revealed certain operational shortcomings in
> EPP, mainly related to the stateful nature of the protocol:
> 
> As the provreg WG is dormant, we have submitted our draft as an
> individual submission.
> 
> Since the provreg mailinglist is still very much alive, we are kindly
> requesting its subscribers to provide us with feedback on our proposal.
> 
> Kind regards,
> 
> --
> 
>  Miek Gieben
>  SIDN Labs

---

From: Miek Gieben <[email-masked]>
Date: Mon, 23 Apr 2012 13:28:13 +0200

[ Quoting <[email-masked]> in "RE: [provreg] draft-wullink-restful..." ]
> Miek,
> 
> As I said in our off-list email exchange a few weeks ago, this document
> describes something that is "EPP-like" as opposed to an extension of EPP. The
> document should make that point clear.

Yes, we (try to) do that. The problem is that EPP is *defined* as being
stateful, which is clearly something we break.

Regards,
    Miek Gieben

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Apr 2012 11:37:00 +0000

> Sent: Monday, April 23, 2012 7:28 AM
> To: [email-masked]
> Subject: Re: [provreg] draft-wullink-restful-epp-00.txt
> 
> > As I said in our off-list email exchange a few weeks ago, this
> > document describes something that is "EPP-like" as opposed to an
> > extension of EPP. The document should make that point clear.
> 

It's more than just the stateful/stateless change. While you're reusing the XML data structures, the command and response syntax is different. The command and response processors of an existing server-side implementation will need to be changed significantly to implement this mapping.

Scott

---

From: Miek Gieben <[email-masked]>
Date: Mon, 23 Apr 2012 13:45:13 +0200

> It's more than just the stateful/stateless change. While you're reusing the
> XML data structures, the command and response syntax is different. The command
> and response processors of an existing server-side implementation will need to
> be changed significantly to implement this mapping.

Yep, that's true. But those command and reposonse processors do become a lot 
simpler with REPP.

Regards,
Miek Gieben

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Apr 2012 12:42:43 +0000

This is the first time that I've heard of challenges in load-balanced
environments or EPP session state not being linked to an active TCP
session.  Can you go into more detail of these issues?  I've been involved
with many EPP-based systems through the years and I've never come across
any of these issues.  This goes to the heart of the reliability of
stateful TCP sessions, which is used with many other protocols.  It would
be good to discuss the problems posed prior to consideration of a new
stateless version of EPP on top of REST.

--
  
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 4/23/12 6:51 AM, "Miek Gieben" <[email-masked]> wrote:

>EPP,
>requesting
>_______________________________________________
>provreg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/provreg

---

From: Maarten Wullink <[email-masked]>
Date: Mon, 23 Apr 2012 14:02:55 +0000

Stateless EPP makes it possible to load balance individual EPP requests instead of
EPP connections. This should make it easier to distribute to load evenly across the servers.
Distributing tcp connections across EPP servers does not guarantee an equal load on every server. This
is because not all EPP connections are equal.

Also when there is no persistent tcp connection it should be easier to remove
a server from the server pool for maintenance without having to disconnect the tcp connections of the
clients connected to the server.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gould, James
Sent: maandag 23 april 2012 14:43
To: Miek Gieben; [email-masked]
Cc: [email-masked]
Subject: Re: [provreg] draft-wullink-restful-epp-00.txt

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: "Michael Young" <[email-masked]>
Date: Mon, 23 Apr 2012 10:18:41 -0400

I can see this argument  with a high velocity, high volume system, however
load-balancing via TCP sessions is a trivial issue with a domain or number
registry and individual traffic flows are commonly handled through packet
shapers these days.  Add in some policy driven rate-limiting and you are
more than covered.

Now don't assume I am negative on innovating, quite the opposite, I'd love
to see us being progressive however I am not sure I see any distinct benefit
to moving to a stateless EPP.  

It would help if you could build a list of pros and cons for stateless EPP
and also describe the trust model you would use for the source traffic - so
we can understand how the current solution stacks up against what you are
proposing.

Best Regards,

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Wullink
Sent: April-23-12 10:03 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [provreg] draft-wullink-restful-epp-00.txt

Stateless EPP makes it possible to load balance individual EPP requests
instead of EPP connections. This should make it easier to distribute to load
evenly across the servers.
Distributing tcp connections across EPP servers does not guarantee an equal
load on every server. This is because not all EPP connections are equal.

Also when there is no persistent tcp connection it should be easier to
remove a server from the server pool for maintenance without having to
disconnect the tcp connections of the clients connected to the server.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gould, James
Sent: maandag 23 april 2012 14:43
To: Miek Gieben; [email-masked]
Cc: [email-masked]
Subject: Re: [provreg] draft-wullink-restful-epp-00.txt

This is the first time that I've heard of challenges in load-balanced
environments or EPP session state not being linked to an active TCP session.
Can you go into more detail of these issues?  I've been involved with many
EPP-based systems through the years and I've never come across any of these
issues.  This goes to the heart of the reliability of stateful TCP sessions,
which is used with many other protocols.  It would be good to discuss the
problems posed prior to consideration of a new stateless version of EPP on
top of REST.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 23 Apr 2012 16:20:04 +0200

> clients connected to the server.

Hi all,

while I have mixed feelings regarding the REST approach, I agree to the arguments:

Although RFC 5734 allows the server to actively terminate the communication with 
the client, it can only do this by closing the connection. There is no graceful 
shutdown that would allow the client to prevent an I/O error on the attempt to 
write a message. Assuming a busy connection, the sudden interruption leaves the 
client in an ambiguous state whether the (partially) transmitted request has 
been received and processed by the server.

For the benefit of the registrars, we avoid to close connections in our server 
side EPP implementation except for those connections which are idle over a long 
period. As a consequence, in a load balanced configuration, the balancing can 
actually only occur via the assignment of new connections to the server with the 
lowest load, so an unequal load cannot easily be leveled.

Regards,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Apr 2012 10:45:10 -0400

On Mon, Apr 23, 2012 at 02:02:55PM +0000, Maarten Wullink wrote:

> Stateless EPP makes it possible to load balance individual EPP
> requests instead of EPP connections.

"Stateless N makes it possible to treat formerly-stateful protocol N
statelessly."  Yes, obviously.  The question is partly whether that is
a good idea, & I'm not sure I see what the argument is there.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Michael Young" <[email-masked]>
Date: Mon, 23 Apr 2012 10:49:01 -0400

See my earlier email Klaus but there's no reason why you can't terminate a
connection based on a policy for permitted packet flows - so I still don't
see this as any kind of a significant problem.  You do have to use a
persistent connection algorithm when using a load-balancer, however with
packet-shapers you can set policies on the maximum flow rate per connection
or even across a group of connections.  In short, you are expecting the
client to take some responsibility for not hammering the server within a
single connection and limiting them if they do.  I don't see valid use case
where a single EPP connection operating against today's equipment and
environs would need to apply an excessive amount of load for a server in the
course of any normal registry business. If you know of one, I'd love to know
about it.

Namedrop behaviours of course are another special use case, but segmented
special connection pools and rate-limiting have typically solved that one as
well.  The scope of the namedrop server hammering was also reduced by the
now active secondary marketplace that occurs prior to a name being dropped
in the first place.

Best Regards,

Michael Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Klaus Malorny
Sent: April-23-12 10:20 AM
To: Maarten Wullink
Cc: [email-masked]; [email-masked]
Subject: Re: [provreg] draft-wullink-restful-epp-00.txt

On 23/04/12 16:02, Maarten Wullink wrote:
> requests instead of EPP connections. This should make it easier to
distribute to load evenly across the servers.
> Distributing tcp connections across EPP servers does not guarantee an 
> equal load on every server. This is because not all EPP connections are
equal.

Hi all,

while I have mixed feelings regarding the REST approach, I agree to the
arguments:

Although RFC 5734 allows the server to actively terminate the communication
with the client, it can only do this by closing the connection. There is no
graceful shutdown that would allow the client to prevent an I/O error on the
attempt to write a message. Assuming a busy connection, the sudden
interruption leaves the client in an ambiguous state whether the (partially)
transmitted request has been received and processed by the server.

For the benefit of the registrars, we avoid to close connections in our
server side EPP implementation except for those connections which are idle
over a long period. As a consequence, in a load balanced configuration, the
balancing can actually only occur via the assignment of new connections to
the server with the lowest load, so an unequal load cannot easily be
leveled.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Apr 2012 16:26:09 +0000

In reading the messages it looks like the two issues with the stateful TCP
session raised include:

1. EPP may pose challenges in load-balanced environments - What has been
raised is load-balancing on a per-command basis instead of a
per-connection basis.  Load balancing the connections distributes the load
fine today.  If there is a need to load balance on a per command basis,
you can keep the state in the gateways and load balance the requests to a
tier of stateless application servers.  The same thing can be done on a
per command type basis, by having the gateways send the commands to the
different set of backend application servers.  The gateways are typically
the least utilized in this scheme, so spreading the load on them doesn't
really solve any problems.  A case was made that stateless would improve
performance, but I believe it will greatly decrease the performance.  I'm
assuming that the security elements still apply (2-way SSL as well as
authentication) which would need to be done on a per-command basis in the
stateless model.  Creating of the 2-way SSL connection even with SSL
session resumption will add a lot of extra overhead on a per command
basis.  Passing the user credentials to authenticate the user on a per
command basis will also add a lot of extra overhead.  Can someone describe
how these elements will be mitigated in a stateless model?  Overall, I
don¹t see how moving from stateful to stateless will benefit either the
client or the server from a performance or load perspective.
2. EPP sessions can wind up in a state where they are no longer linked to
an active TCP session - Can someone describe this issue?

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 4/23/12 11:09 AM, "Rubens Kuhl" <[email-masked]> wrote:

>
>Stateless requests also allow for having different pools of servers for
>different types of requests. For instance, mapping "domain info" to
>servers on a read-only database and "domain create" to servers with write
>access to the database. Can improve performance, security, or both.
>
>
>Rubens
>
>
>On Apr 23, 2012, at 11:02 AM, Maarten Wullink wrote:
>
>>instead of
>>equal load on every server. This
>>remove
>>Behalf Of Gould, James
>>>for
>>> registrars to submit or manipulate domain names. Even though the
>>>protocol
>>> is
>>> * EPP sessions can wind up in a state where they are no longer linked
>>>to
>>> an
>>>individual
>> regops mailing list
>> [email-masked]
>> http://nlnetlabs.nl/mailman/listinfo/regops
>
>
>regops mailing list
>[email-masked]
>http://nlnetlabs.nl/mailman/listinfo/regops

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 23 Apr 2012 10:05:36 -0700

You could initiate a session with a RESTful server, just like most websites work:

- You will use a RESTful URL to create a session: /session/user_id [POST]

- The server would return a cookie, which you will return with every RESTful request.

- When you're done processing requests you can: /session/user_id [DELETE]

The advantage of this model, is that you can use the existing knowledge on how to scale web-services and apply them to Registry-Registrar interactions.

Francisco

On Apr 23, 2012, at 9:26 AM, Gould, James wrote:

> Passing the user credentials to authenticate the user on a per

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 23 Apr 2012 12:09:36 -0300

Stateless requests also allow for having different pools of servers for different types of requests. For instance, mapping "domain info" to servers on a read-only database and "domain create" to servers with write access to the database. Can improve performance, security, or both. 

Rubens

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Apr 2012 17:57:39 +0000

Francisco,

So your proposal is to make it stateful based on the HTTP session?  This
would mitigate the authentication per command issue; although it is
switching the discussion from stateless back to stateful.  There is still
the connection establishment overhead (2-way SSL) that will decrease the
performance.  Do you have a proposal to mitigate that?  Is there an
perceived problem in scaling registry services that needs to be solved and
if so can you provide any details?  I believe that the registries have
shown that EPP can scale without the need to add HTTP to the stack.  We
defined and used an EPP HTTP transport for over 6 years, which did allow
for scaling the server-side using standard web scaling techniques.  HTTP
keep-alive was used to maintain the EPP session with the server.  EPP TCP
did perform better since it didn't include the HTTP overhead in the stack.
 The EPP HTTP transport was lightly used since the preference was to use
EPP TCP, but this is an option to consider.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 4/23/12 1:05 PM, "Francisco Obispo" <[email-masked]> wrote:

>The advantage of this model, is that you can use the existing knowledge
>on how to scale web-services and apply them to Registry-Registrar
>interactions.
>
>Francisco
>
>
>
>

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 23 Apr 2012 11:32:57 -0700

> So your proposal is to make it stateful based on the HTTP session?  This

Yes, you can keep HTTP-session information in a shared way across multiple servers (memcached, SQL-db, etc). so you can have any front-end server vailidate it.

Clients can keep the connection (or session) alive by issuing commands periodically.

> performance.  

On the client side, you could have pre-cached connections with multiple servers.

> Do you have a proposal to mitigate that?  Is there an

I guess something like this could be implemented with EPP (over TCP), by building an extension to deal with the session information:

1) EPP <login> authenticates and generates a cookie (stored in a shared system) 
   that gets sent in the <extension> section
2) Subsequent requests are validated with that cookie
3) EPP <logout> destroys the cookie on the server side.

That way, clients could contact any EPP server in you pool, and get service by showing a valid session cookie.

Francisco

Francisco Obispo 
email: [email-masked]

---

From: Miek Gieben <[email-masked]>
Date: Mon, 23 Apr 2012 20:52:27 +0200

[ Quoting <[email-masked]> in "Re: [provreg] [Regops]  draft-wulli..." ]
> Yes, you can keep HTTP-session information in a shared way across multiple
> servers (memcached, SQL-db, etc). so you can have any front-end server
> vailidate it.
>

Interesting twist :)

Reading the other comments, I get the feeling that: Yes, EPP over REST is
an interesting idea, but we overcame all (alleged) shortcomings of EPP by
implementing sophisticated load balancing techniques.

To us EPP over REST is a simplification over EPP and makes stuff possible 
without resorting to load balancers. Also EPP over REST is relatively easy
to implement as HTTP/REST module exist for numerous languages.

Kind regards,
Miek Gieben

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Mon, 23 Apr 2012 21:07:42 +0200

Op 23-04-12 18:26, Gould, James schreef:

> Load balancing the connections distributes the load fine today. 

Sure, but what happens with an existing EPP-session when one of the
application servers suddenly becomes unavailable?

> If there is a need to load balance on a per command basis,
> you can keep the state in the gateways

Yes, but that implies more complexity on the gateways/loadbalancers.

Besides that, we noticed there are quite a lot of registrars using a
'login-command-logout' sequence for every request they wish to make.
That is, in our view, less efficient than simply issuing one RESTful
request each time.

> an active TCP session - Can someone describe this issue?

We've encountered a number of scenario's where clients ran into their
session limits unexpectedly. I remember one case where the client forgot
to send a <logout>, but that is off course their problem. There are also
scenario's where a flaky TCP connection or buggy client messes things
up. Every so often this results in questions to our supportdesk.

--
Marco

---

From: Maarten Wullink <[email-masked]>
Date: Mon, 23 Apr 2012 19:25:16 +0000

Using HTTP as an additional protocol does add more overhead. requiring the
use of SSL adds even more overhead. I am not quite sure how to mittegate this.

However, using HTTP/REST does allow for a more efficient transport of request and
response data. For some requests there is no need for a request XML message because the
resource URL combined with an HTTP method is sufficient. The same goes for some
response messages. e.g. for the object check response, returning a couple of http headers
instead of a complete EPP xml message makes it more efficient.

The client and the server have to spend much less time creating, validing, marshalling etc of XML messages.
Maybe this will mittegate some of the added overhead, we have not done any measurements but i am
interested in such results. 

________________________________________
Van: Gould, James [[email-masked]]
Verzonden: maandag 23 april 2012 18:26
To: Rubens Kuhl; Maarten Wullink
Cc: [email-masked]; [email-masked]
Onderwerp: Re: [Regops] [provreg] draft-wullink-restful-epp-00.txt

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Apr 2012 21:46:47 +0000

> application servers suddenly becomes unavailable?

It depends where the state is held (gateway or application server).  If
the application server is stateless, than nothing happens to the EPP
session.  If the application server is stateful, then hopefully the
gateway will recognize the dropped application server connection and will
in turn close the client connection.

> Yes, but that implies more complexity on the gateways/loadbalancers.

Load balancing behind the gateways is just one option, but you are correct
that it adds complexity.

> That is, in our view, less efficient than simply issuing one RESTful

We see this as well, but there are another set of registrars that keep
long running EPP sessions that get the benefit of stateful sessions.  A
best practice is to keep a pool of long running sessions for the best
performance.  

> up. Every so often this results in questions to our supportdesk.

You're going to most likely have some sort of server policy on load
(connections, bandwidth) in either event that can result in
troubleshooting and questions to customer support.  I'm not sure if
stateless versus stateful will help reduce the server policies and
subsequently the troubleshooting.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Luis Muñoz <[email-masked]>
Date: Mon, 23 Apr 2012 17:47:44 -0400

On Apr 23, 2012, at 1:57 PM, Gould, James wrote:

> There is still

I don't think there's a way to completely get rid of this. A new TCP session will need to be created (or existing connections from a pool could be multiplexed).

Still this proposal could be a big win in performance.

-lem

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Apr 2012 22:21:56 +0000

What is the basis of the claim that the proposal could be a big win in
performance?  What is the fundamental performance issues today with EPP
TCP and how does REST over HTTP solve it?  I heard that stateless will
provide benefits, but with SSL and authentication the approach needs to
move to a stateful (RESTful login and HTTP keep-alive) model.  I heard
that there can be load balancing done per command instead of per
connection, but per command load balancing can be accomplished today
behind the gateways and there is a question of whether the gateway tier
itself is a problem area from a performance and scalability perspective.
I heard that existing knowledge to scale web-services can be utilized, but
the registries already have knowledge on scaling EPP services.  I don't
see performance and scalability as a key driver for a new provisioning
protocol.  Is there another driver for this proposal?
 
--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 4/23/12 5:47 PM, "Luis Muñoz" <[email-masked]> wrote:

>I don't think there's a way to completely get rid of this. A new TCP
>session will need to be created (or existing connections from a pool
>could be multiplexed).
>

---

From: Luis Muñoz <[email-masked]>
Date: Mon, 23 Apr 2012 18:29:39 -0400

The fact that you can more efficiently pool connections will in many scenarios allow you to get away with less connections that are more long lived and potentially, with less authentications.

Per command load balancing also removes the need to have gateways rerouting the requests. This function now is easier to "flatten" into the frontend.

Of course I suppose mileage will carry.

-lem

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 24 Apr 2012 16:25:08 +0800

You mean cookie based session? 

Is the cookie stored on the client side or included in the http header or
url for every request?
In the first case, if the cookie is disabled by the client, does it still
work? If the second case, things like header or url length limit, replay
attack may cause problems.

Or we can generate and manage the authentication information by ourselves,
so creating sessions is not necessary.

Linlin Zhou
CNNIC

> Of Francisco Obispo
> Sent: Tuesday, April 24, 2012 1:06 AM
> To: Gould, James
> Cc: [email-masked]; [email-masked]; Rubens Kuhl
> Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt
> 
> 
> - The server would return a cookie, which you will return with every
RESTful
> request.
> The advantage of this model, is that you can use the existing knowledge on
how
> to scale web-services and apply them to Registry-Registrar interactions.
> 
> Francisco
> 
> 
> 
> 
> > Passing the user credentials to authenticate the user on a per command
> > basis will also add a lot of extra overhead.  Can someone describe how
> > these elements will be mitigated in a stateless model?  Overall, I
> > don¹t see how moving from stateful to stateless will benefit either
> > the client or the server from a performance or load perspective.
> 
> Francisco Obispo
> email: [email-masked]
> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
>

---

From: Klaus Malorny <[email-masked]>
Date: Tue, 24 Apr 2012 10:31:09 +0200

On 23/04/12 19:05, Francisco Obispo wrote:
> how to scale web-services and apply them to Registry-Registrar interactions.
>
> Francisco
>
>

Hi,

if you are using cookies, so why use REST at all? AFAIK, multiple ccTLDs use 
proprietary implementations of EPP over HTTP(S). These use more or less POST 
requests to a static URL, containing the command as the POST data and the 
response in the HTTP response body (hello/greeting, login and logout 
accordingly). Session state is maintained by cookies. It does not require any 
changes to the base protocols (RFCs 5730-5733) and also avoids my personal 
disfavoured REST concepts of giving up the self-containedness of the payload and 
using different payload formats for requests and responses (which occur to the 
lesser extent in the proposed standard). So IMHO it would be better to focus on 
the standardization of the existing flavours if there is a demand of an 
HTTP-based transport layer.

Klaus

---

From: Maarten Wullink <[email-masked]>
Date: Tue, 24 Apr 2012 09:42:24 +0000

Using a static URL and the http POST method to submit EPP XML messages will work fine.
But I think using REST will help in creating an easier to use EPP API.

As mentioned before, when using REST the EPP request message is optional for
commands like check, delete and info. These will (in most cases) no longer require a request EPP message.
The URL and HTTP method provide all the required information to perform the request.
(the authentication info can be transmitted with Authorization: Basic header)

"multiple ccTLDs use proprietary implementations of EPP over HTTP(S)."
I am interested to know which ccTLDs have such a implementation and what their experiences are.

Example domain name info:

Rest style

GET /domains/example.com

VS plain http POST

POST /command [postdata = epp xml domain name info request]

Personally I like the REST style more, no need for XML request message and informational URL.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Malorny
Sent: dinsdag 24 april 2012 10:31
To: [email-masked]; [email-masked]
Subject: Re: [provreg] [Regops] draft-wullink-restful-epp-00.txt

Hi,

Klaus

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Apr 2012 07:12:15 -0400

> But I think using REST will help in creating an easier to use EPP API.

To emphasise what Scott already pointed out, it's not going to create
an "easier to use EPP API".  It's going to create a new protocol, sort
of like EPP.

Normally, what we hear is how difficult it is to deal with the
plethora of extensions -- the tiny differences in the various
extensions make everything too hard for registries and registrars
alike.  (Given some servers' carelessness with their namespaces,
actually, this isn't that surprising.  The greeting turns out to be a
crummy guide to the extensions actually on offer in many deployed
implementations.)  I'm finding it a little hard to believe that it
will be easier to solve this problem by ditching EPP in favour of a
completely new protocol with a new set of such challenges.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 24 Apr 2012 12:45:30 +0000

Our EPP HTTP transport included the following:

1. Client sends an HTTP GET
2. Server returns the EPP Greeting with session cookie in the header
(JSESSIONID)
3. Client sends command with HTTP POST and the session cookie as an HTTP
header
4. Server returns EPP Response

This is done in a 2-way SSL connection similar to the EPP TCP transport
and HTTP keep-alive was used to maintain the stateful connection.  We
stopped supporting the EPP HTTP transport.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 4/24/12 4:31 AM, "Klaus Malorny" <[email-masked]> wrote:

>> You could initiate a session with a RESTful server, just like most
>>websites
>> work:
>>
>>on