Several sections of the Core Specification [1] are in contradiction wrt
to the default values for reply endpoint and its optionality. Currently
the specification treats the reply endpoint as a required property
instead of an optional property and contradicts itself in several
sections as follows: 

-- Section 3.1 lists reply endpoint/fault endpoint as "optional"
properties as their cardinality is defined as (0..1)

-- Section 3.2 lists the corresponding headers wsa:ReplyTo/wsa:FaultTo
as OPTIONAL elements. However,  the "default" value for the reply
endpoint property is designated to be anonymous URI. This aspect makes
the property required and is in conflict with its definition in Section
3.1. Consequently, the message exchanges will always assume a response,
instead of using the URI "". 

-- Section 3.3.1 (Formulating a Reply Message) first bullet second
statement says "If none is present, the processor MUST fault.". It is
not clear what "none" refers to here. There are two possibilities: 
(a) There is no reply endpoint property (refers to "0" as in Section
3.1). If this is the case, this is in contradiction with the fact that
there is a value (anonymous) as the "Note" in the following paragraph
suggests. This is again the reflection of the contradiction between the
sections in 3.1 and 3.2. Perhaphs the intention of this paragraph is to
say that there is always a reply endpoint property when a reply is
expected and it is an error not to have a reply endpoint in this case.
However, this intention itself contradicts the fact that an EPR with an
anonymous reply endpoint is always assumed which will result in ALWAYS
having a reply endpoint, deeming it to be REQUIRED, not OPTIONAL. 
(b) The value of the reply endpoint property is
"". This case is covered in 2,
therefore probably (b) is not the intended semantics for "none". 
Default values and optional values do not mix well. The specification
should clearly indicate whether the value is mandatory and supplied by a
default or optional. 



Dr. Umit Yalcinalp
NetWeaver Industry Standards
Email: Tel: (650) 320-3095 

Received on Monday, 16 January 2006 23:46:52 UTC