|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI - revised 2.2.4
Julian,
I
would also request an explicit definition of offering party and responding
party. The current text still leaves ambiguity when target sends a key in
response to implicit default key of the Intiator. In this case who is the
offering party and who is the responding party
Sanjeev
Here is a revised
(complete) part 2.2.4 based on recent agreed changes:
1.1.1 Text Mode
Negotiation
During login and
thereafter some session or connection parameters are negotiated through an
exchange of textual information.
All negotiations are stateless - i.e. the result MUST be based only on
newly exchanged values.
The
general format of text negotiation is:
Originator-> <key>=<valuex> Responder->
<key>=<valuey>|reject|NotUnderstood
The value can be a number, a single literal constant
a Boolean value (yes or no) or a list of comma separated literal constant
values.
In literal list
negotiation, the originator sends for each key a list of options (literal
constants which may include "none") in its order of preference.
The responding party answers with the
first value from the list it supports and is allowed to use for the specific
originator.
The constant "none"
MUST always be used to indicate a missing function. However, none is a valid
selection only if it is explicitly offered.
If a target is not supporting, or not allowed to use
with a specific originator, any of the offered options, it may use the
constant "reject". The constants "none" and "reject" are reserved and
must be used only as described here. Any key not understood is answered
with "NotUnderstood".
For
numerical and single literal negotiations, the responding party MUST respond
with the required key and the value it selects, based on the selection rule
specific to the key, becomes the negotiation result. Selection of a
value not admissible under the selection rules is considered a protocol error
and handled accordingly.
For
Boolean negotiations (keys taking the values yes or no), the responding party
MUST respond with the required key and the result of the negotiation when the
received value does not determine that result by itself. The last value
transmitted becomes the negotiation result. The rules for selecting the
value to respond with are expressed as Boolean functions of the value received
and the value that the responding party would select in the absence of
knowledge of the received value. Specifically, the two
cases in which responses are OPTIONAL are:
- The Boolean function is "AND" and the value "no"
is received. The outcome of the negotiation is "no". - The Boolean function is "OR" and the value "yes"
is received. The outcome of the negotiation is "yes".
Responses are REQUIRED in all other cases, and the
value chosen and sent by the responder becomes the outcome of the
negotiation.
The value "?" with
any key has the meaning of enquiry and should be answered with the current
value or "NotUnderstood".
The
target may offer key=value pairs of its own. Target requests are not limited
to matching key=value pairs as offered by the initiator. However, only
the initiator can initiate the negotiation start (through the first Text
request) and completion (by setting to 1 and keeping to 1 the F bit in a Text
request).
Comments ?
Julo
Home
Last updated: Mon Oct 08 13:17:27 2001
7124 messages in chronological order
|