RE: Message Pushing and TCP Transport

["Bason, Chris" <cbason@verisign.com>]

Would someone please elaborate on why this push concept 
is advantageous to EPP (preferably a PUSH proponent)? 

I apologize if this is redundant but I was not at the
IETF meeting and would like to hear the justification
for putting this into the protocol.

Chris Bason


-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Tuesday, August 14, 2001 8:01 AM
To: 'ietf-provreg@cafax.se'
Subject: Message Pushing and TCP Transport


Discussion requested:

One of the items to come out of last week's provreg meeting was a desire to
add message push features to the base EPP specification so that clients and
servers can negotiate the preferred message delivery method.  Text to be
added to the base spec is fairly straight-forward; I'll work that out with
Eric.

A more complex situation arises when we consider how to support message
pushing with TCP transport (no snide remarks from the BEEP proponents,
please).  Right now we've specified use of a single TCP port for exchanging
commands and responses; the addition of message pushing means that the
"client" end should be willing and able to receive unsolicited messages from
the "server".

This can be accomplished using a single port, but it may be easier to do
using two ports in a fashion similar to the way ftp works.  As the "server"
needs to push messages within the bounds of an established session, it can
open a connection to the "client" on the second port, push the data, and
close the connection.

Anyway, I'd like to get a feel for how folks would like to see this
specified.  I'd like to add it to the TCP draft as REQUIRED if you intend to
do message pushing, but not used is message pushing isn't used.

<Scott/>