CORBA3 — Inconsistent definition of semantics of RebindPolicy?

4.12.3.32 states:

> REBIND is raised when the current effective RebindPolicy, as described in
> Section 22.2.1.2, interface RebindPolicy on page 22-5, has a value of
> NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
> in a LocateReply message with status OBJECT_FORWARD or a Reply message with
> status LOCATION_FORWARD. This exception is also raised if the current effective
> RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
> The invocation can be retried once the effective RebindPolicy is changed to
> TRANSPARENT or binding is re-established through an invocation of
> CORBA::Object::validate_connection.

but 22.2.1.2 says:

> If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
> ORB will raise a REBIND system exception if any rebind handling would cause a
> client-visible change in policies. This could happen under the following
> circumstances:
>
> o The client receives a LocateReply message with an OBJECT_FORWARD status and a
> new IOR that has policy requirements incompatible with the effective policies
> currently in use.
>
> o The client receives a Reply message with LOCATION_FORWARD status and a new
> IOR that has policy requirements incompatible with the effective policies
> currently in use.

So the former says that a REBIND exception always occurs a rebind is
necessary (and NO_REBIND is set), but the latter says that a REBIND
exception only occurs when any client-visible policies would change.

Which one is correct?

Also, it is not clear from the specification whether an invocation on a
new object reference that has never been bound must fail if RebindMode
is not TRANSPARENT, forcing the use of validate_connection, or whether
the first initial binding can proceed without the use of
validate_connection.

see above