EPP PUSH: Session Setup Semantics

["Liu, Hong" <Hong.Liu@neustar.biz>]

Hi, all,

Now that we are moving towards developing a transport neutral EPP PUSH
capability, I would like to ping the list on some design choices at hand.

The first issue comes to mind is what we mean by setting up a session that
the server can push data to the client. To set the context, I reiterate the
EPP session setup procedure in my previous email. I will use the terms
"server" and "client" as defined in the base EPP.

1. Upon  successful connection establishment, the server sends a <greeting>
message to the client, advertising its intent to support EPP PUSH in the
this EPP session. This is done by supplying the EPP PUSH URI as an <extURI>
value within the <svcExtension> field.
2. The client responds with a <login> command. The client includes the EPP
PUSH URI as an <extURI> value within the <svcExtension> field if and only if
it agrees to support EPP PUSH in this session.
3. The server responds to the <login> command.

If the client logins successfully, the EPP session is established AND both
the server and the client are in sync about whether this session can be used
for server-pushed data or not. Here is the potential ambiguity I would like
to resolve.

Suppose both the server and the client agree on supporting EPP PUSH in this
session, there are two possible semantics:
a. Push-only semantics. The session can only be used for server-pushed
messages. The client cannot use <poll> in this session to retrieve messages
from the server.
b. Mixed semantics. Both server-push and client-poll are allowed.
In both cases, I think it is reasonable to assume that other EPP commands
and responses are allowed.

Which semantics should we pick, (a) or (b)? 
Is this a registry policy issue or a standardization issue?

Cheers,

--Hong