needs renegotiation/reconsideration.
Note that the Target may reply with other keys' responses,
along with the rejected ones.
Then the initiator will reconsider all rejected keys.
Note that a status code of anything but 0, implies
closing the connection.
Please see this message:
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html
My reply is a bit messy, in that I should've been clearer,
that the originator of the key being rejected by the
responder, SHOULD, if available, offer another set of values,
or close the connection.
Currently, the draft says (pg 69, 12-90):
If a responder does support,
understand or is allowed
to use none of the offered options with a specific originator,
it MAY use the constant "Reject" or it MAY respond with an
admissible value. The selection of a value not offered is
considered a negotiation failure and is handled as a protocol
error.
Which is inconsistent with itself. (I.e. self-contradictory
to negotiation.)
Proof: By the first clause:
Assume that the responder cannot use any of the
offered options to a key (keyword ``none'' in the
first sentence). Then the responder
1) MAY Reject,
2) MAY offer an admissible value.
Take 2) and proceed.
Then the originator receives an (admissible) value
which was NOT in what it offered and closes the
connection by the second clause.
Clearly, this is a negotiation failure.
If, on the other hand, we had chosen 1),
i.e. send Reject, the originator, may reconsider
it's options and send a different set of values,
and should one of them be acceptable to the
responder, we arrive at negotiation success.
QED.
This has already been communicated to Julian. Julian?
Nevertheless, a Reject response is required by
the responder to ``close the loop''.
If the originator doesn't close the connection
after that, the responder MAY choose to send
it's own values for the same (Rejected) key.
I.e. the responder to the Reject will now become
the originator of the Reject-ed variable.
--
Luben
