Web Services Addressing Last Call Issues List

Ref:  [1] WS-Addressing 1.0 Core 
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/)
        [2] WS-Addressing 1.0 SOAP Binding 
(http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331)

The Core specification require [message id] property in a message only 
if expects a reply, as indicated by presence of [reply endpoint] or 
[fault endpoint] properties. Accordingly  [reply endpoint] is required 
only if a reply is expected. Same goes for [fault endpoint] which is 
also optional.

Also messages that are replies do not need to have a [message id] property.

Given the above, how the faults described in section 5 of the WS-A SOAP 
Binding specification [2] could be received by the sender of the message 
if these properties are not supplied? I understand that the spec says 
faults are "generated" (and not necessarily transmitted) but, for faults 
like "5.5  Endpoint Unavailable" that also supply a <wsa:RetryAfter>, 
the intent is to send it so that the receiver can retry the message. 
These are faults outside of what the service defines in its WSDL.

So, it seems we are saying that WS-A SOAP binding users SHOULD be 
prepared to receive such faults even when the underlying service (WSDL) 
does not define any but we make it difficult for that to happen by not 
requiring the needed properties.

IMO to enable this, the core spec should highly encourage the use of 
(SHOULD) [message id] and [fault endpoint] / [reply endpoint] 
properties?, so that the WS-A defined faults have a chance of reaching 
the sender of the message (including when it is a reply)? Ideally I 
would make them required properties always.

Prasad Yendluri

Ref: WS-Addressing 1.0 - Core 
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/)

1.  Section 2.2: Example 2-1?
     The contents the "Example" are (normative?) schema for the 
wsa:EndpointReference element.
     Don't call it an "Example".
2. Section 2.2 description of  
/wsa:EndpointReference/wsa:ReferenceParameters/{any}
         Rephrase as follows:

    "Each element information item found in [reference parameters]
    (including all of its [children], [attributes] and [in-scope
    namespaces]) is represented as is."

3. Section 3, 3rd paragraph after editorial note, last sentence:
    Rephrase as follows:
          "The contract between the interacting parties may specify that 
multiple or even a variable number of replies be delivered."
4. Section 3, description of [fault endpoint]. Rephrase to eliminate "to 
to" in,
    "the sender MUST use the contents of the [fault endpoint], when
    present, of the message being replied to to formulate the fault
    message."

5. Section 3.1, "Example 3-1"?
    The contents of  "Example 3-1" are actually "XML Infoset 
representation of message addressing properties".
     Don't call it an "Example".

6. Section 3.1 /[reference parameters]* is not shown in XML Infoset 
representation of message addressing properties in "Example 3-1"

7. Section 3.1 /[reference parameters]* description. Rephrase as follows:
    "Each element information item found in [reference parameters] 
(including all of its [children], [attributes] and [in-scope 
namespaces]) is represented as is."

         

Ref: WS-Addresing 1.0 - Core 
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/)

Section 2.2 states it defines wsa:EndpointReferenceType:

"This section defines an XML Infoset-based representation for an 
endpoint reference as both an XML type (wsa:EndpointReferenceType) and 
as an XML element (<wsa:EndpointReference>)."

But the wsa:EndpointReferenceType is not defined in "this section".

The wsa:EndpointReference element is defined in the section in "Example 
2-1" but that definition is largely incomplete and does not show most of 
the extension points that are described in the text that follows. The 
following are not shown in the "Structure of the wsa:EndpointReference"

/wsa:EndpointReference/wsa:Address/@{any}
/wsa:EndpointReference/wsa:ReferenceParameters/@{any}
/wsa:EndpointReference/wsa:ReferenceParameters/{any}
/wsa:EndpointReference/wsa:Metadata/{any}
/wsa:EndpointReference/wsa:Metadata/{@any}
/wsa:EndpointReference/@{any}

Only /wsa:EndpointReference/{any} extensibility point is shown in the 
outline.

Regards, Prasad

Ref: WS-Addressing 1.0 Core 
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331)

The Editorial Note on page 2 of the specification (at the bottom of the 
section "Status of the Document") states:

"The Web Services Addressing Working Group has decided to use XML 
Schema, where appropriate, to describe constructs defined in this 
specification. Note that this restricts use of Web Services Addressing 
to XML 1.0."

However, later towards the end of section 1.2 it stated,

"Examples in this specification use an XML 1.0 [XML 1.0 
<http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/#XML10>] 
representation but this is not a requirement."

These two statements seem to contradict.

Regards, Prasad

Ref: WS-Addresing 1.0 - Core 
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/)

The utility of having the [source endpoint] property from the receiver 
perspective is not clear.
Specifically why does it need to be an endpoint reference?
What useful purpose could it serve to the receiver and why would a 
message sender include that property in message sent?

Section 3.0 last paragraph seems to imply [source endpoint] may serve to 
be the default [reply to] or [fault to] in certain cases:

"Requests whose [reply endpoint], [source endpoint] and/or [fault 
endpoint] use this address MUST provide some out-of-band mechanism for 
delivering replies or faults (e.g. returning the reply on the same 
transport connection). This mechanism may be a simple request/reply 
transport protocol (e.g., HTTP GET or POST)."

But that is explicitly ruled out in other parts of the specification 
that require [reply endpoint]  property.

Why not default the [reply endpoint] and [fault endpoint] to [source 
endpoint] when replies and faults are to be sent to the "sender" of the 
request than a different (or same) endpoint explicitly specified in the 
request.

This is analogous to email From and ReplyTo headers.

If the above is not done the specification needs to minimally add some 
explanation of the intended utility of this property.

Regards, Prasad

WS-Addressing SOAP binding specification has the following statements:

"To ensure interoperability with a broad range of devices, all
conformant implementations that include support for SOAP 1.2 MUST
support the SOAP 1.2 Addressing 1.0 Module."

"To ensure interoperability with a broad range of devices, all
conformant implementations that include support for SOAP 1.1 MUST
support the SOAP 1.1 Addressing 1.0 Extension."

The above could be interpreted to mean, all conformant implementations 
of SOAP 1.2 MUST support SOAP 1.2 Addressing 1.0 Module and all 
conformant implementations of SOAP 1.1 MUST support SOAP 1.1 Addressing 
1.0 Extension. I believe that is not the intent.

I would ask that these statements be rephrased as follows to eliminate 
any ambiguity:

"To ensure interoperability with a broad range of devices, all 
comformant implementations of WS-Addressing 1.0 that include support for 
SOAP 1.2 MUST support the SOAP 1.2 Addressing 1.0 Module"

and

"To ensure interoperability with a broad range of devices, all 
comformant implementations of WS-Addressing 1.0 that include support for 
SOAP 1.1 MUST support the  SOAP 1.1 Addressing 1.0 Extension"

Regards, Prasad

The following are a few typographic nits that should be corrected in the
Core document.

- Table 1-1: The prefix S11 is not used in this doc.  Suggest striking.

- Section 2-1 [metadata]: The prefix "xsd" in "xsd:any" should be "xs".

- Example 3-1: Use pseudo-schema notation consistently.  
  Replace RelationshipType="..." with RelationshipType="xs:anyURI".

- Example 3-2, 3-3: Consistent whitespace formatting of the examples
  would make them easier to read.

The mixed use of the acronyms URI and IRI is a bit confusing.  Sometimes
the draft uses IRI, and sometimes it uses URI.  However, simply using
IRI throughout has problems too.  We suggest as a principle for when to
use IRI vs. URI that when specific instances of IRIs can be identified
as URIs by inspection (e.g. the anonymous URI), and we should call them
URIs to make it clear they can be used in any context where a URI is
allowed.  The types of the properties are rightly described as IRIs,
since the range of values is greater than allowed by URIs.  Following
this principle would result in the following changes:

- Last sentence before 1.1: 'Line (010) specifies an action URI
identifying expected semantics.' (Note also case correction.)

- Last sentence in section 2.2: 'The following shows an example endpoint
reference. This element references the endpoint at the URI
"http://example.com/www.fabrikam/acct".' (Note also extra "the"
removed.)

- Section 3 [relationship]: 'The message identifier IRI may refer to a
specific message, or be the following well-known URI that means
"unspecified message":
"http://www.w3.org/@@@@/@@/addressing/id/unspecified".'

- Table 3-1 heading 'URI'.

- Section 3 [relationship]: 'A reply message MUST contain a
[relationship] property consisting of the predefined reply URI and the
message id property of the request message.'

- Section 3 [relationship]: 'WS-Addressing defines the following
well-known URI for use by endpoints that cannot have a stable,
resolvable IRI: "http://www.w3.org/@@@@/@@/addressing/role/anonymous".'

- Section 3.1 4th bullet: '[relationship]: a new pair of IRIs is added
to this value as follows; the relationship type is the predefined reply
URI "http://www.w3.org/@@@@/@@/addressing/reply" ...'

Although the [address], [destination], etc. properties defined in
sections 2.1 and 3 are of type "IRI", which suggests an absolute IRI
(otherwise it would state IRI Reference), this is proving a bit subtle
for some readers.  Suggest making it explicit that these are absolute
IRI values in the following locations:

- Section 2-1 [address] property: reword as 'An absolute IRI
representing the address of the endpoint.'  

- Section 3 [destination] property: reword as 'An absolute IRI
representing the address of the intended receiver of this message.'

- Section 3 [action] property: reword as 'An absolute IRI that uniquely
identifies the semantics implied by this message.' (Note removal of
redundant "identifier.")

- Section 3 [message id] property: reword as 'An absolute IRI that
uniquely identifies this message in time and space.'

- Section 3 [relationship] property: reword as 'The type of the
relationship is identified by an absolute IRI. The related message is
identified by an absolute IRI that corresponds to the related message's
[message id] property.'

Section 2-1 [reference parameters] property states: "Reference
parameters are element information items that are named by QName."
Element information items have properties such as [local name],
[prefix], and [namespace URI].  The mix of infoset and XML production
terminology is confusing.  Suggest wording this similarly to the SOAP
spec: "Reference parameters are namespace qualified element information
items."

Section 2-1 [reference parameters] property states:

  'Reference parameters are also provided by the issuer of the endpoint
  reference and are otherwise assumed to be opaque to consuming
  applications.'

The "otherwise" implies that the reference parameters cannot be treated
as opaque by the issuer (who might not be the receiving service, e.g. a
broker).  Reference parameters might be understood only by the service
being addressed.

Suggest rewording by striking "also" and "otherwise":

  'Reference parameters are provided by the issuer of the endpoint
  reference and are assumed to be opaque to consuming applications.'

Section 2-1 [reference parameters] property states:

  'The use of reference parameters is dependent upon the protocol
  binding and data encoding used to interact with the endpoint.'

We're not sure what the phrase "and data encoding" is trying to convey.


Suggest striking the phrase "and data encoding":

  'The use of reference parameters is dependent upon the protocol
  binding used to interact with the endpoint.'

Section 2.1 [metadata] states:

  'The metadata embedded in each of the EPRs MAY differ, as the 
  metadata carried by an EPR is not necessarily a complete statement 
  of the metadata pertaining to the endpoint.'

The word "each" no longer has a referent.

Suggest rewording as:

  'The metadata carried by an EPR is not necessarily a complete 
  statement of the metadata pertaining to the endpoint.'

Table 3-1 states:

  'Indicates that this is a reply to the message identified by the IRI.'

It's not clear which IRI this refers to.

Suggest rewording as:

  'Indicates that this is a reply to the message identified by the 
  [message id] IRI.'

Section 3 [relationship] states:

  'A reply message MUST contain a [relationship] property consisting 
  of the predefined reply IRI and the message id property of the 
  request message.'

This implies one or more reply relationships must be indicated.  What
does it mean to be a reply to more than one message?

Suggest changing "a" to "exactly one", as in the following rewording:

  'A reply message MUST contain exactly one [relationship] property
  consisting of the predefined reply IRI and the message id property 
  of the request message.'

Section 3 1st paragraph after property list states:

  'The dispatching of incoming messages is based on two message 
  properties: the mandatory "destination" and "action" fields indicate 
  the target processing location and the verb or intent of the message 
  respectively.'

This suggests that _only_ these two properties can be used for dispatch,
when in fact they are there simply to facilitate dispatch, and other
parts of the message may also be used for dispatching purposes.  It's
out of scope for WS-A to say what a dispatcher may or may not use.

Suggest rewording:

  'The mandatory [destination] and [action] properties indicate the 
  target processing location and the verb or intent of the message 
  respectively, which facilitates the dispatch of incoming messages.'

Section 3: 2nd paragraph after property list states:

  'To allow these "anonymous" endpoints to initiate message exchange 
  patterns and receive replies, ... "

The anonymous URI can be used for more purposes than just replies, for
instance, e.g. faults.

Suggest appending "and other messages" as follows:

  'To allow these "anonymous" endpoints to initiate message exchange 
  patterns and receive replies and other messages, ... "

Section 3.1 /wsa:To states in the last sentence:

  'Otherwise the [children] of this element convey the value of this
  Property.'

This sentence is inconsistent with the description of other headers that
carry values in their [children], and sounds like something tricky is
going on when there isn't.

