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: public-ws-addressing-comments-request@w3.org [mailto:public-ws-
> addressing-comments-request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Tuesday, April 12, 2005 9:05 AM
> To: public-ws-addressing-comments@w3.org
> 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.'