Subject: RE: TCP Mapping

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 28 Jun 2002 19:48:55 -0400

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

First, I do expect to have to edit the TCP draft slightly to address some
comments I received from members of the IESG.  That won't happen until after
IETF-54.

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.

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.

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.

-Scott-

> -----Original Message-----
> From: Liu, Hong [mailto:[email-masked]]
> Sent: Friday, June 28, 2002 5:55 PM
> To: [email-masked]'
> Subject: TCP Mapping
> 
> 
> Scott,
> 
> I would like to know whether it is still possible to make 
> changes to the TCP
> mapping document at this point. We have been working on a 
> draft for EPP TCP
> PUSH extension, as we promised before. Sorry, we missed the 
> -00 deadline
> this time...
> 
> There are a number of ways to do it, but we find it the 
> simplest to use the
> Total Length header of the EPP datagram in the TCP mapping to 
> differentiate
> the server-pushed message from other messages. We are 
> considering using only
> the highest bit in the header, but maybe a better way is to 
> reserve the
> highest octet for other extensions. EPP messages do not need 
> 2^32-1 octects,
> 2^24-1 should be sufficiently large. What do you think?
> 
> We would also like to hear from you and others on the list about other
> alternatives. Thanks!
> 
> --Hong
>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 28 Jun 2002 22:19:34 -0400

> Hong and I have already exchanged private messages on this topic.  I'll

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

> comments I received from members of the IESG.  That won't happen until after

If the comments from non-contributor IESG reviewers are editorial in nature,
then the editorial delta is a non-event. If they are substantive in nature,
say replace tcp with sctp (example of substantive proposed change), then the
contributors need to determine if there is consensus to adopt any of the
changes.

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

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

> drafts _after_ we have the mechanics documented a bit better.

Good.

Cheers,
Eric