Re: Some questions related to "last segment" of a ddp message

On Jan 24, 2004, at 1:34 PM, Barry Reinhold wrote:

> Pat,
> 	Although I don't consider myself a conservative, the
> interpretation of the specification here is starting to get too liberal
> for my taste. (Sorry, it's primary time here in New Hampshire...)
>
> I do think there is an issue here in terms of what we are expecting 
> when
> the sender "SHOULD" send a message in a particular format. If the 
> sender
> SHOULD send the message using format A, this implies that the receiver
> MUST accept format A and B (assuming a choice between A and B). Thus 
> the
> receiver MUST NOT return an error if the message arrives using format
> "B".
>
> This is important for interoperability. If a specification allows a
> behavior (SHOULD implies allowing a behavior that is not the "desired"
> behavior) then the receiver has got to support it, otherwise some pairs
> of devices just won't work.
>
>

I believe that the specification is already clear.

The Receiver MAY/SHOULD assume that each segment it receives is part
of a message, and that messages have been properly broken down into
segments. But ultimately, the receiver only needs to track the
LLP sequence (to determine if all prior placements have completed)
and the 'L' bit.

In the spirit of "be conservative in what you send and liberal in
what you accept" the receiver SHOULD NOT perform additional error
checking.

But for it to be *incorrect* for the receiver to reject a set
of segments there must be some way that they can be a valid
translation of a message. Given that all bytes within a
message have a known value, there is no way to translate
it into a set of segments that have holes.

It is equally arguable that while overlapping segments is
a waste of network bandwidth that cannot be justified over
a reliable transport, that it might be incorrect for the
receiver to enforce network bandwidth preservation.

But this is all very abstract because everyone agrees that
there is no need for the receiver to perform these checks.
Is anyone's receiver *looking* for more work to do?