Suggest omitting this sentence, and similarly with the final one of
wsa:Action: 'The [children] of this element convey the value of this
property.'

Section 3.1.1: [destination] is conspicuously absent from the list of
properties where simple string comparison can be performed.  It would be
helpful to point out that this is intentional.  In addition, there is
one scenario where it would be beneficial to use simple string
comparison - when the [destination] is the anonymous URI.

Suggest appending this sentence to the paragraph:

  'Comparison of the [destination] property is out of scope, other 
  than using simple string comparison to detect whether the value 
  is anonymous, that is, where [destination] has the value
  "http://www.w3.org/@@@@/@@/addressing/role/anonymous".'

Section 3: 2nd paragraph after property list states:

  'WS-Addressing defines the following well-known URI for use by
  endpoints that cannot have a stable, resolvable IRI:
  http://www.w3.org/@@@@/@@/addressing/role/anonymous.'

We are concerned that the semantics of the anonymous URI are not crisp
enough.  Specifically, it is not stated explicitly anywhere that when
HTTP is used, the anonymous URI represents the HTTP response.  We
suggest stating explicitly in the Core that its meaning is defined by
the transport in use, and adding to the SOAP Binding spec a statement
specifying the meaning when using the HTTP transport.

We propose following the above sentence with another:

  'The precise meaning of the anonymous URI is defined by the 
  transport in use.'

Add to section 3.2 of the SOAP Binding spec a statement:

  'In the case of SOAP over HTTP the URI 
  http://www.w3.org/@@@@/@@/addressing/role/anonymous denotes 
  the response to an HTTP request.'

Section 3 last paragraph states (referring to the anonymous URI):

  'This IRI MAY be used as the [destination] for reply messages 
  and SHOULD NOT be used as the [destination] in other circumstances.'

This comment is true of HTTP, but not necessarily true of other
transports.  The statement as it stands is too HTTP-specific.

We suggest removing this sentence.

Section 3.1, last paragraph states:

  'Note that each of the element information items described above
  allows attribute wildcards for future extensibility.'

We allow attribute extensibility but we don't describe a processing
model for it.  Consistent with EPR extensibility we suggest ignoring
extension attributes that you don't understand.

Append the following sentence to this paragraph:

  'Software processing these headers may safely ignore any extension
  attributes it does not recognize.'

Corresponding changes to the SOAP Binding spec:

- Last sentence before 1.1: 'Line (010) specifies an action URI
  identifying expected semantics.' (Note also case correction.)

- Section 2.1: 'The SOAP 1.2 Addressing 1.0 Feature is named using 
  the following URI: ...'

- Section 3.1: 'The SOAP 1.2 Addressing 1.0 Module is identified 
  using the following URI: ...'

- Section 4.1: 'The SOAP 1.1 Addressing 1.0 Extension is identified 
  using the following URI: ...'

> -----Original Message-----
> From: [email protected] [mailto:public-ws-
> [email protected]] On Behalf Of Jonathan Marsh
> Sent: Tuesday, April 12, 2005 9:05 AM
> To: [email protected]
> Subject: Rationalize URI vs. IRI (Core, clarification)
> 
> 
> The mixed use of the acronyms URI and IRI is a bit confusing.
> Sometimes
> the draft uses IRI, and sometimes it uses URI.  However, simply using
> IRI throughout has problems too.  We suggest as a principle for when
> to
> use IRI vs. URI that when specific instances of IRIs can be identified
> as URIs by inspection (e.g. the anonymous URI), and we should call
> them
> URIs to make it clear they can be used in any context where a URI is
> allowed.  The types of the properties are rightly described as IRIs,
> since the range of values is greater than allowed by URIs.  Following
> this principle would result in the following changes:
> 
> - Last sentence before 1.1: 'Line (010) specifies an action URI
> identifying expected semantics.' (Note also case correction.)
> 
> - Last sentence in section 2.2: 'The following shows an example
> endpoint
> reference. This element references the endpoint at the URI
> "http://example.com/www.fabrikam/acct".' (Note also extra "the"
> removed.)
> 
> - Section 3 [relationship]: 'The message identifier IRI may refer to a
> specific message, or be the following well-known URI that means
> "unspecified message":
> "http://www.w3.org/@@@@/@@/addressing/id/unspecified".'
> 
> - Table 3-1 heading 'URI'.
> 
> - Section 3 [relationship]: 'A reply message MUST contain a
> [relationship] property consisting of the predefined reply URI and the
> message id property of the request message.'
> 
> - Section 3 [relationship]: 'WS-Addressing defines the following
> well-known URI for use by endpoints that cannot have a stable,
> resolvable IRI:
> "http://www.w3.org/@@@@/@@/addressing/role/anonymous".'
> 
> - Section 3.1 4th bullet: '[relationship]: a new pair of IRIs is added
> to this value as follows; the relationship type is the predefined
> reply
> URI "http://www.w3.org/@@@@/@@/addressing/reply" ...'
> 

- Section 3.3, first bullet: "each [reference parameter]" -> "each of 
  the [reference parameters]"

- Example 5-1 says "<!-- Headers elided for clarity.  -->" The correct
  word is probably "brevity".

- Example 5-2 is the only SOAP 1.1 example, yet it doesn't show any WSA
  headers.  It might be worth losing brevity to have one example of a 
  SOAP 1.1 envelope containing at least the WSA headers shown in 
  Example 5-1.

- Section 5.5 "xs:NonNegativeInteger" -> "xs:nonNegativeInteger"

The current split between Core and SOAP Binding specifications makes the
combined result difficult to read and comprehend and doesn't seem to
help separate abstraction from a concrete binding.  For example:

- The Core contains examples using SOAP, even the Core is supposedly
independent of SOAP.

- XML representations for the abstract properties are defined in the
Core, even though these representations are used as SOAP headers.

- Conversely, if you were looking for a concrete definition of a WS-A
SOAP header, you would not find it in the SOAP Binding spec.

- The definition of the wsa namespace is split between documents,
implying that versioning of these two specs must be held in lockstep,
further implying that they really are a single spec published as two
parts.

- There's lots of redundancy between Core and SOAP boilerplate.

To alleviate this confusion and simplify the spec, we request that the
SOAP Binding specification should be merged back into the Core.  Since
they are on the same timeline and have the same status (Rec track),
there should be minimal process issues.

We are willing to develop a concrete proposal to facilitate this, but
the general idea is to insert sections 2-6 of the SOAP spec as divisions
of a new Section 4 in the Main spec, and merging introductory and
bibliographic material as necessary.  Some consolidation or
specialization of the Security Considerations might also be
contemplated.

Section 2.4 states: 

  'If the http://www.w3.org/2003/05/soap/features/action/Action property
  of the SOAP Action featureSOAP 1.2 Part 2: Adjuncts has a value, then
  the value of the http://www.w3.org/@@@@/@@/addressing/feature/Action
  property of the SOAP 1.2 Addressing 1.0 feature MUST be identical to
  it.'

If these two fields don't match, which fault should be returned?  We
suggest Invalid Message Addressing Property is sufficient.

Append the following sentence to the previous paragraph:

  'Failure to have an identical value results in the Invalid Message
  Addressing Property [ref] fault.'

Section 3.2 states: 
  'The SOAP 1.2 Addressing 1.0 Module uses the XML Infoset 
  representation of the abstract message addressing properties 
  defined in Web Services Addressing 1.0 - Core.'

The terminology between the abstract properties and the XML
representation of those properties, reused as SOAP headers, is
confusing.  Defining the XML representations and their use as SOAP
headers in a single spec helps (see comment
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0024.html). But we also suggest being more precise in distinguishing
these two notions.

Change the above sentence to:

  'The SOAP 1.2 Addressing 1.0 Module defines SOAP headers corresponding
  to the XML Infoset representation of the abstract message addressing
  properties defined in Web Services Addressing 1.0 - Core.'

Change the sentence in Section 3.3 which states:

  'When a message is be addressed to an endpoint, the values of the SOAP

  1.2 WS-Addressing 1.0 Feature properties are mapped to the message as
  SOAP header blocks with the following additional modifications:'

to read:

  'When a message is to be addressed to an endpoint, the XML
  representation of each SOAP 1.2 WS-Addressing 1.0 Feature property is
  inserted into the message as a SOAP header block subject to the
  following additional constraints:'

Change the third bullet in Section 3.3, which states:

  'Each property that is of type IRI MUST be serialized as an absolute
  IRI in the SOAP message.'

to read:

  'Each property that is of type IRI MUST be serialized as an absolute
  IRI in the corresponding XML Infoset representation of that Message
  Addressing Property.'

The primary definition of the WS-A properties is in the Core, using the
[property] notation, not in the SOAP Feature which assigns each of these
properties a URI.  The notation in Section 3.3 below mixes these two
notations in referring to WS-A properties. Since the [property] notation
is primary, we suggest referring to the primary definition directly and
using the [property] notation.  The notation also refers to these
properties as SOAP 1.2 WS-Addressing 1.0 Feature properties instead of
WS-Addressing 1.0 Message Addressing Properties, which exhibits the same
problem of unnecessary levels of indirection.

Change the following sentence:

  'When a message is to be addressed to an endpoint, the values of the
  SOAP 1.2 WS-Addressing 1.0 Feature properties are mapped to the
  message as SOAP header blocks with the following additional
  modifications:'

to read (also incorporating the changes requested at
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0026.html):

  'When a message is to be addressed to an endpoint, the XML
  representation of each non-empty WS-Addressing 1.0 Message Addressing
  Property is inserted into the message as a SOAP header block subject
  to the following additional constraints:'

Change the first bullet in Section 3.3, which states:

  'The value of the
  http://www.w3.org/@@@@/@@/addressing/feature/ReferenceParameters
  property is added to the SOAP message header.'

to read:

  'The value of the [reference parameters] property is added to the
  SOAP message header.'

Change the third bullet in Section 3.3, which states:

  'Each property that is of type IRI MUST be serialized as an absolute
  IRI in the SOAP message.'

to read (also incorporating the changes requested at
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0026.html):

  'Each property that is of type IRI MUST be serialized as an absolute
  IRI in the corresponding XML Infoset representation of that Message
  Addressing Property.'

Other elements and attributes in the wsa namespace capitalize the first
letter of each name.  According to this convention,
wsa:isReferenceParameter should be changed to wsa:IsReferenceParameter
throughout.

Specifically isReferenceParameter appears in two locations:
- Section 3.3 second bullet.
- Example 3-2.
The schema would also need to be updated.

The definition of the wsa:isReferenceParameter is informal, only
appearing in Section 3.3 bullet 2.  This is inconsistent with our
definition of other attributes in the Core spec, and leaves open
questions, for instance, as to the type of the attribute.

Change the definition from:

  'Each header block added as a result of the above rule is 
  annotated with a wsa:IsReferenceParameter attribute whose value 
  is "true".'

to:

  'Each header block added as a result of the above rule is annotated
   with a wsa:IsReferenceParameter attribute whose value is an valid
   xs:Boolean representation of "true".'

Add to the Core spec, section 3.1, a definition of this attribute as
follows:

  '/[reference parameters]/@wsa:IsReferenceParameter
     This REQUIRED attribute (of type xs:Boolean) signifies that 
     the message information header is a reference property.'

Section 3.3 bullet 2 defines the addition of wsa:IsReferenceParameter to
a reference parameter header.  It does not state what to do in the
(abusive?) case that there already is such an attribute.

We suggest adding the following sentence to bullet 2:

  'This attribute replaces the ws:IsReferenceParameter attribute if
  already present on the reference parameter.'

It seems worthwhile making the fact explicit that a reference parameter
element will change during transmission through SOAP because of the
addition of the wsa:IsReferenceParameter attribute.

Add a note following bullet 2 of Section 3.3 stating:

  'Note: When validating the integrity of a [reference parameter], a
  receiver should anticipate the addition of the
  wsa:IsReferenceParameter attribute and the introduction of the 
  WS-Addressing namespace to the [in-scope namespaces].'

The rules in Section 3.3 imply that every header is required for each
message.  That isn't the case.

Section 3.3 states:

  'When a message is be addressed to an endpoint, the values of the SOAP
  1.2 Addressing 1.0 Feature properties are mapped to the message as
  SOAP header blocks with the following additional modifications:'

Clarify that this applies to the "values of non-empty ... properties".

Taking
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0026.html and
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0027.html into account, this would read:

  'When a message is to be addressed to an endpoint, the XML
  representation of each non-empty WS-Addressing 1.0 Message Addressing
  Property is inserted into the message as a SOAP header block subject
  to the following additional constraints:'

The first bullet point reads:
 
  'The value of the 
  http://www.w3.org/@@@@/@@/addressing/feature/ReferenceParameters 
  property is added to the ...'

Change it to read (taking
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0027.html into account):

  'The value, if any, of the [reference parameters] property is added to
  the ...'

Add a fourth bullet point:

  'Each optional element or attribute that has a value equal to the
  defined default value for that element or attribute MAY be omitted.'

