V3 core requirements and segmentation

Question from: Mike Douglass Mon, 21 Jul 1997 11:29:48 -0400

Given that the target can force segmentation on a V3 origin (I.e. even if the client proposes no segmentation during initialization, i.e. sets the segmentation bits off, the server may overide that, set one or both segmentation bits on, and segmentation is in effect, even though the client didn't propose it. The target may thus "force" segmentation.) shouldn't segmentation be a baseline V3 requirement for the origin?

The reasoning (when baseline requirements were developed) is that if in fact the client does not support segmentation (and see note below), it may (and should) close the association when the server tries to "force" segmentation, and this would not violate the protocol nor mean that the client doesn't support version 3.

(Note: just because a client sets the segmentation bit off doesn't mean that it doesn't support segmentation; specifically, it means that it chooses not to propose segmentation for this association.)

The above reasoning still doesn't provide a complete answer, as you could further argue that a v3 client needs to be "segmentation aware" in order to even know that the server is forcing segmentation, so it knows to terminate the connection if it doesn't support it; and this is not reflected in the core requirements. The reasoning on this point is taken from 3.2.1.1.3, bottom of (first) note:

" ..... The origin might set the flag to 'in effect' for a capability unknown to the target. In that case it is recommended that the target set the corresponding flag to 'not in effect' in the response. However, if the origin sets a flag to 'not in effect' and the target sets the corresponding flag to 'in effect,' and if the origin is not aware what capability that flag represents, it is recommended that the origin terminate the Z-association."

Based on all of the above, it wasn't deemed necessary to reflect segmentation within the baseline requirements.