|
Julian,
If declarations
should not be repeated (except for those where it is explicitly allowed), then
it should be "negotiate or declare" because "negotiate" doesn't cover
declarations. Alternatively, one could add an explicit definition that
"Negotiate" includes both declarations and negotiations. Secondly, SendTargets
is not a valid example for login as it is FFPO. I think the only parameter
explicitly allowed to be duplicated during Login is TargetAddress (when returned
as a result of a redirect). Furthermore, I can not find any explicit statement
that SendTargets may be repeated during a FFP negotiation sequence. Only
TargetName and TargetAddress have explicit text allowing them to be repeated (in
Appendix B for both and in the description of redirection for LoginResponse for
TargetAddress).
Therefore, I
suggest:
For
4.3:
Neither the initiator nor the target should
attempt to declare or negotiate a parameter more than once during login except
for responses to specific keys that explicitly allow repeated key declarations
(e.g. TargetAddress). If detected by the target this MUST result in a Login
reject (initiator error). The initiator MUST drop the connection
For
4.4:
Neither the initiator nor the target should attempt to declare or
negotiate a parameter more than once during any negotiation sequence without an
intervening reset except for responses to specific keys that explicitly allow
repeated key declarations (e.g. TargetAddress). If detected by the target this
MUST result in a Reject with a reason of "protocol error". The initiator MUST
reset the negotiation as outlined above.
Pat
Pat,
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared
twice.
I think that you refer to the responses to
SendTargets - those contain more than an instance of the declarations and have
to outlined.
How about the following text in 4.4:
Neither the initiator nor the target should attempt to negotiate a parameter
more than once during login except for responses to specific keys that
explicitly allow repeated key declarations (e.g. SendTargets). If detected by
the target this MUST result in a Login reject (initiator error). The initiator
MUST drop the connection.
and in
4.4:
Neither the initiator nor the target should attempt to negotiate a parameter
more than once during any negotiation sequence without an intervening reset
except for responses to specific keys that explicitly allow repeated key
declarations. If detected by the target this MUST result in a Reject with a
reason of "protocol error". The initiator MUST reset the negotiation as outlined
above.
Julo
Julian,
The following text appears in 4.3 (page 78 just before 4.3.1):
Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login. If detected by the target this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.
and nearly the same text in 4.4 (page 85 near the end):
Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset. If detected by the target this MUST result in a
Reject with a reason of "protocol error". The initiator MUST reset
the negotiation as outlined above.
This is confusing partly because "negotiate" seems to be generally used covering both negotiations and declarations and in some cases covering only negotiations. It isn't clear in which sense it is used. If the text above applies only to negotiated values, then it would be allowable to send parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength over which doesn't seem to be a good idea. However, there are other declarative parameters which are sent multiple times - SendTargets where there are multiple targets or multiple addresses for a target requires sending the same parameter multiple times.
Perhaps the text should be changed to:
Neither the initiator nor the target should attempt to declare or negotiate a
parameter other than TargetName, TargetAlias or TargetAddress more than once....
Regards,
Pat
| 