Re: TCP Mapping

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Hong,

You've answered a flow-control (dualing endpoints flipping P-BITS) query.

You've answered a payload (same as <poll> elements, and unspec else) query.

For reasons I'm unclear on, your comments across several items of mail
suggest that these are mutually exclusive mechanisms for "tagging" some
"server-pushed message". (See also "careful reading" below).

Am I correct in guessing that if your preferred method of signaling (P-BIT)
is the mechanism, that the payload data could be marked up as <poll> data,
with some as yet unspecified additional content?

To correctly decode <poll>, a client would have to first determin the value
of P-BIT?

Or is XML even present in the P-BIT signaled payload data?

A question I don't seem to have seen answered is how you are proposing
to modify a transport draft that has no options, and which itself is not
optional in the protocol draft. 

Are the properties you've described unique to implementations that elect
to implement them (MAY), or are they common to all implementations (MUST)?

There are business reasons why a client implementation of 6/4 over tcp
wouldn't connect to a NeuStar server implementation of 6/4. Are there also
technical reasons why the same two implementations couldn't be capable of
error-free interoperation?

There has been prior discussion of a <push> command.

Looking back over your messages I see that I wasn't carefull enough reading.
I missed the fact that you proposed to use 8 bits to signal directionality,
not one (mail of 28 June). Either that mail, or your reply to my edit of
tcp-04 (mail of 29 June), which referenced a single bit, but not both, can
be correct.

Which is it? 8 bits, or 1 bit? If 8 bits, are the remaining 7 bits "reserved"
for some future signaling or differentiation mechanism, or are they "don't
care" (ignore)?

Eric