We have agreed that it is acceptable for a message to contain duplicate
WSA headers, as long as they are targeted differently.  To improve
interoperability, we should clarify what happens when duplicate headers
targeted to the ultimate recipient are inserted in a message:

  'A message MUST not contain more than one wsa:To, wsa:ReplyTo,
  wsa:FaultTo, wsa:Action, or wsa:MessageID header targeted to the
  ultimate receiver.  A recipient MUST generate a
  wsa:InvalidMessageAddressingProperty fault in this case.'

We don't define conformance in a clear location in the document,
although there is a suggestive statement in Section 4:

  'To ensure interoperability with a broad range of devices, all
  conformant implementations that include support for SOAP 1.1 MUST
  support the SOAP 1.1 Addressing 1.0 Extension.'

This statement however is a bit ambiguous as to what one is conforming
to and what it means to conform.

We suggest removing the above sentence, and replace it with an explicit
Conformance Section (new Section 7) as follows:

-----------
7. Conformance

A SOAP 1.2 message conforms to the SOAP 1.2 Addressing 1.0 Module when
it contains headers from the wsa namespace, and follows all the
constraints defined by the SOAP 1.2 Addressing 1.0 Module.

A SOAP 1.1 message conforms to the SOAP 1.1 Addressing 1.0 Extension
when it contains headers from the wsa namespace, and follows all the
constraints defined by the SOAP 1.1 Addressing 1.0 Extension.

An endpoint which conforms to this specification understands and accepts
SOAP messages containing headers in the wsa namespace targeted to it,
and generates reply or fault messages it may send in response according
to the rules outlined in this specification.
-----------------

Section 5 2nd paragraph states:

  'Endpoints compliant with this specification MUST include the required
  message addressing properties serialized as SOAP headers in all fault
  messages.'

For consistency, "compliant" -> "conformant".

Section 5.1 states '[Detail] [invalid property]'

It is unclear from this terse description precisely what is to be
returned.  A URI naming the property?  An XML representation of the
property?  The offending SOAP header?  In removing the term Message
Information Header from the spec this fault seems to have gotten messed
up a bit.  We feel the most direct way to communicate a SOAP fault is to
indicate which header caused the fault.  We therefore suggest changing
the name and specification of this fault to be more header-centric.

To denote the header that caused the problem without causing message
bloat that could be used to mount distributed denial of service attacks,
we suggest returning only the QName of the offending header.

Replace Section 5.1 as follows:

--------
5.1 Invalid Addressing Header

A header representing a WS-Addressing 1.0 Message Addressing Property
cannot be processed.

[Code] S:Sender

[Subcode] wsa:InvalidAddressingHeader

[Reason] A header representing a Message Addressing Property is not
valid and the message cannot be processed. The validity failure can be
either structural or semantic, e.g. a [destination] that is not an IRI
or a [relationship] to a [message id] that was never issued.

[Detail] [Invalid header QName]
-------

Similar problems exist in Section 5.2 (what is a [missing property
QName]?).  Replace Section 5.2 as follows:

-----
5.2 Message Addressing Header Required

A required header representing a message addressing property is absent.

[Code] S:Sender

[Subcode] wsa:MessageAddressingHeaderRequired

[Reason] A required header representing a message addressing property is

not present.

[Detail] [Missing header QName]
------

Although it might cost nearly as much to send a bloated EPR as it would
to process it, it might be worthwhile to point out the possibility of
DOS attacks in this case.

  'Reference Parameters and other WS-Addressing headers can potentially
  be quite large. Implementations should take care not to expose
  themselves to a denial of service attack based on constructing or
  consuming messages based on EPRs with large reference parameters.'

It might be possible to manipulate a service into using up all it's
sockets.  We should point out that implementations should guard against
this attack.

  'When [reply endpoint] and/or [fault endpoint] do not contain the
  anonymous URI, the processor of such an EPR should take care to avoid
  a denial of service attack caused by opening an excessive number
  network connections, which are typically a scarce resource.'

If an implementation is completely non-discriminatory about where it
sends faults it may be possible to manipulate that endpoint into
participation in a DoS attack.

  'Care should be taken to avoid participating in a denial of service
  attack in which an attacker sends malformed messages to many receivers
  and includes a [fault endpoint] for the target of the attack.'

Regarding the request for feedback on the use of xs:nonNegativeInteber,
we prefer xs:unsignedInt.

xs:nonNegativeInteger allows an arbitrary number of digits, which is
inconvenient when mapping to native types in our tooling, and introduces
implementation-specific limitations which may affect interop.

xs:duration also allows arbitrary precision and the accompanying
implementation-specific limitations, yet is difficult to restrict this
type via pattern facets and even then doesn't map well into native types
in our tooling.

xs:unsignedLong may also be acceptable because it's easy to tool and
manipulate, although we don't see a need for 50 million year durations
in this case.

We therefore prefer xs:unsignedInt.

When I read the Last Call Working Draft [1] of the Web Services Addressing 
1.0 - Core specification, I see that the cardinality indicator associated 
with the "[destination]" property in section 3. Message Addressing 
Properties [2] is "(mandatory)".  Unfortunately, I do not see a definition 
of "(mandatory)" anywhere in the same document (I even checked RFC 2119 
[3]).  So, while I would doubt that anyone would argue about associating 
minOccurs=1 to the term, it is less clear what value of maxOccurs to 
associate.  I can see arguments for both one and unbounded.  So...

(1) What did the authors intend for the meaning of "(mandatory)"?

(2) If the intent was in fact maxOccurs=unbounded, could you help me to 
understand the use cases behind the intent?  I have some ideas, but I am 
sure that the authors must have more.

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
[2] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/#msgaddrprops
[3] http://www.ietf.org/rfc/rfc2119.txt

Example 3-1 in core spec has an extra "?" 
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
                                    ^^^^

thanks,
dims
-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Should "Table 3-1. Predefined [relationship] values" say "Table 3-1.
Predefined [relationship] types"?

-- dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

In the core spec Section 3 and Section 3.1 can we change the order
of the Abstract Properties and the XML Infoset representation to be the
same? For example " [destination] : IRI (mandatory)" is first in Section
3, but Section 3.1 has "/wsa:MessageID"...just to make things
clear/easy.

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Table 1-1 lists S11, but S11 is not used in the doc. Should we
remove it from table 1-1? And related observation is that the text does
not say anything about SOAP 1.1 (it just says - "WS-Addressing may be
used with SOAP [SOAP 1.2 Part 1: Messaging Framework] as described in
Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP]."). 

thanks,
dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Section 4 Security Considerations has a typo? (" message level
signature, and use of an XML digital signature") should the "and" be
replaced with an "or"?

thanks,
-- dims
-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Some URL's in References are bad. They have an extra '.'
	[IETF RFC 2119] - 2nd URL
	[WSDL 2.0] - 2nd URL
	[XML 1.0] - 2nd URL
	[XML Namespaces] - 2nd and 4th URL
        [XML Information Set] - 2nd and 4th URL
	[XML Schema Structures] - 2nd URL and 4th URL
        [XML Schema Datatypes] - 2nd and 4th URL

Thanks,
dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

In "3.2 Formulating a Reply Message" should we say something about
wsa:Metadata? (or is it just implied that it is ignored/consumed)

thanks,
dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

[WSDL 2.0] - First URL points to wrong URL. Second and Fourth URL's
have an extra '.'
[IETF RFC 2119] - Second URL has an extra '.'
[XML 1.0] - Second URL has an extra '.'
[XML Namespaces] - Second and Fourth URL's have an extra '.'
[XML Information Set] - Second and Fourth URL's have an extra '.'
[XML Schema Datatypes] - Second and Fourth URL's have an extra '.'
[SOAP 1.2 Part 1: Messaging Framework] - Second and Fourth URL's have
an extra '.'
[SOAP 1.2 Part 2: Adjuncts] - Second and Fourth URL's have an extra '.'

InvalidMessageAddresssingProperty
should be
InvalidMessageAddressingProperty

thanks,
dims

The following line:
Fault messages are correlated as replies using the [relationship]
property as defined in Section 3

Should be:
Fault messages are correlated as replies using the [relationship]
property as defined in Section 3 of the Web Services Addressing 1.0 -
Core[WS-Addressing-Core] specification.

Right?

Section 3.1 and 4.1 use the same IRI
(http://www.w3.org/@@@@/@@/addressing/module). Is this ok?

thanks,
dims

Can you please re-order the items in section 2.3 (SOAP) to be the same
as Section 3 of core.

thanks,
dims

Core spec uses MessageID...Section 2.3 Properties (in SOAP) uses MessageId

thanks,
dims

a couple of very minor editorial comments:

- The SOAP binding document uses the terms MAP and MEP without 
introducing them. OK they're explained in referenced documents, but i 
think it's only polite to introduce them in each document with the 
first usage: "Message Addressing Property (MAP)".

- If we use MAP, shouldn't we then use capitalisation for that term 
throughout rather than the lower-case "message addressing properties"?

Whilst i'm kicking the tyres, the text in Example 3-9 of the working 
draft of WSDL Binding document (22/3) doesn't scan to well: 
'the default value is the name of the operation [with?] "Request" 
appended'

Paul

    I want to raise an issue with section 3.0, [1], which says, in part:

<quote>
The dispatching of incoming messages is based on two message properties: the
mandatory "destination" and "action" fields indicate the target processing
location and the verb or intent of the message respectively.
</quote>

In the WS-I BP WG, we argued strongly that we shouldn't be saying anything
about dispatching because it is a service implementation detail. So I wonder
why WS-Addressing says this. If I choose to dispatch on request element in
SOAP body or prefix used for the SOAP envelope, what do you care? Is it the
intent of WSA to "standardize" implementation model?

I'd prefer to see this paragraph dropped.

Thanks,
Tim-

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/#msgaddrprops

As I read the spec, a compliant WS-Addressing based endpoint MUST use the
value in the ReplyTo header as the place to send a reply message. Further,
when a reply is expected, the ReplyTo header must be present. Because of
this, the section on security recommends that a service SHOULD only use EPRs
from trusted sources.

My issue with this is that it isn't enough to trust the source, I have to
trust that source that it's okay to send reply messages to the requested
endpoint. I may trust one source enough to send messages to a specific,
prearranged domain, but it is unlikely that I trust a source enough to send
messages anywhere. In the absence of that very specific trust, it seems
reasonable that a service would trust a client enough to process the request
and to send the response back to the client on the same connection (sort of
the inverse of the Java applet sandboxing model).

To implement that, a service would check for a ReplyTo header - which must
be present in the case of a reply - and check to see whether the address was
the anonymous URI. If the address is anything else, the service should raise
a fault. As I read the spec, however, that is not allowed.

In short, if a ReplyTo is required and MUST be honored, then I have no
choice but to ensure that I trust sources of EPRs enough to let them tell me
to send messages to an arbitrary address (which is a lot of trust indeed!).
If I can't do that, I have to either violate the protocol or just not use
WS-Addressing.

I faced this precise issue when I worked at MSDN. We considered using WSE to
implement our services, but it honored the ReplyTo header. Since MSDN offers
services that are used by the public (indirectly via VS.NET), we didn't
trust callers enough to get us to pummel arbitrary URIs with messages. As a
result, WSE added a feature to disable ReplyTo/FaultTo processing, and they
are disabled by default. 

Given the importance of security, I believe the WS-Addressing spec must
address this issue. Simply saying that services SHOULD only use endpoints
from trusted sources is NOT sufficient.
    

Section 5.0 of SOAP Binding defines the binding of fault properties,
namely [Code], [Subcode], [Reason], and [Detail] to SOAP 1.1 and SOAP
1.2 envelopes. All the properties are bound to a SOAP 1.2 envelope (as
shown in Example 5-1) but only [Subcode] and [Reason] are bound in SOAP
1.1 envelope (as shown in Example 5-2). The faults specified in section
5.1 to 5.5 are thrown when there is a problem in the
WS-Addressing headers. In that sense, I think all of these faults can be
treated as header faults.

Now SOAP 1.1 says [1] that detailed error information belonging to
header entries MUST be carried within header entries. However if we
treat these faults as headerfaults then they really are unsolicited
header faults and thus there is no description in the WSDL that
indicates how the detail information can be carried out in the header
entries.

Proposal -

Define a new wrapper element wsa:faultDetail or wsa:headerFault in
section 5.0 of SOAP Binding [1] that can be used to convey the fault
[Detail] in SOAP 1.1 message.

[1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Ref477488700

WSA 1.0 - SOAP-Binding Document Editor's Copy 2005/04/12 

Example 3-1 does not declare the XML namespace prefix "wsaw" 
used in line 9 of the example. 

I suggest adding the missing declaration: 
  xmlns:wsaw="http://www.w3.org/@@@@/@@/addressing/wsdl" 
    

a) Section 3 of core 
( http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/ ) states

"Message addressing properties provide references for the endpoints
involved in an interaction. The use of these properties to support 
specific interaction is in general defined by both the semantics of 
the properties themselves and the implicit or explicit contract that 
governs the message exchange. If explicitly available, this contract 
can take different forms including but not being limited to WSDL 
MEPs and interfaces; business processes and e-commerce 
specifications, among others, can also be used to define explicit 
contracts between the parties."

For migration purposes an pre-existing wsdl defined request/response 
service endpoint may wish to publish an EPR, which contains the http 
POST url in the address element, an which does not conatin ref parms, 
and may contain wsdl specific metadata (e.g., port type. Such an 
endpoint may support a contract specifying that it will accept ws 
addressing headers and behave as specified in ws addressing spec when 
it receives these headers, however also specifying that it will 
continue to accept http post requests without ws addressing headers.

This needs to be reflected in the above paragraph somehow.

One proposed solution is to add the above paragraph to this section.

b) In the Soap binding spec 
( http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/ )

5.2 Message Addressing Property Required

A required message addressing property is absent.
[Code] S:Sender
[Subcode] wsa:MessageAddressingPropertyRequired
[Reason] A required message addressing property is not present.
[Detail] [Missing Property QName]

It should be clarified that there is no requirement that the above 
fault MUST be sent by every endpoint which has published an 
endpoint reference, when it receives invocations from senders 
which are not conforming to WS-addressing.

One proposed solution is to add the following paragraph:

?Endpoints should be allowed to support ?migration? contracts 
which allow clients to continue to invoke operations outside 
of the scope of ws-addressing, even though that service endpoint 
claims conformance to ws-addressing (i.e., it will act within the 
ws-addressing behaviour if the sender includes ws-addressing 
headers in their request).?    

4. Security Considerations

  "Users of WS-Addressing and EPRs (i.e., entities creating, consuming
  or receiving Message Addressing Properties and EPRs) SHOULD only use
  EPRs from sources they trust. For example, such users might only use
  EPRs that are signed by parties the user of the EPR trusts, or have
  some out-of-band means of establishing trust."

It's not quite clear what the "or have" refers to - the users? The
trusted parties?  Suggest rewording the last sentence as:

  "For example, such users might rely on the presence of a verifiable
  signature by a trusted party over the EPR, or an out-of-band means 
  of establishing trust, to determine whether they should use a
  particular EPR."

In the next paragraph:
  "integrity protected" -> "integrity-protected"

And
  "Such optional integrity protection might be provided by transport,
  message level signature, and use of an XML digital signature within
  EPRs."

Seems like this "and" should be "or".  For clarity, how about this
rewording:

  "Such optional integrity protection might be provided by a transport
  or message-level signature, or the use of an XML digital signature
  within an EPR."
    

Hi all,

I read the two LC drafts of WS Addressing and below are my editorial
comments (ones that I consider editorial, of course). My more
substantial comments will be sent separately.

Web Services Addressing 1.0 - Core
http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

1) in example 1-1, I suggest one leading zero in line numbers could be
dropped so it looks better (subjective, admittedly)

