RE: TCP Mapping

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

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:wessorh@ar.com]
Sent: Sunday, June 30, 2002 1:57 AM
To: Liu, Hong
Cc: 'ietf-provreg@cafax.se'
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