RE: TCP Mapping

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

Scott, Eric,

Thanks to both for contributing. That is exactly what I am looking for, -:)

Please see my comments below, tagged with <HL/>. I don't know how to make my
outlook produced a unix-like response with embedded > for preceding email
text.

> Hong and I have already exchanged private messages on this topic.  I'll
> repeat what I said here.

So ... Did you decide mutually to re-conduct the prior private exchange
on an IETF list?

<HL>
That was my understanding. The issue is of general interest, and I would
like to get more feedback on the list.
</HL>

[snip...]

> Second, I'm very much against putting application-layer semantics into the
> layer above TCP -- it smells like a layering violation to me.  I
explicitly
> added an <extension> element as a child of the <epp> element to support
> adding features like data pushing from the "server" -- that's where I
think
> such extensions belong.  Plus, it's not wise to believe that EPP messages
> aren't likely to exceed a certain length based on experiences with domain
> name provisioning.  There may well be other operating environments where
all
> 32 bits (and maybe even more -- I gave some serious thought to a 64-bit
> length field in the header) are needed.  Being short-sighted now means
we're
> going to have issues in the future.

The proposal was vague, no delta of schema, no delta of text. That said, the
proposal revisited the Ethernet vs 802.3 overloading of type-as-length. 

No thanks.

<HL> 
So Eric, you are for Scott's proposal to use the <extension> child element
for defining the PUSH. Am I getting it right? Maybe you could expand on this
topic a bit more... Indeed, this is the most important choice to make for
our draft at the moment: how to tag a server-pushed message? Other issues
will follow once we get this straightened out.

If we adopt Scott's proposal, we may just define a new <push> command, a
response, and possibly a few new respond code. The new command will be from
the server to a client, which will break the base EPP model a bit. Are we
going in this direction?
</HL>

> Third, this whole pushing thing may be a better candidate for
implementation
> using BEEP.  If that's true, it doesn't belong in the TCP draft at all.

Actually, the peer- vs client- (event model) isn't dependent upon the
transport protocol (tcp or beep/{tcp,...}, but ... pragmatically, it doesn't
belong in any draft grounded on working group consensus -- unless most
everyone actually contributing have had a profound change of mind.

<HL> 
I don't think PUSH should be tied to BEEP exclusively either, though BEEP
makes it easier to implement PUSH. Since most of the EPP implementation
today are built upon TCP, we choose to tackle this problem with TCP in mind.
Ideally, we should try to separate the PUSH mechanics from the underlying
transport, as Eric said. Then we address how PUSH can be realized on top of
TCP, BEEP or other transports yet to be defined for EPP, just like what we
have done with the base EPP protocol. This may turn out to be the case in
our draft, but right now we use TCP as a starting point.
</HL>

> I've already started work on a draft document describing how to properly
> extend the protocol, and I expect -00 to be ready some time after the
> Yokohama meeting.  I think it will be far easier to deal with extension
> drafts _after_ we have the mechanics documented a bit better.

Good.

<HL> Yes, this certainly will help! </HL>