2) in table 1-1, namespace with prefix S11 is not necessary as it's not
used in the document

3) paragraph after table 1-1 says the examples are in XML 1.0 but this
is not a requirement, but this seems to be in conflict with the first
editorial note (in status of the document) that states that the use of
XML Schema restricts use of WSA to XML 1.0. These should be reconciled.

4) section 2.1, [metadata] says xsd:any, should say xs:any (drop the
'd')

5) the last two paragraphs describing [metadata] say: "the metadata
embedded in each of the EPRs MAY differ" but I believe the intention is
to say "the metadata embedded in different EPRs with the same [address]
MAY differ"; similarly later "to deal with conflicts between the
embedded metadata of two EPRs, ..." should likely say "to deal with
conflicts between the embedded metadata of two EPRs with the same
[address], ..."

6) last paragraph of 2.1, the reference to 2.4 should probably be in the
form of "(see 2.4 ...)", otherwise it doesn't flow with the sentence
around.

7) section 2.2 says it defines in XML Infoset-based representation and
then it doesn't use infoset terms; it uses "element" instead of "element
information item", for example. This is probably for readability
purposes and it's totally understandable, but it should be mentioned
early in 2.2 that this is the case.

8) Just above example 2-2, the URI
"http://example.com/www.fabrikam/acct" should drop the "www." part that
is inconsistent with the example.

9) in second paragraph after ednote in section 3: "Request Reply" should
probably be "Request/Reply" or "Request-Reply", i.e. with some delimiter
other than a space.

10) at the end of the same paragraph: "a variable number or replies"
should be "a variable number of replies"

11) section 3, description of [action] mentions WSDL port type where it
should probably mention WSDL interface (name changed in WSDL 2)

12) below, the description of [message id] says "a message may be
retransmitted for any purpose including communications failure" but I
don't think a communications failure is a purpose of retransmission.
Instead I'd say "a message may be retransmitted for any reason including
communications failure"

13) in the URI "http://www.w3.org/2005/03/addressing/role/anonymous" I'd
replace "role" with "address" as the rest of the document doesn't
mention roles in any way (the URI is in two places in the doc)

14) in example 3-1, instead of the ellipsis in RelationshipType
attribute value I'd put xs:anyURI, following the style of putting types
where normally one'd have values.

15) I'd rename the attribute RelationshipType to relationshipType as I
believe in W3C specs at least attributes usually start lowercased (even
if element name capitalization is inconsistent in the specs).


Web Services Addressing 1.0 - SOAP Binding
http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/

16) in example 1-1 I'd drop one leading zero from line numbers

17) section 3.2, last paragraph uses the acronym MAP without previously
introducing it, I suggest adding "(MAPs)" after the "message addressing
properties" earlier in this paragraph or just expanding the MAPs
instead, as it's only used once.

18) in section 5.5: "source should not retransmit" should probably be
"source SHOULD NOT retransmit"

19) I believe the MAY in section 6 ("receiver MAY perform additional
security ... checks") should be lower case, probably same for the SHOULD
earlier in that section, because WS-Addressing doesn't specify any means
of doing these things so it's rather informal here and the normal,
lower-case may and should would be better for readability.

20) in sections 1.2 of both documents, a reference to XML Namespaces has
a space between the link and the closing square bracket: 
"[XML Namespaces ]"

Best regards,

Jacek Kopecky

Hi,

as an LC comment for WS-Addressing, I'm unclear about why the working
group chose to use IRIs instead of URIs. All the schemas specify anyURI
which would imply the values are URIs.

I'm aware that URIs and IRIs are interchangeable, in other words that
all IRIs can be represented as URIs. I'm unsure if the there is an
unambiguous transformation from URI to IRI. 

Therefore I'd prefer the WS-Addressing specification to use the term
URI, perhaps stating that IRIs can be used (transformed into URIs as
described in the IRI spec). In any case, the distinction between URI and
IRI is mostly for presentation to a human operator, and IRIs do not
directly validate as xs:anyURI so the XML will carry URIs.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as an LC comment for WS-Addressing, I'd like to note that often in the
specifications (in both LC drafts, that is) an element description says
something like "this element (of type xs:anyURI) ..." which is
technically inconsistent with the attribute extensibility allowed
everywhere.

The normative XML Schema contains the type AttributedURIType (and
others) to make up for this, but the text should clarify that it's not
meant literally, that the element is of the stated type, rather that its
text content is of that type.

Similarly, the elements that contain other elements, like
ReferenceParameters and Metadata, don't say in the text whether they can
contain only element children or if text is also allowed and how it can
be handled.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as another editorial LC comment for WS-Addressing, I'd like to point out
that both LC documents say the XML Schema is available by dereferencing
the namespace URI provided in the same paragraph, but it would be so
much easier if that URI was in fact an HTML link. 8-)

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as an LC comment for WS-Addressing, it is my opinion that section 2.5 of
the Core spec is incomplete at best.

In particular, it concludes with "designers should consider whether they
desire standard processing per this specification in cases where their
extension is not recogonised or understood" but what if a designer comes
up with the answer that nope, they don't desire standard processing if
their extension is not understood? Either the section 2.5 should be
extended with a rationale for not allowing this scenario or a model for
required (mustUnderstand) extensions should be devised. 

For the sake of simplicity, I'd probably prefer either reusing some
existing mechanism for that (like wsdl:required), possibly raising a W3C
issue about the creation of a general mechanism (xml:mustUnderstand?),
or just saying clearly and explicitly that WS-Addressing does not
support required extensions and why.

Also, please note the typo in "recogonised" present in that text in the
spec.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as an LC comment for WS-Addressing, I'd like to voice my disagreement
with some of the WS-Addressing choices in handling replies, in
particular with the following excerpts: "if a reply is expected, a
message MUST contain a [reply endpoint]" and "If the reply is a normal
message, select the EPR from the incoming message's [reply endpoint]
message addressing property. If none is present, the processor MUST
fault".

Instead of this strict requirement for a reply endpoint, I'd prefer that
in absence of explicit reply endpoint it would be assumed to be an EPR
with the address "http://www.w3.org/2005/03/addressing/role/anonymous"
and no parameters nor metadata. This still allows the processor to fault
when a reply is generated but no reply endpoint is known (and none is
provided out-of-band), but it allows for shorter messages that transfer
replies over the same communication channel, like in HTTP request/reply.

This would remove the text "This element MUST be present if a reply is
expected" in description of ReplyTo (or soften the MUST to SHOULD), and
the description of MessageIdD would additionally be suggested (SHOULD)
when a reply is expected but ReplyTo is empty.

In fact, I'd soften the MUST around MessageID to SHOULD anyway as it is
not necessary in some cases, like the mentioned HTTP request/reply
single communication channel.

Further, section 3.2 "Formulating a Reply Message" doesn't seem to allow
faults (or replies, if you accept my suggestion above) to messages
without ID. In particular, point two describes how [relationship] is
populated in the reply message but since a fault can occur on a message
that doesn't have ReplyTo or FaultTo (therefore MessageID is optional),
this description would end up with only half of the relationship URI
pair. I believe the text should mention that no relationship will be
created in the reply message if the request message had no ID.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as an LC comment for WS-Addressing, I'd like to voice my disagreement
with the decision in WS-Addressing that action IRI is mandatory in all
WS-Addressing-compliant messages.

The spec says "It is RECOMMENDED that the value of the [action] property
is an IRI identifying an input, output, or fault message within a WSDL
port type. An action may be explicitly or implicitly associated with the
corresponding WSDL definition."

This shows that WS-Addressing ascribes semantics to WSDL operations,
which the WSDL specification doesn't currently warrant. I don't object
to this particular assumption, but you should be aware that other WSDL
users may have a different view.

WSDL 2 contains an Operation Name Mapping Requirement [1] that assumes
that the bodies of the messages in a single WSDL interface unambiguously
identify the operation, or that an extension is present that enables the
receiver of a message to identify the intended operation, and by
extension (using the above assumption) identify the intended semantics. 

Therefore, if [action] identifies the input, output or fault within a
WSDL interface, as RECOMMENDED, and if the default action pattern
currently present in the WS-Addressing WSDL Binding draft [2] is used,
and in fact if WS-Addressing action is not the mechanism for fulfilling
the Operation Name Mapping Requirement, then [action] is redundant.

That's a lot of ifs but given the current ways of generating WSDL that
are known to me it seems like a very common scenario. 

If I was implementing a Web Services stack, I'd like it to allow the use
of WS-Addressing, but not require it. Therefore I'd choose to identify
the intended semantics of messages in general from their bodies.
Therefore WSDLs generated by this tooling would either not specify
action (and thus recommend the use of the default action pattern) or
simply put the same action, for example "http://example.com/dwim", on
all messages, and by default ignore the action property in incoming
messages.

So I basically don't see a reason for [action] to be mandatory in
WS-Addressing.

I propose two options for a solution:

1) Factor [action] out of WS-Addressing, to a specification (called
WS-Semantics?) that would be optionally combinable with WS-Addressing,

2) or make [action] optional, i.e. MAY-strength,

and in both cases [action] should be formulated as an extension or
feature to be used in WSDL 2 to fulfill the Operation Name Mapping
Requirement, if the message bodies don't suffice.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/


[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Interface_OperationName
[2] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050215/#_Toc77464322

Hi,

as an LC comment for WS-Addressing, I'd like to say that I think
WS-Addressing SOAP binding should not mandate the fault reason text (in
section 5). 

For example it's unclear from the spec whether the reason for Action Not
Supported fault is "The [action] cannot be processed at the receiver."
or "The http://example.com/deleteAccount cannot be processed at the
receiver." And this difference shouldn't even matter (compare with HTTP
reason phrase) but due to the MUST in section 5 this affects compliance.

To resolve my issue, I'd like the [Reason] part to become only
recommended, or suggested, not REQUIRED.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as an LC comment for WS-Addressing, I'd like to note that in SOAP 1.2,
fault detail (the element S:Detail) can only contain element children,
which is apparently violated by sections 5.2 and 5.4 of WS-Addressing
SOAP binding.

The sections say, respectively:

5.2: [Detail] [Missing Property QName]
5.4: [Detail] [action]

The values (QName, anyURI) must be somehow enclosed in elements (or
represented as elements, which is doable for the QName) to be compatible
with SOAP 1.2 fault detail.

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Hi,

as an LC comment for WS-Addressing, I'd like to voice my support for
either using nonNegativeInteger or duration for RetryAfter timeout
(section 5.5 in WS-Addressing SOAP binding), as opposed to unsignedLong
or unsignedInt which impose unnecessary restrictions (even though
perhaps reasonable, 64 bits for milliseconds should be enough for
everyone 8-) ).

