Subject: RE: TCP Mapping

From: "Hollenbeck, Scott" <[email-masked]>
Date: Sat, 29 Jun 2002 17:47:10 -0400

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

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.

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

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 29 Jun 2002 18:59:19 -0400

I'm still trying to figure out what the P-bit is in the <greeting>.

I wouldn't expect the editors of the WG beep draft to pay any attention
to anything but the consensus of the WG, and I don't expect the WG to 
stuff signaling into the length field.

---

From: Rick Wesson <[email-masked]>
Date: Sat, 29 Jun 2002 16:40:18 -0700 (PDT)

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