Re: [ietf-provreg] Re: EPP over HTTP or simple TCP?

[Eugenio Pinto <eugenio.pinto@fccn.pt>]

Stephane and Klaus,

Thanks for your quick feed-back.

Regarding the TCP transport protocol on RFC 4934 you are right, it was 
my mistake to talk about the "end-code" if we have the leading length field.

However the main reason for my email was the implementation part:

Have you implemented the TCP approach? If so, did you implement a TCP 
server from scratch or you used the source code from a server like Tomcat?

I have already implemented a single threaded TCP server on JAVA that is 
in conformance with RFC 4934 and implements the XML schema validation on 
the received messages.

I think I can use this code to develop a generic JAVA Interface that 
will be in conformance with the core EPP protocol specifications and can 
be used for any EPP server implementation just by extending it's methods.

Is this interesting for you? Have you already a similar interface 
implementation on JAVA or any other programing language that can be 
freely distributed and is already tested in production?

If you have can you send it to this list? I would rather prefer to use 
an already-in-production version of the core server implementation than 
to use my own just released version...

Regards,
Eugenio


Klaus Malorny wrote:
> Stephane Bortzmeyer wrote:
>> On Wed, Oct 31, 2007 at 05:45:43AM +0000,
>>  Eugenio Pinto <eugenio.pinto@fccn.pt> wrote
>>  a message of 21 lines which said:
>>
>>> - A way is to send EPP messages in the body of HTTP requests and
>>> manage HTTP requests with standard code.
>>
>> That's tempting but it violates RFC 3205 and, besides, there is no
>> written specification on EPP-over-HTTP so it will be non-standard.
>
> To my knowledge, there is at least one ccTLD exactly doing this.
>
>>
>>> - Another solution, with less overhead, is to send EPP messages
>>> directly in the TCP stream and add some "end-code" characters to the
>>> end of the message in order for the server to recognize each EPP
>>> message
>>
>> Why adding this end-code when RFC 4934 uses a leading length field?
>>
>> 4.  Data Unit Format
>>
>>    The EPP data unit contains two fields: a 32-bit header that describes
>>    the total length of the data unit, and the EPP XML instance.
>>
>
> I fully agree. RFC4934 is quite simple so that there is no real reason 
> why to invent other supposed "simple" transport mechanisms, including 
> the use of HTTP(S), for new implementations.
>
> Regards,
>
> Klaus
>