Further, the default is set to "infinite", presumably to signal that the
receiver does not expect the endpoint ever to become available again. 
I think this intent should be made explicit in the spec text, without it
I, for one, was confused for a while and wanted to suggest a more
reasonable default value.

So maybe extending the spec like this could help:

"If this element is omitted from the detail, the value is infinite,
effectively signaling that the endpoint is not expected to become
available ever again."

In case you wonder, this is the last LC comment from me at this time. 8-)

Best regards,

                   Jacek Kopecky

                   Ph.D. student researcher
                   Digital Enterprise Research Institute
                   University of Innsbruck
                   http://www.deri.org/

Our security experts have uncovered another consideration that we plan
to address in our WS-Addressing implementation.  It might prove valuable
to other implementers as well.

The current Security Considerations section (4) in the Core spec says:
  
  "Some processors may use message identifiers ([message id]) as part of
  a uniqueness metric in order to detect replays of messages. Care
  should be taken to ensure that for purposes of replay detection, the
  message identifier is combined with other data, such as a timestamp,
  so that a legitimate retransmission of the message is not confused
  with a replay attack.

We propose to append the following to that paragraph:

  "It is also advisable to use message identifiers that are not
  predictable, to prevent attackers from constructing and sending
  an unsolicited reply to an outstanding request without having to 
  see the actual request message."

Section 3 of the core states, in the description of the [message id] 
property that the [message id] is

"An absolute IRI that uniquely identifies this message in time and 
space. No two messages with a distinct application intent may share a 
[message id] property."

This is neither enforceable nor necessary.  The only functional 
requirement for message IDs is that they be sufficient to correlate 
messages.  Exactly what further requirements this imposes depend on the 
deployment.  In particular, if the reply endpoint is anonymous and the 
binding is SOAP/HTTP, there is no need for a message ID at all.

If there is no specific reason for this restriction, other than it being 
a good idea in many circumstances, then the requirement should be 
removed or at least softened to something like "Messages with distinct 
application intent SHOULD NOT have identical [message id] properties."

If there is a compelling reason for this restriction, then it should be 
strengthened to RFC 2119, as for example "Messages with distinct 
application intent MUST NOT have identical [message id] properties.", 
and the reason should be made clear.

There are currently SOAP faults for

    * Invalid Message Addressing Property
    * Message Addressing Property Required
    * Destination Unreachable
    * Action Not Supported
    * Endpoint Unavailable

In the "Invalid message addressing property" the distinction of whether 
the fault is syntactic or semantic is left to the [Reason] text, which 
we don't specify normatively.  Recovery may differ significantly for 
these two cases, and it would be better to be able to distinguish them 
easily in a standard way.  There are several other distinctions that we 
can see may occur, based on the current definitions, but do not 
distinguish in a standard way.

The set of faults should be expanded to include

    * Invalid Message Addressing Property Syntax (semantic errors
      continue to use "Invalid Message Addressing Property")
    * Unknown Relationship Type ([relationship] contained an entry with
      an unknown relation IRI)
    * Duplicate Reply Relation ([relationship] contained more than one
      reply relation entry)
    * Duplicate Message Addressing Property (multiple versions of the
      same header targeted at a given node).
    * Duplicate Message ID (assuming this is to be enforced, an endpoint
      can at least say that it has received distinct messages with the
      same ID)

There may be others, as well.

As it stands, we do not prohibit reference parameters from containing 
wsa:headers.  For example, an EPR could contain a wsa:Action header.  
This doesn't seem like a good idea, though at least it can be detected 
via the "IsReferenceParameter" attribute.  Unless there is a compelling 
use case for such behavior, it should either be discouraged (SHOULD NOT) 
or prohibited (MUST NOT).

The rules for formulating a reply in section 3.2 state that "a new pair 
of IRIs is /added /to this value as follows ..." (emphasis added).  We 
have recently clarified (in LC15) that there should only be one reply 
relation in a compliant message.  A compliant processor is required to 
produce a compliant message in response to a compliant request.

However, it is possible for a request also to be a reply, particularly 
outside the context of the usual WSDL MEPs.  In this case, the request 
message may still be compliant, but if it is, the responder is obligated 
to produce a non-compliant message by adding a reply relation to a 
message that already has one.

This could be resolved either by prohibiting request messages to have 
reply relations or by allowing (but discouraging) multiple reply 
relations in compliant messages.

Section 3.1 of the core states that "These properties [i.e., MAPs] are 
immutable and not intended to be modified along a message path."  The 
SOAP binding amplifies this by saying first (in section 3.2) "When 
sending a message each property is represented using the appropriate 
element information item as a SOAP header block." (i.e., properties must 
be represented as header blocks), and (in section 6.1) "To avoid 
breaking signatures, intermediaries MUST NOT change the XML 
representation of WS-Addressing headers. Specifically, intermediaries 
MUST NOT remove XML content that explicitly indicates otherwise-implied 
content, and intermediaries MUST NOT insert XML content to make implied 
values explicit." (i.e., the header blocks must not be changed in transit).

However, the SOAP binding also says (in section 3.2), "Note that the 
message addressing properties gathered by an intermediary when receiving 
a SOAP message do not necessarily get replayed as MAPs when resending 
the message along the message path." and also (in section 2.2) that "A 
binding that supports this feature MUST provide a means to transmit the 
properties listed above with a message and to reconstitute their values 
on receipt of a message."  This last statement appears to imply that 
there are means other than simply putting the properties in the envelope 
as headers.

Several questions arise:

    * In what scenarios would " message addressing properties gathered
      by an intermediary ... not necessarily get replayed ..."?
    * Is a binding required to put MAPs on the wire as headers, or may
      it use transport-specific representations (e.g., any routing
      headers used by an underlying transport) without echoing them as
      SOAP headers?
    * Is an intermediary forbidden from changing headers in all
      circumstances, or only when those headers are signed?

The spec seems unclear, in that there are statements that at least 
appear to conflict.  Unfortunately, I can't propose a clarification 
without better knowing the intent.

It is somewhat confusing to refer to "section 3 up to but not including 
section 3.1" (for the MAP definitions), "section 3.1" (for the MAP 
infoset) and "section 3.2" for the reply rules.  Put a different way, it 
isn't clear whether "section 3" means just those definitions or the 
whole of section 3.  If a subsection header is inserted after the 
introductory text in section 3, these become simply "section 3.1", 
"section 3.2" and "section 3.3" with no ambiguity.

Examples 3-2 and 3-3 show SOAP messages with s:mustUnderstand=1 for the 
wsa:To header, but not for any other header.  The SOAP binding says 
nothing about the mustUnderstand header at all.  If mustUnderstand is 
meant to reflect that the wsa:To header is mandatory, it should be 
present on the wsa:Action as well, but more likely this is just an 
oversight and the s:mustUnderstand attribute should be removed to avoid 
muddying the waters.

Section 3.2 specifies the behavior of a compliant processor when 
constructing the reply to "a WS-Addressing compliant request message".  
Such a message MUST contain a [reply endpoint], by the rules earlier in 
section 3, since a request message expects a reply.  Given this, it is 
not possible that no [reply endpoint] is present when constructing a 
reply under these rules.

The statement should be deleted.

The rules in beginning of section 3 and in section 3.1 say that [reply 
endpoint] is required when "a reply is expected", and similarly for 
faults.  This expectation is presumably on the part of the client 
sending the message.  When the server receives the message, how is it to 
know what was expected?  If there is no [reply endpoint], it could 
assume either that no reply was expected, or that a reply was expected 
but the sender is sending a non-compliant message.

In other words, when it matters whether a reply was expected, there is 
no way to tell.  These statements should either be removed or clarified.

 From discussion within the group, it appears that section 3 of the 
core, except for section 3.2, concerns compliance of messages, not 
processors.  In particular, the consequence of omitting a property that 
MUST be present is that the message is non-compliant, not that any 
particular processor MUST fault.  However, the notion of message 
compliance is only introduced in section 3.2, where it is used without 
explicit definition.  This makes the core liable to misinterpretation, 
as one might naturally assume that omitting a property that MUST be 
present would obligate a processor to fault.


There are (at least) two general solutions to this:

   1. Remove all MUST and REQUIRED statements from the first parts of
      section 3 and state their actual effect in section 3.2.  Since
      section 3.2 covers replies to a request message (which must have a
      [reply endpoint]), this simply means rephrasing the opening
      paragraph along the lines of:

"This section specifies how a WS-Addressing compliant processor must 
process a WS-Addressing compliant request.  Such a request is one 
containing all of: [destination], [action], [reply endpoint] and 
[message id]."

   2. Clearly state at the beginning of section 3 that the rules there
      and in section 3.1 define message compliance only and do not
      obligate a processor to fault if they are violated.

Note that even the first version is meant to preserve the behavior 
specified in the core and so is at least arguably not substantive.

The intent of the core (as I understand it) is that processors are free 
to do as they like when sent non-compliant messages.  In particular, 
this allows them to handle plain HTTP requests as they always would have.

If so, this should be made explicit in section 3.2 for the sake of 
clarity, by including a statement to the effect that "This specification 
places no constraints on the processing of non-compliant messages."

  Currently the [message id] property is required whenever [reply 
endpoint] or [fault endpoint] is present.  While correlating messages 
via [message id] is useful, it is not necessary in several plausible cases:

    * Correlation is handled at the transport level.  In such a case a
      sender may still wish to include a [reply endpoint] with an
      anonymous address, in order to ensure that a particular reference
      parameter appears in the reply, but there is no need for a message
      id per se.
    * Correlation context is provided at the SOAP level by other means,
      for example via a header containing a context or transaction ID. 
      In such a case, the receiver of a reply may already be tracking
      which messages arrive with which [action] properties in a
      particular context, and have no need to look at a message id.
    * Correlation is handled at the application level.  The body of a
      request may contain a transaction id or other correlating token,
      with this token echoed in the response, or the application
      semantics may otherwise make message ids unnecessary.
    * Correlation doesn't matter because there is no meaningful reply. 
      This basically means a "void" operation with no application-level
      faults defined.
    * Correlation doesn't matter for other reasons.  For example, if
      several requesters send requests, all of which are directed to the
      same [reply endpoint], whose job is simply to accumulate some
      aspect of the messages received without regard to what produced
      them.  The server has no need to know it is being used in this
      way, and there is no reason to require message ids.

In general, the receiver or a request has no way of knowing how the 
sender may or may not be correlating replies, and has no reason to care.

Even if an identifying token is needed for message correlation, there is 
no need to define a [message id] property.  The [reply endpoint] may 
contain any identifying token at all, for example <me:myRelationship 
type="me:InReplyTo">0xdeadbeef</me:myRelationship>.  By the existing 
rules, this will be echoed into any replies sent to the reply endpoint.  
Indeed, this is one way of handling correlation by context or 
transaction id as well.  The main value added by the [message id] 
property is that there is no need to duplicate this information in the 
[fault endpoint], in the case where both [reply endpoint] and [fault 
endpoint] are defined.  This is potentially useful, but clearly not 
essential.

Making [message id] mandatory has at least these moderate but definite 
drawbacks:

    * In cases where correlation is already being done by other means,
      carrying a redundant [message id] provides needless opportunity
      for error and confusion.
    * Producing a globally unique id for each message takes time, which
      may matter in high-volume or resource-constrained environments.
    * Similarly, requiring recipients to needlessly check for [message
      id] and echo it back also takes time.
    * In practice, client implementations are liable to produce
      non-unique IDs on the assumption that it doesn't matter anyway. 
      This misbehavior is generally not worth detecting, as it would
      require servers to remember IDs of incoming messages, but if
      undetected it can lead to mysterious behavior if that assumption
      becomes false, as correlating by a non-unique ID may well work by
      accident, most of the time.

In general, the receiver of a message should be liberal in what it 
accepts and not go out of its way to prohibit behavior that may be 
useful to the rest of the system.  Requiring [message id] without being 
able to know whether or not it is actually needed runs counter to this 
principle.

The "security model" in WS-Addressing Core and SOAP Binding amounts to 
little more than 'only process WS-Addr constructs from sources you 
trust'. Such advice is practically useless in the real world of 
services deployed on the internet.

In line with its charter to deliver "A security model for using and 
communicating these abstract properties.", the WG needs to produce:

(i) a much more detailed analysis of the security threats inherent in 
WS-Addressing and countermeasures to protect against them

(ii) if trust forms the foundation for processing of WS-Addressing 
constructs then the WG must, at a minimum, deliver an interoperable 
mechanism for establishment of such trust.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

The description of [message id] reads:

  An IRI that uniquely identifies this message in time and space. No
  two messages with a distinct application intent may share a [message
  id] property. A message MAY be retransmitted for any purpose
  including communications failure and MAY use the same [message id]
  property.

It's not clear when two message identifiers have to be different, and
when this isn't required. The specification says that one has to use
different message identifiers when the messages have "a distinct
application intent".

