Subject: RE: TCP Mapping

From: "Liu, Hong" <[email-masked]>
Date: Sat, 29 Jun 2002 20:27:09 -0500

Rick,

Most (if not all) EPP implementations today use TCP and will stay that way
for a long time. For this matter, we want to make PUSH work using TCP. It is
not a requirement, it is an extension with which we can use PUSH for EPP
over TCP.

I don't think EPP PUSH should be exclusively tied to BEEP. BEEP makes EPP
PUSH easier, and that is it.

I am not sure about smtp since I have not seen the draft yet...

Two questions need to be addressed separately in the discussion:
1. Can EPP PUSH be used for EPP over TCP?
2. How to do the EPP PUSH extension properly for EPP over TCP (or over any
transport)?

I hope we can agree on 1 and focus on 2.  

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[email-masked]]
Sent: Saturday, June 29, 2002 7:40 PM
To: Hollenbeck, Scott
Cc: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong;
[email-masked]'
Subject: RE: TCP Mapping 

I understand how push can work with beep, but why is it a requirement to
work with the tcp transport? also isn't push with smtp only require a
corrdinated mbox?

I'd prefer we not muck with the tcp transport and find a method to get
push to work with all transports or settle on using beep because it is
already prepaired for push style messaging.

-rick

---

From: Rick Wesson <[email-masked]>
Date: Sat, 29 Jun 2002 22:57:20 -0700 (PDT)

On Sat, 29 Jun 2002, Liu, Hong wrote:

> for a long time.

ok, we disagree.

> For this matter, we want to make PUSH work using TCP. It is

why, whats the use case, and why is it worth altering each and every
transport to enable push. we all agreeded along time ago that push work
better in beep.

It would help us all if you gave us some reasoning behind your wishes.

> PUSH easier, and that is it.

nor do I, however beep supports a push model where as our EPP over TCP
doesn't.

> 1. Can EPP PUSH be used for EPP over TCP?

we have learned we shouldn't be altering the EPP over TCP transport to
make it work.

> 2. How to do the EPP PUSH extension properly for EPP over TCP (or over any

over any transport is the preferable objective.

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 30 Jun 2002 07:06:10 -0400

Hong,

> Most (if not all) EPP implementations today use TCP and will stay that way

I'm don't doubt the correctness of your statement concerning the NeuStar
registry and client. I don't do business with NeuStar, or follow it with
any particular interest, so other than what NeuStar contributors disclose
on this list, concerning its implementation or plan of record, I wouldn't
know (and don't care).

I do know that I'm not the sole implementor who has, or is working on, an
implementation of EPP using a BEEP channel profile. I'm surprised to learn
of NeuStar's long-term de-committment from EPP over BEEP -- this month in
particular.

You wrote:
> ... we want to make PUSH work using TCP. It is

Your initial note to this list, and Scott's careful recitation, reflect
that your desire is to modify a transport draft that has no options, and
which itself is not optional in the protocol draft. 

Just how is the NeuStar extension supposed to work?

This way?

	o client implementations communicating with the NeuStar registry
	  MUST NOT ignore the P-BIT,
and
	o client implementations communicating with another registry
          MAY ignore the P-BIT?

Or this way?

	o client implementations communicating with any registry
          MUST NOT ignore the P-BIT?

> 1. Can EPP PUSH be used for EPP over TCP?

Could you suggest a definition for "EPP PUSH" please? I seem to have missed
it.

Eric