RE: TCP Mapping

[Rick Wesson <wessorh@ar.com>]

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


On Sat, 29 Jun 2002, Hollenbeck, Scott wrote:

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