Assume that I want to create a new account using a SOAP message. I see
in a tutorial the following:

  To create an account, one would send a SOAP message as follows:

    <soap:Envelope xmlns:soap=?
		   xmlns:wsa=?>
      <soap:Header>
	<wsa:To>http://example.com/accounts</wsa:To>
	<wsa:Action>http://accounts.example.com/register</wsa:Action>
	<wsa:MessageId>http://example.com/mid/123</wsa:MessageId>
      </soap:Header>
      <soap:Body>
	<x:createAccount/>
      </soap:Body>
    </soap:Envelope>

Readers of the tutorial wanting to create an account may want to send
the exact same message, including the same message identifiers. After
all, the application intent is the same: create an account. Also, I am
retransmitting the above message for the purpose of interacting with
the service as described by the tutorial, which seems to fit "any
purpose".

I am naturally inclined to interpret [message id] as RFC 2822's
Message-Id: each message has a different message identifier. As a
point of reference, RFC 2822 says:

  The "Message-ID:" field provides a unique message identifier that
  refers to a particular version of a particular message.  The
  uniqueness of the message identifier is guaranteed by the host that
  generates it (see below).  This message identifier is intended to be
  machine readable and not necessarily meaningful to humans.  A
  message identifier pertains to exactly one instantiation of a
  particular message; subsequent revisions to the message each receive
  new message identifiers.

Is there any reason not to have a similar requirement? If not, what
does the sentence about "distinct application intent" means?

-=- Proposed solution -=-

Ask for unique message identifiers for distinct messages.

Replace:

  No two messages with a distinct application intent may share a
  [message id] property. A message MAY be retransmitted for any
  purpose including communications failure and MAY use the same
  [message id] property.

by:

  A message identifier pertains to exactly one instantiation of a
  particular message; subsequent revisions to the message each receive
  new message identifiers. A particular message which failed to be
  delivered MAY be retransmitted using the same [message id] property.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:[email protected] - http://www.w3.org/People/Hugo/

I have the following comments on WS-A Core
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331

Comment 1 ========= [editorial]

In the Introduction and Example 1-1 of Core, the term "message information
headers" and "message information header blocks" , respectively, are used.
This should be changed to "message addressing header...." in both places.

Comment 2 ========= [editorial]

Section 3, definition of [message id] says "...The value of this property is
an opaque IRI whose interpretation beyond equivalence is not defined in this
specification.....". The word "opaque" is not needed and should be deleted.
(There was another instance where such a use of "opaque" was removed. This
instance appears to have been missed, and should be removed for the same
reasons.)

Comment 3 =========

Section 2.1 uses the expression "consuming applications" in two places in
connection with the opacity and use of, respectively, reference parameters and
metadata. This word "consuming" can be ambiguous and/or confusing. It seems
that the the intention is that the word "consuming application" refers to an
entity which recieves an EPR and uses it to invoke a Web Service. However the
target Web Service, in turn, "consumes" some of the data implied by the
RefPars and metadata. Thus, it seems that the expression "consuming
application" could equally well apply to a user (sender) of a WS request
(using EPRs and WS-A) as well as the target Web Service itself.

Note that section 4 (first sentence) describes users of EPRs as being of at
least three types: "Users of WS-Addressing and EPRs (i.e., entities creating,
consuming or receiving Message Addressing Properties and EPRs)...etc.". Here
again, the distinction between "consuming" and "receiving" is ambiguous, as a
potential client for a Web Service can be both a "consumer" (in the sense of
section 2.1) when it receives an EPR for the target WS, as well as a
"receiver".

My proposal is as follows:

In section 2.1, replace(unchanged text not provided for clarity):

"[reference parameters] : xs:any (0..unbounded). 
..... Reference parameters are also provided by the issuer of the endpoint
reference and are otherwise assumed to be opaque to consuming applications.
........"

with

"[reference parameters] : xs:any (0..unbounded). 
..... Reference parameters are also provided by the issuer of the endpoint
reference and are otherwise assumed to be opaque to an entity that uses this
reference to invoke a Web Service. ........"

and, next, replace

"[metadata] : xsd:any (0..unbounded)
...... Metadata may be included in an endpoint reference to facilitate easier
processing by the consuming application, or because the metadata was
dynamically generated.
......."

with

"[metadata] : xsd:any (0..unbounded)
...... Metadata may be included in an endpoint reference to facilitate easier
processing by the entity that uses this reference to invoke a Web Service, or
because the metadata was dynamically generated.
......."

Comment 4
=========
[editorial]

The text in section 3 regarding the [relationship] and [reference parameter]
properties uses the expression "...the following well-known URI...". Surely
"well-known" is an exaggeration. I propose that for both these instances, the
word "well-known" be replaced with "pre-defined" or "standardized".

Comment 5
=========

In section 3, the "unspecified message" and "anonymous" destination property
values have the path segments ".../id/..." and ".../role/..." (changed to
".../address/..." per resolution of LC64 item13) for their "well-known" URIs.
For some reason the pre-defined (but not well-known? ;-)) "reply" URI does not
include any additional path segment. Why not? Conversely, are the path
segments ../id/.. and ../role/..( or ../address/..) needed?

If one is included for "reply", some suggestions are ".../type/reply" or
".../message/reply".

Comment6
========

In section 3, why is the pre-defined [action] property value of
"http://www.w3.org/@@@@/@@/addressing/fault" (defined in WS-A SOAP Binding
section 5) not included here, just like all the other pre-defined values for
various properties?

Proposed text (additions shown between <<>>):

"[action] : IRI (mandatory)
An identifier that uniquely identifies the semantics implied by this message.

It is RECOMMENDED that the value of the [action] property is an IRI
identifying an input, output, or fault message within a WSDL port type. An
action may be explicitly or implicitly associated with the corresponding WSDL
definition. Web Services Addressing 1.0 - WSDL Binding[WS-Addressing-WSDL]
describes the mechanisms of association.

<<A pre-defined [action] property value
"http://www.w3.org/@@@@/@@/addressing/fault" is used when the reply message
conveys a fault.>>"


Comment 7
=========

Why is there not a section "Formulating a Request message" equivalent to
section 3.2 "Formulating a Reply message". The existing example 3-1 could be
used, together with appropriate text, as content for such a section.

Thanks,
Nilo

Nilo Mitra
Ericsson, Inc.
desk: +1 212-843-8451
mobile: +1 516-476-7427 

Section 4 of the Core states:

    Some processors may use message identifiers ([message id]) as part
    of a uniqueness metric in order to detect replays of messages. Care
    should be taken to ensure that for purposes of replay detection, the
    message identifier is combined with other data, such as a timestamp,
    so that a legitimate retransmission of the message is not confused
    with a replay attack.

This essentially echoes advice found in at least one reliability 
standard under development.  In fact, the issue of distinguishing 
legitimate retransmissions from illegitimate replays is generic to 
layering reliability on top of security, whether or not message ids are 
present, as any message at all may be retransmitted.   The only reason 
that [message id] might need to be called out specially is that, given 
its name and putative function, one might be tempted to use it as a 
message identifier for reliability purposes.  Note that this advice is 
only relevant to implementors of reliable messaging, who are presumably 
aware of the issues in any case.  Nothing anyone else can do regarding 
[message id] will affect the situation one way or the other.

The advice that the message identifier be combined with other data is 
not quite correct.  The relevant restriction is simply that the [message 
id] should not be used as a uniqueness criterion for security purposes.  
That is, it should be left out of uniqueness determination entirely, 
despite its name possibly suggesting otherwise.  The text would be 
better worded along the lines of:

    For purposes of reliability and security, the [message id] property
    SHOULD regarded simply as another part of the message payload.  It
    SHOULD NOT be used as part of a uniqueness metric in order to detect
    replays of messages, as a message with a given [message id] may be
    legitimately re-sent for purposes of reliable transmission.

I have the following comments on: http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331

Comment 1
=========
[editorial]

Section 2 says "....to transmit the properties listed above...". It should be
"listed below", as the properties are listed in the section 2.3 that follows.

Comment 2
=========
[editorial]

Section 3.3 has text which includes "...message information header...". This
should be "...message address header...".

Comment 3
=========

Section 3.2, 2nd para has the sentence "The resulting header blocks are
targetted at the ultimate recipient in the SOAP message path (note that
extensions to WS-Addressing could be written to specify different
targetting)."

Apart from the fact that nothing in this sentence is normative, it is not
clear if constructs such as <wsa:To soap:role="http://..../next" 
soap:relay="true">, which is also targeted at the ultimate receiver, are
allowed by the present specification, without the need to create an extension
to it.

Comment 4
=========

Section 3.2, last para, last sentence states: "Note that the message
addressing properties gathered by an intermediary when receiving a SOAP
message do not necessarily get replayed as MAPs when resending the message
along the message path."

What does "replay" mean? Should it be "replaced"?

In any case, the meaning of this sentence is unclear, and should be further
explained.

Comment 5
=========
[editorial]

The explanatory text says "No endpoint can be found capable of acting in the
role of the [destination] property."

This is the fist use of the ambiguous word "role", and also differs from the
[reason] code. The proposal is to rewrite the sentence as follows:

"No endpoint can be reached for the address in the [destination] property."


====
Thanks,
Nilo

Nilo Mitra
Ericsson, Inc.
desk: +1 212-843-8451
mobile: +1 516-476-7427 

Section 1 of Web Service Addressing 1.0 - Core [1] says:

"Web Services Addressing (WS-Addressing) defines two constructs, message 
addressing properties and endpoint references, that normalize the 
information typically provided by transport protocols and messaging 
systems in a way that is independent of any particular transport or 
messaging system.

It should instead say:

Web Services Addressing 1.0 - Core (WS-Addressing) defines two 
constructs, message addressing properties and endpoint references, that 
normalize the information typically provided by transport protocols and 
messaging systems in a way that is independent of any particular 
transport or messaging system."

[added "1.0 Core"]

This will disambiguate as to which spec (of the three) is being referred to.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

Example 1-1 in Web Service Addressing 1.0 - Core [1] uses the SOAP 
binding defined in [2], but does not refer to it. A reader of the spec 
not familiar with WS-Addressing will find this a little bit confusing as 
the Core does not say anything about the SOAP binding.

I would like to suggest that a reference to the SOAP binding be added here.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
[2] http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/

Section 1.1 of WS-Addressing 1.0 Core [1] says:
"Specifically, each member of an element's [children] or [attributes] 
property is described using an XPath-like notation (e.g., 
/x:MyHeader/x:SomeProperty/@value1)."

This should be:
"Specifically, each member of an Element Information Item's [children] 
or [attributes] property is described using an XPath-like notation 
(e.g., /x:MyHeader/x:SomeProperty/@value1)."

[changed 'element' to 'Element Information Item']

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core Section 1.2 says:

"WS-Addressing may be used with SOAP [SOAP 1.2 Part 1: Messaging 
Framework] as described in Web Services Addressing 1.0 - SOAP 
Binding[WS-Addressing-SOAP]. WS-Addressing may be used with WSDL [WSDL 
2.0] described services as described in Web Services Addressing 1.0 - 
WSDL Binding[WS-Addressing-WSDL]."

The references point to SOAP 1.2 and WSDL 2.0, but not to SOAP 1.1 and 
WSDL 1.1. Given that the SOAP and WSDL binding will contain bindings to 
all the versions of SOAP/WSDL, I would like to suggest that those 
reference be added to the above paragraph.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1] , Section 1.2 says:

"Examples in this specification use an XML 1.0 [XML 1.0] representation 
but this is not a requirement."

Per the ed note in the 'status' section XML 1.0 is a requirement.

I would like to suggest that the above sentence in section 1.2 be deleted.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1], Example 1-1 (in the explanation) uses the 
term 'Endpoint Reference' whereas everywhere else the term used is 
'endpoint reference' (case difference).

I would like to suggest that the case in Example 1-1 be changed to lower 
case.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1] in sections 2.1 and 3 use notational 
conventions such as:

[address] : IRI (mandatory)

Where the part after the ":" is the 'type' of the property and the
paranthetical part specifies the cardinality.

Section 1.1 (that explains the notational convention) says that it uses 
the same notational convention as Infoset when describing the abstract 
data models. Infoset does not use the convention that is used in Core. 
This new notational conventions should be explained in section 1.1.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1] section 2.1 says:

"To deal with conflicts between the embedded metadata of two EPRs, or 
between embedded metadata and metadata obtained from a different source, 
or to ascertain the current validity of embedded metadata, mechanisms 
that are outside of the scope of this specification, such as EPR life 
cycle information 2.4 Endpoint Reference Lifecycle or retrieval of 
metadata from an authoritative source, SHOULD be used."

It is not clear which two EPRs the sentence is referring to.
I would like to suggest that the sentence be changed to:

"To deal with conflicts between the embedded metadata of two EPRs 
pertaining to the same endpoint, or between embedded metadata and 
metadata obtained from a different source, or to ascertain the current 
validity of embedded metadata, mechanisms that are outside of the scope 
of this specification, such as EPR life cycle information 2.4 Endpoint 
Reference Lifecycle or retrieval of metadata from an authoritative 
source, SHOULD be used."

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1] section 2.5  say that endpoint references are
extensible and talks about extension elements and attribute. Section 2.2 
shows how that works and provides a framework and syntax for it in the 
Infoset representation. It is not clear how one would go about extending 
the Information Model for EPRs and what extension elements and attribute 
mean in that context.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1] Section 3.1 says:

