RE: TCP Mapping

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

First, I am guilty of making everyone work over the weekend...

Scott, please see my comments in line.

--Hong

-----Original Message-----
From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: Saturday, June 29, 2002 5:47 PM
To: 'Eric Brunner-Williams in Portland Maine'; Liu, Hong
Cc: 'ietf-provreg@cafax.se'
Subject: RE: TCP Mapping 


> (from draft-ietf-provreg-epp-tcp-04.txt)
> 4. Datagram Format
> 
>   The data field of a TCP datagram MUST contain an EPP datagram.  The
>   EPP datagram contains two fields: a 32-bit header that describes
> >	the P-bit (is the message "PUSH" or "PULL")

One big bug with this approach: putting _anything_ specific to this
push/pull thing in the TCP draft is going to cause a problem with BEEP
transport (or any transport other than streaming TCP) because the BEEP draft
(for example) depends on standard BEEP profiles -- not the EPP TCP draft.
If this gets put into the TCP draft, just how is it going to work with BEEP
transport, email transport, or whatever other transport someone might define
in the future?

<HL>
Just want to make sure that I understand correctly. Strictly speaking, BEEP
is not a transport protocol like TCP. It is a shim layer protocol that makes
application framing easier. BEEP by itself also needs to be mapped to a
transport protocol. RFC3081 defines the TCP mapping for BEEP, and I assume
that when we define EPP over BEEP over TCP, it is RFC3081 that is used for
TCP mapping, not draft-ietf-provreg-epp-tcp-04.txt. So I do not see any
problem here.

Later on, we may also define EPP over SCTP. But by the same principle, EPP
over BEEP over SCTP should use the SCTP mapping for BEEP, not the SCTP
mapping for EPP. Not that we want to do so, just another example.
</HL>

Hong has already said (and I'm paraphrasing) that a goal is to make the push
thing work without BEEP.  Well, if it's going to work with any transport the
mechanics can't be put into one of the transport drafts.  It has to be
defined at a higher layer.

<HL>
Yes, indeed. We want to make PUSH work for TCP since this is what we have
today. I see your point here: it would be best if we can define a transport
independent PUSH for EPP. I am still exploring this on the list, using TCP
as a starting point.
</HL>
 
FWIW, assuming this discussion carries past tonight I'm going to have to
pick it up after 8 July; silence != concurrence.  It's time for a little
R&R...

<HL>
Have a good vacation next week. I will be out for the later part of next
week, too. 
</HL>

-Scott-