Subject: RE: TCP Mapping

From: "Liu, Hong" <[email-masked]>
Date: Sun, 30 Jun 2002 10:16:42 -0500

Rick,

I would like to clarify a couple of points here:

First, the work on EPP PUSH over TCP is complimentary to that for BEEP. I
like BEEP and we all agree it is easier to use BEEP for EPP PUSH. But that
by itself should not exclude others from using the same capability over TCP.
Are you insisting that if one wants to support PUSH, s/he MUST use BEEP?
Please clarify. I personally prefer to leave it open and let the market
decide what to use in real life operations.

Second, if your objection to this work is about making changes to the Total
Length field in TCP mapping to support EPP PUSH, I hear your point and I am
open to it. The whole objective for me bringing this topic to the list is to
get feedback from you and others on what the best technical solution is to
support EPP PUSH over TCP. So far, I see the WG (from those who spoke out)
seems to lean towards developing this capability independent of the
underlying transport. If that is the way to go, we will do it.

So, do you support developing the EPP PUSH extension without changing the
Total Length field in the TCP mapping? I just need to confirm your opinion.

Cheers,

--Hong

-----Original Message-----
From: Rick Wesson [mailto:[email-masked]]
Sent: Sunday, June 30, 2002 1:57 AM
To: Liu, Hong
Cc: [email-masked]'
Subject: RE: TCP Mapping 

[snip...]

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

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

> 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?

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
> transport)?

over any transport is the preferable objective.

-rick

---

From: Rick Wesson <[email-masked]>
Date: Sun, 30 Jun 2002 08:57:10 -0700 (PDT)

Hong,

> I see the WG (from those who spoke out) seems to lean towards
> developing this capability independent of the underlying transport. If
> that is the way to go, we will do it.

yes, I agree with you here.

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 30 Jun 2002 18:23:39 -0400

Hong,

How is your extension supposed to work?

Exactly what do you mean by "EPP PUSH"?

Eric

------- Forwarded Message

Hong,

You wrote:

> Most (if not all) EPP implementations today use TCP and will stay that way
> for a long time.

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
> not a requirement, it is an extension with which we can use PUSH for EPP
> over TCP.

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

------- End of Forwarded Message