"These properties are immutable and not intended to be modified along a 
message path."

1) Is that true only for the infoset representation? If not (which I 
believe is the case) this statement needs to be moved to section 3.

2) /[reference parameters] is part of MAPs and the SOAP binding [2] maps 
the parameters to individual SOAP header blocks. These properties can 
contain SOAP 1.1/1.2 actor/role attribute that target specific SOAP 
forwarding intermediaries in the message path. The header blocks 
targeted to a forwarding intermediary will be consumed by the 
intermediary and then it will move the message along the message path 
*without* the header block in it (unless the semantics of the header 
blocks require reinsertion). Such a mapping, in fact, facilitates the 
properties being change along the message path.

The statement quoted above contradicts what the mapping in [2] enables 
one to do. Either the mapping in [2] should be changed, the above 
sentence removed/modified or appropriate warnings/restrictions be 
included in [2].

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
[2] http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331/

WS-Addressing 1.0 Core [1] talks about 'request' and 'reply' message and 
define normative statements about those messages in the context of 
WS-Addressing. But, it does not define/specify what 'request' 'reply' 
message are.

There is no general accepted understanding of what such messages mean. 
The specification should either remove those statements or define 
exactly what they mean or move the statements in question to the WSDL 
binding where request/response (or in/out) are well defined.

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

WS-Addressing 1.0 Core [1] Infoset representation of EPRs (as well as 
the XML 1.0 representation as described/typed by the Schema) allows 
extensibility attributes on the elements:

/wsa:EndpointReference/wsa:Metadata
and
/wsa:EndpointReference/wsa:ReferenceParameters

the Information model equivalent of which are:

[metadata] : xsd:any (0..unbounded)
and
[reference parameters] : xs:any (0..unbounded)

Given that [metadata] and [reference parameters] are collection of 
individual parameters (or elements/EIIs), how/where do the extensibility 
attributes on /wsa:EndpointReference/wsa:Metadata and 
/wsa:EndpointReference/wsa:ReferenceParameters fit in? If not, why is 
the Infoset mapping > Information model?

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

Sorry this is late (is it still 5/11 somewhere in the world?), I hope it
is still simple enough to accept as a Last Call comment against WS-A.

It is unclear, when extracting an [address] from an EPR's address, and
placing it in a message's [destination] property, and then into a wsa:To
header, what modifications of an IRI's lexical representation are
allowed.  To clarify that no %-escaping is performed, we ask that the
following modification be made to the spec:

Replace the third bullet of
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html
#bindrefp:

- The value of each message addressing property that is of type IRI MUST
be serialized as an absolute IRI in the corresponding SOAP header block.

With:

- The value of each message addressing property that is of type IRI MUST
be serialized as an absolute IRI in the corresponding SOAP header block.
No additional %-escaping is performed.

This is an editorial comment. 

WSD wg has adopted a BNF style for designating pseudo schemas and used
in WSDL 2.0 specifications consistently. The definition is available in
the current WSDL 2.0 Core Language specification [1], in section 1.4.8.
Using this style differentiates a pseudo schema from an actual example
that contains a concrete schema or a document fragment. Further, it
improves the readibility of the pseudo schemas. The values of attributes
and elements are designated by schema types in italics when actual
values are not used. 

I propose the wg to adopt the same pseudo schemas style to improve the
readability of Example 2.1 and Example 3.1 in the WS-Addressing Core
Specification [2] and whenever pseudo schemas are needed in the future
for other WS-Addressing specs. I recommend referring to WSDL 2.0 Core
Language specification for examples throughout. 

As an example, Example 3.1 states the following: 

<wsa:MessageID> xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
<wsa:To>xs:anyURI</wsa:To>
<wsa:Action>xs:anyURI</wsa:Action>
<wsa:From>endpoint-reference</wsa:From>
<wsa:ReplyTo>endpoint-reference</wsa:ReplyTo>
<wsa:FaultTo>endpoint-reference</wsa:FaultTo>

By adopting the style, xs:anyURI would be in italics,
"endpoint-reference" should be replaced by wsa:EndpointReferenceType in
italics. 

<wsa:MessageID> xs:anyURI </wsa:MessageID>
<wsa:RelatesTo RelationshipType="..."?>xs:anyURI</wsa:RelatesTo>
<wsa:To>xs:anyURI</wsa:To>
<wsa:Action>xs:anyURI</wsa:Action>
<wsa:From>wsa:EndpointReferenceType</wsa:From>
<wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo>
<wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo>



Thanks, 

--umit

[1] http://www.w3.org/TR/2005/WD-wsdl20-20050510/#bnfpseudoschemas
[2] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

The Web Services Description WG reviewed the WS-A specs, and had these
editorial comments on Section 3 of the Core spec touching on
WSDL-related terminology:

- "The basic interaction pattern from which all others are composed is
"one way"." It would be preferable to use "one way" in a manner
consistent with the use of the term for the WSDL 1.1 transmission
primitive - "One-way". 

- "Request Reply" is a common interaction pattern...." Likewise, it
would be preferable to use "Request Reply" in a manner consistent with
the use of the term for the WSDL 1.1 transmission primitive -
"Request-Response". 

- "...or to a particular WSDL MEP." Since this spec primarily references
WSDL 1.1 transmission primitives, shouldn't this be consistently worded
as "...or to a particular WSDL transmission primitive or MEP." (to
capture support of WSDL 1.1 and 2.0)? 

- In the description for [action], we have "...within a WSDL port type."
Shouldn't this be consistently worded as "...within a WSDL port type or
interface." (to capture support of WSDL 1.1 and 2.0)?

These comments were compiled by Charlton Barretto, who also identified
other general editorial issues which we expect him to file separately.
Please accept our apologies for the tardiness of the above comments, and
for our delay of Charlton's additional comments.

Thank you.
Jonathan Marsh on behalf of the WS Description WG

         
Hi WS-Addressers,

Apologies for the late comment, but since this is just "adding weight"
to a comment you've already received, I hope you won't mind too much.

At the WSDL telcon on May 5, we discussed Jacek's comments [1], and the
WSD group agreed to send you this further comment noting that the WSDL
group as a whole agrees with the substance of the particular comment
Jacek sent here [2] regarding the optionality/defaulting of ReplyTo.  We
felt that since under the current rules <wsa:ReplyTo> is mandatory
even when using the currently-spec'ed WSDL/SOAP/HTTP request/response
patterns, a lot of bytes could be saved by doing defaulting and
optionality as Jacek suggests.

Thank you for your consideration,
--Glen (on behalf of the WSDL WG)

      Section 3.1.1 says:
         A property of the binding or endpoint named {addressing required}
            of type xs:boolean
            
         should be phrased:
         
         A property {addressing required} of type xs:boolean, to the
            Binding and Endpoint components

Section 3.1.1 says:
            
            A property of the binding or endpoint named {addressing required} of
            type xs:boolean. The property value is the value of the
            wsdl:required attribute information item on the wsaw:UsingAddressing
            extension element, if present; otherwise "false".
            
            It means that, if a WSDL processor supports WS-Addressing, this property will always be present. There are basically 2 states:
            - {addressing required} = true
            - {addressing required} = false
            
            However, using the wsaw:UsingAddressing, you have 3 states:
            - <wsaw:UsingAddressing />
            - <wsaw:UsingAddressing wsdl:required="true" />
            - no wsaw:UsingAddressing in the document
         

So, it should be made clear that {addressing required} is an optional property, whose value is "true" if wsaw:UsingAddressing is present and wsdl:required="true" is present, "false" if wsaw:UsingAddressing is present by wsdl:required is not equal to "true", and not present otherwise.

Section 3.3 WSDL SOAP Module says:
            
            In WSDL 2.0, the wsoap:module construct may be used to declare the
            use of the WS-Addressing 1.0 Module for the SOAP binding. The
            meaning of such a wsoap:module declaration is semantically
            equivalent to wsaw:UsingAddressing in this case. Note that this
            module is not meaningful when used on WSDL constructs where
            wsaw:UsingAddressing is not allowed.
            
            The last sentence could be made clearer. As wsaw:UsingAddressing is
            only allowed at the binding or endpoint component level, it means
            that the declaration of use of the WS-Addressing 1.0 SOAP Module can
            only be made at the binding component level. It should probably be
            spelled out.
            
            Also, this would be better expressed in terms of components.
            

Typos in section 2.1:
            - "by by" -> "by"
            - "http://example.com/www.fabrikam/acct" -> "http://example.com/fabrikam/acct"
         

The XML example 4-1 is wrong since it uses <definition> as the root element. It should use <description>.

Section 4.3 defines the use of <wsa:ReferenceParameters> but does not say how this affects the WSDL 2.0 component model. Does this add a property to Endpoint?

            In the past wsdl and it's well defined extensions (soap, http, mime) have 
            all use lower case element names.  Is there a reason why the wsaw 
            element's use a leading upper case?   Perhaps it's a minor point ... but 
            things would look consitent if wsaw:UsingAddressing wsd redefined to be 
            wsaw:usingAddressing.
            
            <binding name="reservationSOAPBinding" 
               interface="tns:reservationInterface"
               type="http://www.w3.org/2006/01/wsdl/soap"
               wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
               <wsaw:UsingAddressing wsdl:required="true" />
               <operation ref="tns:opCheckAvailability"
                  wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
               <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender" /
            </binding>
         

         example reads
            fault action = http://example.com/stockquote/StockQuotePortType/GetLastTradePriceFault/Error
         example should read
            fault action = http://example.com/stockquote/StockQuotePortType/GetLastTradePrice/Fault/Error
         

         Here are a few editorial comments, based on the 3/3/06 draft of the WSDL
         binding:
         
         * The third paragraph of section 3.2 (Anonymous Element) states that
         The wsaw:Anonymous element MAY have three distinct values.  RFC
         2119 MAY refers to optionality, so strictly speaking this means
         that the wsaw:Anonymous either has three distinct or it doesn't at
         the discretion of the implementor.  This should probably read "...
         MUST have one of three distinct values ..."
         * Section 3.2.1 defines the {anonymous required} WSDL property that
         reflects the value of the wsaw:Anonymous element.  This may have
         one of the three values "optional", "required" or "prohibited". 
         The name {anonymous required} (unlike wsaw:Anonymous) strongly
         suggests a boolean, and having "prohibited" as a value for
         {anonymous required} seems confusing.  Either calling it
         {anonymous} in line with wsa:Anonymous or something like
         {anonymous EPR constraint} might be less potentially confusing.
         * The first paragraph of section 4.2.1 refers to the [action]
         property of messages and says that if no value is given it reverts
         to the SOAPAction if any.  This isn't referring to the actual
         [action] property of the message in question -- putting something
         in a WSDL doesn't automatically cause messages to contain that
         property.  Instead it's talking about what the endpoint is saying
         it will accept and produce for the [action] property. 
         Unfortunately, I'm not sure how the wording can be improved (but I
         would take an action to come up with a better wording if need be)
         * If wsaw:Action appears without wsaw:UsingAddressing it's only
         informational.  Do we want to mention that it could indicate a
         desired SOAPAction?  Probably not.
         * Nit: In section 5, we talk about properties being "mandatory" or
         "optional".  "Required" might be better than "mandatory", since
         things like RFC 2119 use "required"/"optional" and not
         "mandatory"/"optional".  On the other hand, WSN ended up changing
         a few instances of "optional" in the case of "optional elements"
         because we didn't think it really matched the RFC 2119 sense.  I
         believe we settled on "can be omitted".  The main issue is whether
         we specifically want use RFC 2119 terms here, specifically don't
         want to use them, or don't care.         
      

            Here are a few editorial comments on the Last Call Working Draft
            
            Section 1:" (for backwards compatibility" is missing a closing bracket
            
            Section 4.2.3: "the property value is the value of the wsaw:action 
            attribute" should be wsaw:Action
            
            Section 4.2.4: "In the absence of the wsa:Action attribute" should be 
            wsaw:Action
            
            Example 4.1 title uses wsaw:Action and titles for 4.2, 4.5, 4.8, 4.9 use 
            wsa:Action. All examples show similar things. Both wsa:Action and 
            wsaw:Action make sense in this context but it should be consistent.
            
            David
            
         

            There are the following typos(?) in SOAP Binding spec:
            
            1) WSA WSDL binding (wsaw)  namespace is: 
            http://www.w3.org/2005/03/addressing/wsdl.  Needs updating to 
            http://www.w3.org/2006/02/addressing/wsdl.
            
            2) "The SOAP processing model dictates that message addressing properties 
            targeted at an intermediary do not normally get relayed as message 
            addressing properties when the message is forwarded along the message 
            path. The specification for a SOAP header used as a reference property or 
            use of the soap:relay attribute can override this default behaviour."
            Should be "reference parameter"
            
            Thanks
            Katy       
         

            EDITORIAL SUGGESTION:
            Section 2.1
            Do we need to specify cardinality for InterfaceName, ServiceName and 
            EndpointName - i.e. to ensure that there are never multiple ones 
            specified?
            Section 2.2
            As above but with embedded WSDL definitions - do we need to specify max 
            1?
         

            Along the document, we can read instances of "conforms to", but no  
            where it is said what does that mean to "conform to". Please Create a  
            conformance section and name it as such.
            http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216/#tocRange
            See http://www.w3.org/TR/qaframe-spec/#include-conformance-clause-principle
                        

         Please define the class of products of your specification.
            http://www.w3.org/TR/qaframe-spec/#implement-principle
         [[[
         Clearly identify the class of products (i.e., type of products or  
         services) upon which the requirements are imposed.  If multiple  
         classes of products are targeted by the specification, make sure each  
         is described.   Examples of classes of products include: content,  
         producer of content, player, protocol, API, agent, and guidelines.
         ]]]
         

         Typo
         
         [[[
         3.1 UsingAddressing Extension Element
         ]]]
         
         -- Web Services Addressing 1.0 - WSDL Binding
            http://www.w3.org/TR/2006/WD-ws-addr-wsdl-20060216/#tocRange
         Thu, 16 Feb 2006 20:29:34 GMT
         

Kudos to the committee for at long last standardizing asynchronous messaging over a synchronous protocol, i.e. HTTP. This 'last minute' addition will perhaps do more to simplify the architecture of web services based applications than anything else you have contributed. Nice job. One observation, and please forgive me if this has already been addressed within the discussions following the release of the latest working draft. It would appear that by adding an extension element to an existing binding rather than creating a new binding type, the choice of whether to send a request synchronously or asynchronously, i.e. assuming Anonymous is optional, will be impossible to make within the 'application layer.' Using BPEL4WS as an example, an application, i.e. a process in this case, indicates binding selection implicitly via endpoint assignment. Unless I am missing something, how would a process designer choose to invoke an in-out operation synchronously rather than asynchronously, and vice versa, if the service invoked has only one endpoint, i.e. a SOAP/HTTP endpoint? BTW, assuming this is a valid problem, I understand that creating a new binding type is not trivial and may not be an option at this stage in the game. If that's the case, I would MUCH rather keep the existing solution as-is rather than remove it altogether. It is a HUGE improvement over the current mess, i.e. request response using two one way operations.

Todd Wolff

Bluestem Software LLC

            Section 3.2: Anonymous Element.
            
            wsaw:Anonymous does not correspond well with the features of WCF.
            Instead of providing a single SOAP binding that can be parameterized at
            will to accept anonymous URIs, our implementation provides separate SOAP
            bindings for anonymous and non-anonymous cases.  This makes direct
            support for the "optional" value impractical for us to support during
            the CR testing phase.  For this reason we'd like to see wsaw:Anonymous
            functionality deferred so it doesn't hold up the rest of the
            specification.  However, the current design also places undesirable
            limits on the evolution of anonymous handling in the future.
            
            In general we are currently tending towards favoring sets of composable
            assertions rather than a monolithic, though parameterized, assertion or
            extension.  In WS-Policy generally, multiple assertions with distinct
            QNames are preferably to a single assertion that uses attributes and/or
            content to distinguish different cases. For example, given two possible
            assertion designs;
            
            1. <A1/>
               <A2/>
               <A3/>
            
            2. <A Parameter='1' />
               <A Parameter='2' />
               <A Parameter='3' />
            
            then design 1 would generally be preferred because it allows the policy
            matching logic to provide more accurate matches between policies.
            Anonymous handling currently feels more like design 2.
            
            This results in a suboptimal expression of anonymous handling when
            UsingAddressing appears as a policy assertion.  The lack of a
            "ws-addressing engaged" primitive assertion prevents UsingAddressing
            (used as a policy expression, a WSDL extension, or through the soap
            module synonym) from composing well with other primitive (or composite)
            extensions or assertions that govern the handling of anonymous.
            
            For instance, we plan to develop and deploy policy assertions which
            represent composite functionality, one aspect of which may be
            constraints upon anonymous handling.  As far as WS-Addressing is
            concerned, this represents out-of-band specification of
            wsaw:Anonymous-like capability.  Unfortunately, the value space of
            wsaw:Anonymous is not extensible, and forces one to make claims as to
            the treatment of anonymous addresses.  Other assertions may contradict
            the claims made in wsaw:Anonymous, impeding consistent and accurate
            description and therefore interoperability.  Another bad effect of only
            providing a composite design is that anonymous address handling cannot
            be separately negotiated at runtime through trial and fault.
            
            Because there is no way to say, "I'm using addressing, but making no
            design-time claims here as to support for anonymous addresses",
            wsaw:UsingAddressing is unsuitable as a universal mechanism for engaging
            addressing.  Rather than a composite assertion covering both engagement
            of WS-Addressing and anonymous handling, we'd prefer to have composable
            primitives representing this orthogonal functionality.
         

            Section 4.1 Destination
            
            This section says "In the absence of additional runtime information, the
            value of the [destination] message addressing property for a message
            sent to an endpoint MUST match the value of the {address} property ..." 
            
            The use of MUST in conjunction with "additional runtime information"
            makes this phrase a bit confusing.  The MUST implies that this condition
            is testable, but the rest of the text shatters that implication.   
         

            Section 3.1 UsingAddressing Extension Element
            
            
            
            Table 3-1 purports to constrain the behavior of an endpoint based on
            soap:mustUnderstand in the input message, when wsaw:UsingAddressing is
            not present.  If we had a conformance clause defining conformance to
            wsaw:UsingAddressing, it would be more apparent that the definition of
            wsaw:UsingAddressing cannot reasonably constrain the behavior when
            wsaw:UsingAddressing is not used.  There are two ways to address this
            problem.
            
            
            
            First, one could remove the column "UsingAddressing Not Present" from
            the table, and therefore collapse the first two rows, removing mention
            of soap:mustUnderstand on input messages.  This is preferable because
            this spec can't and shouldn't attempt to constrain the behavior of
            soap:mustUnderstand, especially in the case where this spec isn't even
            engaged by the presence of wsaw:UsingAddressing!
            
            
            
            An alternative is to clarify which parts of the table are normative or
            not, by adding "(non-normative)" to the title of the last column to make
            it clear that we're restating for the reader's convenience behavior
            defined outside this specification.
            
         

            Section 4.3 ReferenceParameters
            
            The current mechanism for embedding EPR information in a WSDL
            endpoint/port misses an opportunity to provide some useful benefits,
            which would be regained by embedding the whole EPR rather than just the
            ReferenceParameters element.
            
            
            
            1.	Address information can appear in WSDL in a variety of ways.  In
            WSDL 1.1 it can appear in the wsoap11:element attribute, or in the
            wsoap12:address element if the WSDL 1.1 Binding Extension for SOAP 1.2
            submission [1] (acknowledged by W3C yesterday) is used.  In WSDL 2.0 it
            can appear in the wsdl:endpoint/@address attribute.  Allowing
            wsa:Address to extend the endpoint/port provides a consistent way to
            serialize addresses regardless of the WSDL and SOAP version in use. 
            2.	Deconstructing an EPR to serialize it into WSDL requires special
            serialization code.  Instead of having a single codepath for serializing
            an EPR, we need a WSDL-specific way to serialize just the
            ReferenceParameters. 
            3.	Multiple serializations become increasingly painful as EPR
            extensions are developed, which would each have to be serializable in
            two flavors - EPR extensions, and endpoint/port extensions. 
            4.	Every EPR extension would also have to be defined both as an EPR
            extension and as a WSDL extension, making the development of EPR
            extensions more complex. 
            5.	We currently use 2004/08 EPRs as WSDL extensions without
            deconstructing them, and we'd like a consistent model between the
            submitted and standardized models. 
            
            
            [1] <http://www.w3.org/Submission/wsdl11soap12/>
                        

            "A policy expression containing the wsam:Addressing policy assertion 
            MUST NOT be attached to a wsdl:portType or wsdl20:interface. The 
            wsam:Addressing policy assertion specifies a concrete behavior whereas 
            the wsdl:portType or wsdl20:interface is an abstract construct."
            
            How/why does the wsam:Addressing specify a concrete behavior? We have 
            core and soap-binding spec. The proposal does not make it clear (I hope 
            I didn't miss it) as to compliance to which spec is made by the 
            assertion. We should spell that out.
            
            For example, what happens when the assertion is made on an endpoint that 
            does not use SOAP. I imagine that the conformance to only the core spec 
            is made (and not to some additional WS-Addressing binding that may have 
            been defined for the protocol that is being used).
            
            What happens when the assertion applies to an endpoint that uses SOAP, 
            is the claim about conformance to core+SOAP-binding or just core?
            
            Furthermore, WS-Addressing Core is an abstract spec. It would be very 
            useful to make an assertion on the portType/interface to say that all 
            bindings/endpoint for this portType/interface must use ws-addressing 
            (because the abstract contract depends on the MAP values). This is 
            especially true if one views ws-addressing as a bidning-independent 
            "core" spec on which applications and abstract contracts will have 
            dependencies.
            
         

            wsa:Addressing assertion (by itself) is stated as having no 
            restriction on the endpoint (wrt anon/non-anon). This could be 
            interpreted to mean that the endpoint is claiming to accept both anon as 
            well as non-anon replyTos. Perhaps that is not intended, but I like the 
            model where no nested assertion means no claim is made about the 
            accepted values.
            
            Section 3.1.1 says:
            "The wsam:Addressing assertion does not indicate any restrictions on the 
            use of WS-Addressing unless otherwise qualified by assertions in its 
            nested policy expression."
            
            Suggestion -- add this:
            "In the absence of a nested policy expression, no claim is made about 
            requirement or acceptance of either the anonymous or non-anonymous URI 
            as the value of the [address] property contained in the response EPR of 
            the request message."
            
         

         A while ago I suggested that we have a way of saying things like
         "non-anon response endpoints must be mailto: (or fit some other
         pattern)".  Our decision was to leave this out of scope, which is fine
         with me, but we want to be sure not to disallow it.
         
         Suppose I make an assertion, basically "the service support non-anon",
         generically.  Later, you want to refine that by saying, "Well, actually,
         the service only supports mailto: non-anon".  As I understand it, policy
         intersections are aimed at this sort of thing.
         
         However, if I intersect a policy that says "non-anon allowed" with one
         that says "mailto: only", I get the empty set, since the two assertions
         are different.  I would like to get "mailto: only".
         
      

There is a need for a specification of how to attach policy on endpoint 
        subject level to
        an EPR.
        
        At this point, the fastest way forward might me a small W3C spec devoted 
        to that subject
        produced by the WS-Addressing WG.
        
        I would like to add this to the discussion on the WS-addressing call.

            According to section 4.4
            
            "Ensuring that there is sufficient information within a message to 
            distinguish which WSDL operation it is associated with is specified as a 
            best practice in WSDL 2.0WSDL 2.0. The [action] property provides a 
            mechanism to fulfill that best practice."
            
            Unfortunately, the default action pattern for a WSDL 2.0 fault message does 
            NOT "fulfill that best practice."  If more than one operation throws the 
            same fault, one cannot, using the wsa:action value, distinguish which 
            operation a message is associated with.
            
            Even if defined explicitly, there is not enough granularity to distinguish. 
            The atttribute should instead be defined on the fault reference element, and 
            the default pattern adapted accordingly.
         

The latest policy domain specifications (WS-TX, WS-RX and WS-SX) are 
         moving towards a model where the assertions are valid within  WS-Policy 
         1.2 (http://schemas.xmlsoap.org/ws/2004/09/policy/) *OR* WS-Policy 1.5 
         (http://www.w3.org/ns/ws-policy/) attachments.
         
         For example, take a look at the latest ReliableMessaging policy here: 
         http://docs.oasis-open.org/ws-rx/wsrmp/200702. 
         
         Section 1.4 of the RM spec at the above location states:
         "The assertions defined within this specification have been designed to 
         work independently of a specific version of WS-Policy.  At the time of the 
         publication of this specification the versions of WS-Policy known to 
         correctly compose with this specification are WS-Policy 1.2 and 1.5. 
         Within this specification the use of the namespace prefix wsp refers 
         generically to the WS-Policy namespace, not a specific version."
         
         Could we consider something similar in the WS-Addressing metadata spec? 
         This would mean similar text in the namespace section of the spec and 
         removing direct references to WS-Policy 1.5 (e.g. in the first sentence of 
         section 3.1)   This will alleviate potential forward compatibility issues 
         as well as allowing for current backward compatibility with WS-Policy 1.2.

Section 3.1.1: The current text is somewhat confusing.  Unless
          WS-Addressing seeks to define its own semantics on wsp:Optional, it is
          best to defer to WS-Policy Framework with a reference.
          
             Change from:
                 In order to indicate that the subject supports WS-Addressing
         but
                 does not require its use, an additional policy alternative
                 should be provided which does not contain this assertion. This
                 may be done in WS-Policy compact form by adding the attribute
                 |wsp:Optional="true"| to the |wsam:Addressing| assertion.
          
             Change to:
          
                 The optional assertion mechanism wsp:Optional, the compact
                 authoring style defined by WS-Policy Framework, is used to
                 specify that the subject supports WS-Addressing but does not
                 require its use for the |wsam:Addressing| assertion (See
                 WS-Policy Framework v1.5 [link]).