Web Services Addressing Last Call Issues List

Issue List Revision: 1.110 , Date: 2007/06/25 17:49:16

XSL Revision: 1.13 , Date: 2007/04/02 22:03:32

Statistics

core soap wsdl meta schema all total
active 0 0 0 0 0 0 0
proposed 0 0 0 0 0 0 0
closed 63 35 22 12 1 8 142
duplicate 1 0 0 0 0 0 1
dropped 0 0 0 0 0 0 0
total 64 35 22 12 1 8 143

Open Issues Summary

id owner title target type SC

Closed Issues Summary

id owner title target type SC
lc1 Interaction between Faults and [message id] and [reply endpoint] etc. all
lc2 Editorial Comments core
lc3 Endpoint Reference not properly defined in section 2.2 core
lc4 WS-Addressing restricted to XML 1.0 or not? core
lc5 Utility of [source endpoint] property not clear core
lc6 Disambiguate the Conformance statements in WS-A SOAP Binding specification soap
lc7 Typographic nits core
lc8 Rationalize URI vs. IRI core
lc9 Reinforce absolute IRIs core
lc10 EIIs have QNames? core
lc11 Ref param opacity core
lc12 Ref param data encoding core
lc13 Clearer wording for Section 2.1 core
lc14 Clearer wording for Table 3-1 core
lc15 Disallow multiple "reply" relationships core
lc16 Allow dispatch on more than [destination] and [action] core
lc17 Anonymous not limited to replies core
lc18 [children] inconsistency core
lc19 Clarify [destination] comparison core
lc20 Clarify Anonymous URI and for the case of HTTP responses core
lc21 Anonymous and [destination] over-constrained core
lc22 Header extensibility processing model core
lc23 RE: Rationalize URI vs. IRI soap
lc24 Typographical nits soap
lc25 Merge Core and SOAP Binding specs soap
lc26 Clarify which fault if SOAP Action and wsa:Action don't match soap
lc27 Clarify distinction between XML Infoset representation and SOAP headers soap
lc28 Mixed notation and indirect terminology for MAPs soap
lc29 wsa:isReferenceParameter inconsistent casing soap
lc30 Formal definition of wsa:isReferenceParameter soap
lc31 wsa:IsReferenceParameter clashes soap
lc32 Note effect of wsa:IsReferenceParameter on validation soap
lc33 Binding rules don't appear to allow optional headers soap
lc34 Duplicate headers at the ultimate receiver soap
lc35 Clarify conformance requirements soap
lc36 Clarify Invalid Message Addressing Property and Message Property Required Faults soap
lc37 More Security Considerations soap
lc38 Feedback on xs:nonNegativeInteger soap
lc39 Question regarding cardinality of [destination] core
lc40 Example 3-1 core
lc41 Table 3-1 core
lc42 Order of items in section 3 and 3.1 core
lc43 S11 in Table 1-1 core
lc44 Section 4 core
lc45 Bad URL's core
lc46 Section 3.2 core
lc47 Bad URL's soap
lc48 typo in xsd schema
lc49 Section 5 soap
lc50 IRI for SOAP 1.2 Module and SOAP 1.1 Extension soap
lc51 order of items in section 2.3 soap
lc52 MessageId vs MessageID soap
lc53 introduction of MAP and MEP terms soap
lc54 why does this spec mandate a dispatching model? core
lc55 ReplyTo and security all
lc56 Binding fault [detail] in SOAP 1.1 envelope soap
lc57 Normative text for fault properties binding soap
lc58 Intermediary Processing soap
lc59 Missing xml namespace prefix declaration soap
lc60 entire route in ws-addressing all
lc61 Migration Contracts in Core core
lc62 Migration Contracts in SOAP binding soap
lc63 Wording clarifications in Core Section 4 core
lc64 ws-addressing LC review editorial comments all
lc65 use of IRIs in WS-Addressing all
lc66 presentation of typing information in element descriptions all
lc67 dereferencing namespace URI - but no link (editorial) all
lc68 no mustUnderstand extensibility core
lc69 mandatory ReplyTo, handling replies in WS-Addressing core
lc70 mandatory action core
lc71 mandatory fault reason soap
lc72 content of fault detail soap
lc73 nonNegativeInteger or duration for RetryAfter soap
lc74 Another Security Consideration core
lc75 Uniqueness of [message id] core
lc76 Supported faults soap
lc77 MAPs in EPR reference params soap
lc78 Multiple reply relationships core
lc79 Rewriting by intermediaries core
lc80 Definitions of MAPs in core section 3 should have their own subsection core
lc81 Use of mustUnderstand=1 in example core
lc82 "... the processor MUST fault" in section 3.2 is vacuous. core
lc83 When is a fault/reply expected? core
lc84 Message compliance core
lc85 Processors unconstrained in the face of non-compliant messages. core
lc86 [message id] should be optional core
lc87 Security model is insufficient all
lc88 Uniqueness of [message id] core
lc89 Comments on WS-A Core core
lc90 Security implications of [message id] in re-transmissions core
lc91 Comments on WS-A SOAP Binding soap
lc92 Editorial nit core
lc93 Editorial nit regd Example 1-1 in Core core
lc94 section 1.1 editorial nit core
lc95 section 1.2 (references) core
lc96 requirement of XML 1.0 core
lc97 inconsistent use of 'Endpoint Reference' (ed nit) core
lc98 Notational conventions not explained core
lc99 section 2.1 -- what does 'each of the EPRs' refer to core
lc100 section 2.1 -- unclear wording regarding conflicts between metadata core
lc101 How does one extend the abstract properties of an endpoint reference core
lc102 immutability of MAPs core
lc103 what is a 'request' and what is a 'reply'? core
lc104 XML infoset representation of EPR > Information model core
lc105 IRI escaping when constructing a reply soap
lc106 Editorial Comment core
lc107 WS Description WG comments on WS-A core
lc108 Comment from WSDL group on ReplyTo core
lc109 Should [fault endpoint] be required for robust in-only message? wdsl
lc110 Should [fault endpoint] be prohibited in Robust in-only fault messages? wsdl
lc111 Section 3.1.1 clarity wsdl editorial
lc112 Three states in two wsdl
lc113 Section 3.3 clarity wsdl
lc114 Typos in section 2.1 wsdl editorial
lc115 Example 4-1 is wrong wsdl editorial
lc116 use of wsa:ReferenceParameters wsdl
lc117 Why are the WS-Addressing WSDL binding elements capitalized? wsdl editorial
lc118 typo in example 4-8 wsdl editorial
lc119 WSDL binding editorial comments wsdl editorial
lc120 David Illsley's Editorial issues Vol 1 wsdl editorial
lc121 Katy's editorial issues vol 1 wsdl editorial
lc122 Cardinality for InterfaceName wsdl
lc123 Example Improvement suggestion wsdl editorial
lc124 Jonathan Marsh Conformance section wsdl editorial
lc125 Robert Freund Define the class of products of your specification wsdl editorial
lc126 WS-Addressing typo 3.1 Using wsdl editorial
lc127 Jonathan Marsh Application choice of synchronicity wsdl
lc129 Francisco Curbera Changes to wsaw:Anonymous wsdl design
lc130 Clarify section 4.1: Destination wsdl
lc131 UsingAddressing and soap:mustUnderstand wsdl
lc132 Reference Parameters vs. complete EPRs wsdl
lc133 WS-Policy's review of Metadata LC1 meta design
lc134 Policy Attachment to wsdl:portType or wsdl20:interface meta design
lc135 Clarify text that the addressing assertion alone does not indicate restriction meta editorial
lc136 Non-anon extensibility and policy intersection meta design
lc137 Need for new Rec or TR on attaching policy to EPR meta design
lc138 Need new namespace for second last call meta design
lc139 Provide explanation of namespace stability in namespace document meta design
lc140 Update WS-Policy 1.5 namespace reference in WS-Addressing metadata schema meta design
lc141 Action Property meta design
lc142 WSP namespace - interoperability and forward compatibility meta design
lc143 Editorial comment on 3.1.1 meta editorial
lc144 Editorial comment to 4.4.4 meta editorial
SC key:
* open issue with at least one proposal
+ issue with action item
resolution accepted by reviewer
resolution rejected by reviewer

Detailed Listing

lc1 Interaction between Faults and [message id] and [reply endpoint] etc. all - - closed
Description

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
Origin
Prasad Yendluri (source)
Resolution 2005-04-19
Add to the second paragraph of section 5, is "The [message ID], [fault endpoint] and [reply endpoint] properties facilitate the delivery and correlation of faults." The editors may also add a reference to the Core.
lc2 Editorial Comments core - - closed
Description
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."

         
Origin
Prasad Yendluri (source)
Resolution 2005-04-19
Accepted proposed changes.
lc3 Endpoint Reference not properly defined in section 2.2 core - - closed
Description

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
Origin
Prasad Yendluri (source)
Resolution 2005-04-19
Drop xs:any from example.
lc4 WS-Addressing restricted to XML 1.0 or not? core - - closed
Description
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
Origin
Prasad Yendluri (source)
Resolution 2005-04-19
Drop the editorial note.
lc5 Utility of [source endpoint] property not clear core - - closed
Description
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
Origin
Prasad Yendluri (source)
Resolution2005-07-19
Mark feature at risk (reviewer present).
lc6 Disambiguate the Conformance statements in WS-A SOAP Binding specification soap - - closed
Description

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
Origin
Prasad Yendluri (source)
Proposal 1 2005-05-13
Resolution 2005-06-02
Accept proposal 1 but remove reference to WSDL binding; remove sentences pointed out in original issue. (reviewer present)
lc7 Typographic nits core - - closed
Description

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.
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc8 Rationalize URI vs. IRI core - - closed
Description

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" ...'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution
lc9 Reinforce absolute IRIs core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc10 EIIs have QNames? core - - closed
Description

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."
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc11 Ref param opacity core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc12 Ref param data encoding core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc13 Clearer wording for Section 2.1 core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc14 Clearer wording for Table 3-1 core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc15 Disallow multiple "reply" relationships core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
A reply message MUST contain a [relationship] property containing the predefined reply URI and the [message ID] property of the request message. A message MUST NOT contain more than one [relationship] containing the predefined reply URI.
lc16 Allow dispatch on more than [destination] and [action] core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
"The mandatory [destination] and [action] properties indicate the target processing location and the verb or intent of the message respectively, which can facilitate dispatch of incoming messages."
lc17 Anonymous not limited to replies core - - closed
Description

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, ... "
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution, with text: "To allow these anonymous endpoints to send and receive messages..."
lc18 [children] inconsistency core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc19 Clarify [destination] comparison core - - closed
Description

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".'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc20 Clarify Anonymous URI and for the case of HTTP responses core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Proposal 1 2005-06-24
Return to Sender
Proposal 2 2005-07-15
Return to Sender revised
Resolution 2005-07-18 accepted by originator

Core Table 2-1:

http://www.w3.org/@@@@/@@/addressing/anonymous

Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.

SOAP Binding:

When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.

(reviewer present)

lc21 Anonymous and [destination] over-constrained core - - closed
Description

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.
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc22 Header extensibility processing model core - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc23 RE: Rationalize URI vs. IRI soap - - closed
Description

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" ...'
> 
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc24 Typographical nits soap - - closed
Description

- 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"
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution.
lc25 Merge Core and SOAP Binding specs soap - - closed
Description

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.
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Close with no action.
lc26 Clarify which fault if SOAP Action and wsa:Action don't match soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Proposal 1 2005-04-29
Proposal in review + SOAP 1.1 support
Resolution 2005-05-02
Accept proposal 1 (original proposal + SOAP 1.1), removing "".
lc27 Clarify distinction between XML Infoset representation and SOAP headers soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution, replacing "XML Infoset" with "SOAP Header".
lc28 Mixed notation and indirect terminology for MAPs soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-05
Accept proposed solution, adding "Infoset" where appropriate.
lc29 wsa:isReferenceParameter inconsistent casing soap - - closed
Description

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.
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution
lc30 Formal definition of wsa:isReferenceParameter soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-05-03
Accept proposed solution, integrating into SOAP Binding (instead of Core).
lc31 wsa:IsReferenceParameter clashes soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-04-19
Accept proposed solution
lc32 Note effect of wsa:IsReferenceParameter on validation soap - - closed
Description

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].'
Origin
Jonathan Marsh (source)
Resolution 2005-05-09
Accept proposed solution.
lc33 Binding rules don't appear to allow optional headers soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-05-09
Accept proposed solution.
lc34 Duplicate headers at the ultimate receiver soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-05-16
A message MUST NOT contain more than one wsa:To, wsa:ReplyTo, wsa:FaultTo, wsa:Action, or wsa:MessageID header targeted at a recipient. A recipient MUST generate a wsa:InvalidAddressingHeader fault if such a message is received.
lc35 Clarify conformance requirements soap - - closed
Description

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".
Origin
Jonathan Marsh (source)
Resolution 2005-06-02
See lc6 resolution.
lc36 Clarify Invalid Message Addressing Property and Message Property Required Faults soap - - closed
Description

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]
------
Origin
Jonathan Marsh (source)
Resolution 2005-05-02
>Accept proposed solution.
lc37 More Security Considerations soap - - closed
Description

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.'
Origin
Jonathan Marsh (source)
Resolution 2005-06-02
Accept last two suggestions, add replies and remove "malformed." (reviewer present)
lc38 Feedback on xs:nonNegativeInteger soap - - closed
Description

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.
Origin
Jonathan Marsh (source)
Resolution 2005-05-16
use unsignedLong (reviewer on call).
lc39 Question regarding cardinality of [destination] core - - closed
Description
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
Origin
Rimas Rekasius (source)
Resolution 2005-05-16
Change mandatory to (1..1)
lc40 Example 3-1 core - - closed
Description

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/
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Closed with no action.
lc41 Table 3-1 core - - closed
Description

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

-- dims

-- 
Davanum Srinivas - http://webservices.apache.org/~dims/
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Closed with no action.
lc42 Order of items in section 3 and 3.1 core - - closed
Description

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/
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Accept proposed solution.
lc43 S11 in Table 1-1 core - - closed
Description

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/
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Accept proposed solution.
lc44 Section 4 core - - closed
Description

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/
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Accept proposed solution (change "and" to "or").
lc45 Bad URL's core - - closed
Description

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/
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Close with no action.
lc46 Section 3.2 core - - closed
Description

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/
Origin
Davanum Srinivas (source)
Resolution 2005-05-16
No change.
lc47 Bad URL's soap - - closed
Description

[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 '.'

Origin
Davanum Srinivas (source)
Resolution 2005-04-09
No action about periods; correct the WSDL URL.
lc48 typo in xsd schema - - closed
Description

InvalidMessageAddresssingProperty
should be
InvalidMessageAddressingProperty

thanks,
dims
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Accept proposed solution.
lc49 Section 5 soap - - closed
Description

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?

Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Accept proposed solution.
lc50 IRI for SOAP 1.2 Module and SOAP 1.1 Extension soap - - closed
Description

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

thanks,
dims

Origin
Davanum Srinivas (source)
Resolution 2005-05-16
No change; WG purposefully made it the same URI.
lc51 order of items in section 2.3 soap - - closed
Description

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

thanks,
dims
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
Accept proposed solution.
lc52 MessageId vs MessageID soap - - closed
Description

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

thanks,
dims
Origin
Davanum Srinivas (source)
Resolution 2005-05-09
End with ID.
lc53 introduction of MAP and MEP terms soap - - closed
Description

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
Origin
paul.downey@bt.com (source)
Resolution 2005-05-09
Expand all occurances of MAP and MEP.
lc54 why does this spec mandate a dispatching model? core - - closed
Description
    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
Origin
Tim Ewald (source)
Resolution 2005-04-19
use text: "The mandatory [destination] and [action] properties indicate the target processing location and the verb or intent of the message respectively, which can facilitate dispatch of incoming messages."
lc55 ReplyTo and security all - - closed
Description
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.
    
Origin
Tim Ewald (source)
Proposal 1 2005-07-15
Resolution 2005-07-18
Accept proposal one, keeping non-normative, and with amendment.
lc56 Binding fault [detail] in SOAP 1.1 envelope soap - - closed
Description
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
Origin
Arun Gupta (source)
Resolution 2005-06-15
Add a "wrapper wrapper."
lc57 Normative text for fault properties binding soap - - closed
Description
Fault properties binding to SOAP 1.1 and 1.2 envelope are shown via Example 5-1 and 5-2, but examples are non-normative. So there need to be a normative text around representation of this binding.
Origin
Arun Gupta (source)
Resolution 2005-05-16
Accept proposed solution.
lc58 Intermediary Processing soap - - closed
Description
Can we add a section to the SOAP binding document which discusses issues that will be faced by WS-A compliant intermediary. Intermediaries are allowed in SOAP and therefore the SOAP binding document might be the best place to discuss these issues.
Origin
Vikas Deolaliker (source)
Resolution 2005-06-02
Closed with no changes (reviewer present)
lc59 Missing xml namespace prefix declaration soap - - closed
Description
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" 
    
Origin
Steve Winkler (source)
Resolution 2005-04-09
Accept proposed solution.
lc60 entire route in ws-addressing all - - closed
Description
One of the features of the (hardly ever used) WS-Routing specs (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp) is to describe the entire message path in the soap header. Then you could just send the message to the first endpoint, and each endpoint would know where the message had passed through, and where the message is supposed to go. The WS-Routing spec mentions (at the top of the page) that it is superseded by WS-Addressing. If I understand correctly WS-Addressing does not allow to describe the full message path. I realize WS-Routing is not a W3C specification, but should this issue not be addressed by WS-Addressing, or has the working group decided to only specify the ultimate receiver? (If so, for what reasons)
Origin
Wannes Sels (source)
Resolution 2005-06-13
Out of scope.
lc61 Migration Contracts in Core core - - closed
Description
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.
Origin
Tom Rutt (source)
Resolution 2005-05-23
No change; this is already allowed in the current language (reviewer on teleconference).
lc62 Migration Contracts in SOAP binding soap - - closed
Description
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).?    
Origin
Tom Rutt (source)
Resolution 2005-06-02
Add to the conformance section: "Endpoints MAY accept and respond to messages which contain no WSA headers normally." (reviewer present)
lc63 Wording clarifications in Core Section 4 core - - closed
Description
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."
    
Origin
Jonathan Marsh (source)
Resolution 2005-05-09
Accept proposed solution.
lc64 ws-addressing LC review editorial comments all - - closed
Description
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
Origin
Jacek Kopecky (source)
Resolution 2005-05-09
Accept proposed solution.
lc65 use of IRIs in WS-Addressing all - - closed
Description

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/
Origin
Jacek Kopecky (source)
Resolution 2005-05-16
No change; point out other IRI/URI-related lc changes.
lc66 presentation of typing information in element descriptions all - - closed
Description

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/
Origin
Jacek Kopecky (source)
Resolution 2005-05-16
Accept proposed solution.
lc67 dereferencing namespace URI - but no link (editorial) all - - closed
Description

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/
Origin
Jacek Kopecky (source)
Resolution 2005-05-09
Accept proposed solution.
lc68 no mustUnderstand extensibility core - - closed
Description

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/
Origin
Jacek Kopecky (source)
Resolution 2005-06-27
Closed with no action; no new information.
lc69 mandatory ReplyTo, handling replies in WS-Addressing core - - closed
Description

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/
Origin
Jacek Kopecky (source)
Proposal 1 2005-06-27
noReply EPR
Proposal 2 2005-06-27
notValid EPR
Resolution 2005-07-11
Proposal 2, removing requirement to fault on 'notValid' message. Editors may change 'notValid'.
lc70 mandatory action core - - closed
Description

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
Origin
Jacek Kopecky (source)
Resolution 2005-06-12
Closed with no action; no new information.
lc71 mandatory fault reason soap - - closed
Description

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/
Origin
Jacek Kopecky (source)
Resolution 2005-06-01
Closed with no action.
Resolution 2005-06-20
Accept Jacek's proposal to make reason text a suggestion, rather than a normative requirement.
lc72 content of fault detail soap - - closed
Description

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/
Origin
Jacek Kopecky (source)
Proposal 1 2005-06-03
Resolution 2005-06-15
Adopt proposal 1.
lc73 nonNegativeInteger or duration for RetryAfter soap - - closed
Description

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/
Origin
Jacek Kopecky (source)
Resolution 2005-05-17
use xsd:unsignedLong, modify default text.
lc74 Another Security Consideration core - - closed
Description

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."
Origin
Jonathan Marsh (source)
Resolution 2005-05-16
Accepted as editorial input (reviewer on teleconference).
lc75 Uniqueness of [message id] core - - closed
Description
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.
Origin
David Hull (source)
Proposal 12005-06-20
The value of [message id] uniquely identifies the message. When present, it is the responsibility of the sender to insure that each message is uniquely identified. The behavior of a receiver when receiving a message that contains the same [message id] as a previously received message is undefined by this specification.
Resolution2005-06-20
Accept proposal 1. (reviewer on call)
lc76 Supported faults soap - - closed
Description
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.
Origin
David Hull (source)
Proposal 1 2005-06-03
Proposal 2 2005-06-20
Proposal 3 2005-07-15
Resolution 2005-07-19
         Common Detail constructs for all subcodes:
         <wsa:ProblemHeader>xs:any</wsa:ProblemHeader>
         <wsa:ProblemHeaderQName>xs:QName</wsa:ProblemHeaderQName>
         <wsa:ProblemIRI>xs:any</wsa:ProblemIRI>
         
         New Subcodes:
         Of wsa:InvalidAddressingHeader:
         - wsa:InvalidAddress
         - wsa:InvalidEPR
         - wsa:InvalidCardinality  
         - wsa:MissingAddressInEPR
         - wsa:DuplicateMessageID
         - wsa:ActionMismatch
         
         Detail for ActionMismatch:
         <wsa:ProblemAction>
            <wsa:Action>anyURI</wsa:Action>
            <wsa:SoapAction>anyURI</wsa:SoapAction>
         </wsa:ProblemAction>
         
         * Add ednote that fault details/subcodes may change, 
         be added to based on implementation experience and/or feedback.
         
         e.g.,
         <subcode>wsa:InvalidCardinality</subcode>
         <detail>
            <wsa:ProblemHeaderQName>wsa:Action</wsa:ProblemHeaderQName>
         </detail>
         

(reviewer present)

lc77 MAPs in EPR reference params soap - - closed
Description

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).
Origin
David Hull (source)
Proposal 1 2005-05-23
Resolution 2005-06-02
Accept proposal 1 (reviewer present).
lc78 Multiple reply relationships core - - closed
Description
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.
Origin
David Hull (source)
Resolution 2005-06-02
Make editorial changes to section 3.3 wording concerning population of a reply message's message addressing properties to make sure it is clear that it is a new set of properties. (reviewer present)
lc79 Rewriting by intermediaries core - - closed
Description
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.
Origin
David Hull (source)
Resolution 2005-06-02
Make editorial changes to clarify; "gathered by" to "targetted to", restrict header change prohibition to when relaying. (reviewer present)
lc80 Definitions of MAPs in core section 3 should have their own subsection core - - closed
Description

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.
Origin
David Hull (source)
Resolution 2005-05-16
Accepted as editorial input (reviewer on teleconference).
lc81 Use of mustUnderstand=1 in example core - - closed
Description

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.
Origin
David Hull (source)
Resolution 2005-05-16
Accepted as editorial input (reviewer on teleconference).
lc82 "... the processor MUST fault" in section 3.2 is vacuous. core - - closed
Description

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.
Origin
David Hull (source)
Resolution 2005-06-02
Closed with no action as a result of lc84 resolution. (reviewer present)
lc83 When is a fault/reply expected? core - - closed
Description

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.
Origin
David Hull (source)
Resolution 2005-06-03
Closed with no action (reviewer present)
lc84 Message compliance core - - closed
Description
 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.
Origin
David Hull (source)
Resolution 2005-06-02
New text for 3.1 and 3.3. (Reviewer on call)
lc85 Processors unconstrained in the face of non-compliant messages. core - - closed
Description

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."
Origin
David Hull (source)
Resolution 2005-06-02
Closed with no action (reviewer present)
lc86 [message id] should be optional core - - closed
Description
  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.
Origin
David Hull (source)
Resolution 2005-06-03
Closed with no action (reviewer present)
lc87 Security model is insufficient all - - closed
Description

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.
Origin
Marc Hadley (source)
Proposal 1 2005-06-20
Proposal 2 2005-07-15
Resolution2005-07-18
Accept proposal two, keeping non-normative, and with amendment. (reviewer present)
lc88 Uniqueness of [message id] core - - closed
Description
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:hugo@w3.org - http://www.w3.org/People/Hugo/

Origin
Hugo Haas (source)
Proposal 12005-06-20
The value of [message id] uniquely identifies the message. When present, it is the responsibility of the sender to insure that each message is uniquely identified. The behavior of a receiver when receiving a message that contains the same [message id] as a previously received message is undefined by this specification.
Resolution2005-06-20
Accept proposal 1. (reviewer on call)
lc89 Comments on WS-A Core core - - closed
Description

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 
Origin
Nilo Mitra (source)
Resolution 2005-06-02
Accept 1-5 as editorial, no action on 6 or 7 (reviewer present)
lc90 Security implications of [message id] in re-transmissions core - - closed
Description
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.
Origin
David Hull (source)
Resolution2005-06-27
Prepend "In this case," to the beginning of the second sentence in the existing text. (reviewer on call)
lc91 Comments on WS-A SOAP Binding soap - - closed
Description

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 
Origin
Nilo Mitra (source)
Resolution 2005-06-03
Accept 1,2,5 as editorial; change "are" to "MUST be" for 3; "replay" to "relay" for 4. (reviewer present)
lc92 Editorial nit core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accept proposed solution (reviewer on teleconference).
lc93 Editorial nit regd Example 1-1 in Core core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accept proposed solution (reviewer on teleconference).
lc94 section 1.1 editorial nit core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accept proposed solution (reviewer on teleconference).
lc95 section 1.2 (references) core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accept proposed solution (reviewer on teleconference).
lc96 requirement of XML 1.0 core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
No change; comment no longer relevant (reviewer on teleconference).
lc97 inconsistent use of 'Endpoint Reference' (ed nit) core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accepted as editorial input (reviewer on teleconference).
lc98 Notational conventions not explained core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accepted as editorial input (reviewer on teleconference). Ed action pending resolution of lc106
lc99 section 2.1 -- what does 'each of the EPRs' refer to core - - duplicate
Description

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

"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."

What does 'each of the EPRs' refer to?

I would like to suggest that the sentence be changed to:

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

-Anish
--

[1] http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Duplicate of lc13. (reviewer on teleconference).
lc100 section 2.1 -- unclear wording regarding conflicts between metadata core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-05-16
Accepted as editorial input (reviewer on teleconference).
lc101 How does one extend the abstract properties of an endpoint reference core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Proposal 1 2005-07-13
Resolution2005-07-19

Section 2.1, first sentence - replace with:

An endpoint reference is a collection of abstract properties. This specification defines a core set of properties, but it is also possible for other specifications to extend these and/or add other properties. The semantics and XML Infoset representation (see next section) for any such extension properties will be described in their defining specifications.

Before example, add:

NOTE: Specifications which describe extension elements or attributes used to augment the above model will explain any effects those extensions may have on the abstract properties. They may affect either the core properties or extension properties as defined in section 2.1.

Section 3.2 example:

add cardinality to pseudo-schema

In Notational Conventions:

[Clarify that extensibility is omitted in pseudo-schema]

(reviewer present)

lc102 immutability of MAPs core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Resolution 2005-06-03
remove first paragraph of Section 3.2 in the core. (reviewer present)
lc103 what is a 'request' and what is a 'reply'? core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Proposal 1 2005-06-02
Resolution 2005-06-27
Closed with no action. (reviewer on call)
lc104 XML infoset representation of EPR > Information model core - - closed
Description

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/
Origin
Anish Karmarkar (source)
Proposal 1 2005-07-06
Remove abstract model.
Resolution2005-07-19

Section 2.1, first sentence - replace with:

An endpoint reference is a collection of abstract properties. This specification defines a core set of properties, but it is also possible for other specifications to extend these and/or add other properties. The semantics and XML Infoset representation (see next section) for any such extension properties will be described in their defining specifications.

Before example, add:

NOTE: Specifications which describe extension elements or attributes used to augment the above model will explain any effects those extensions may have on the abstract properties. They may affect either the core properties or extension properties as defined in section 2.1.

Section 3.2 example:

add cardinality to pseudo-schema

In Notational Conventions:

[Clarify that extensibility is omitted in pseudo-schema]

(reviewer present)

lc105 IRI escaping when constructing a reply soap - - closed
Description

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.
Origin
Jonathan Marsh (source)
Resolution 2005-05-23
Accept proposed solution (reviewer on teleconference).
lc106 Editorial Comment core - - closed
Description
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/
Origin
Yalcinalp, Umit (source)
Resolution 2005-06-13
Use WSDL 2.0 pseudo-schema.
lc107 WS Description WG comments on WS-A core - - closed
Description

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
Origin
Jonathan Marsh (source)
Proposal 1 2005-06-02
Request/Response -> Message/Reply
Resolution 2005-06-27
Accept proposal 1, with qualification about the scope of "reply." (reviewer on call)
lc108 Comment from WSDL group on ReplyTo core - - closed
Description
         
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)
Origin
Glen Daniels (source)
Resolution 2005-07-11
See lc69. Reviewer on teleconference.
lc109 Should [fault endpoint] be required for robust in-only message? wdsl - - closed
Description
Given that [message id] is mandatory in Table 5-5 "Message addressing properties for in message.", should [fault endpoint] also be required?
Origin
Marc Hadley
Resolution accepted by originator
At least one of reply endpoint or fault endpoint properties should appear in table 5.5, with some indication of the co-constraints in the core spec
lc110 Should [fault endpoint] be prohibited in Robust in-only fault messages? wsdl - - closed
Description
Should [fault endpoint] be prohibited in Table 5-6 "Message addressing properties for fault message"? This would prevent getting a fault in response to a fault.
Origin
Marc Hadley
Resolution 2006-03-03 accepted by originator
Close with no action
lc111 Section 3.1.1 clarity wsdl - editorial - closed
Description
      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
Origin
Hugo Haas and Arthur Ryman
Resolution 2006-03-03 accepted by originator
Proposal above was accepted
lc112 Three states in two wsdl - - closed
Description
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.

Origin
Hugo Haas and Arthur Ryman
Resolution 2006-03-03
Pending Hugo's AI for some text
Resolution 2006-03-27 accepted by originator
WG accepted Hugo's addition to editor's draft
lc113 Section 3.3 clarity wsdl - - closed
Description
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.
            
Origin
Hugo Haas and Arthur Ryman
Proposal 1
In WSDL 2.0, a SOAP Module component may be used to declare the
         use of the WS-Addressing 1.0 Module for the SOAP binding. The
         meaning of the use of such a SOAP Module component is semantically
         equivalent to the {addressing required} property defined in
         section 3.1.1. Note that this module is only meaningful when used
         on WSDL components where the {addressing required} property is
         allowed, i.e. as a member of the {soap modules} property of a
         Binding component.
Resolution 2006-03-03 accepted by originator
Closed by accepting Hugo's proposal
lc114 Typos in section 2.1 wsdl - editorial - closed
Description
Typos in section 2.1:
            - "by by" -> "by"
            - "http://example.com/www.fabrikam/acct" -> "http://example.com/fabrikam/acct"
         
Origin
Hugo Haas and Arthur Ryman
Resolution 2006-03-03 accepted by originator
Typos corrected
lc115 Example 4-1 is wrong wsdl - editorial - closed
Description
The XML example 4-1 is wrong since it uses <definition> as the root element. It should use <description>.
Origin
Hugo Haas and Arthur Ryman
Resolution 2006-03-03 accepted by originator
Closed by accepting proposal
lc116 use of wsa:ReferenceParameters wsdl - - closed
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?

Origin
Hugo Haas and Arthur Ryman
Resolution 2006-03-03 accepted by originator
Add a {reference parameters} property to the WSDL 2.0 component model, with the same type as the [reference parameters] property in Core 2.1
lc117 Why are the WS-Addressing WSDL binding elements capitalized? wsdl - editorial - closed
Description
            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>
         
Origin
Craig Salter (source)
Resolution 2006-03-13
Close with no action

Response to reviewer

lc118 typo in example 4-8 wsdl - editorial - closed
Description
         example reads
            fault action = http://example.com/stockquote/StockQuotePortType/GetLastTradePriceFault/Error
         example should read
            fault action = http://example.com/stockquote/StockQuotePortType/GetLastTradePrice/Fault/Error
         
Origin
Stefan Illner (source)
Resolution 2006-03-20 accepted by originator
proposal accepted

Response to Reviewer

lc119 WSDL binding editorial comments wsdl - editorial - closed
Description
         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.         
      
Origin
David Hull (source)
Resolution2006-03-20 accepted by originator

Reviewer present at meeting

lc120 David Illsley's Editorial issues Vol 1 wsdl - editorial - closed
Description
            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
            
         
Origin
David Illsley (source)
Resolution2006-03-27 accepted by originator
Accepted as proposed except that in Example 4.1 the title shall use wsa:Action
lc121 Katy's editorial issues vol 1 wsdl - editorial - closed
Description
            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       
         
Origin
Katy Warr (source)
Resolution2006-03-27 accepted by originator
lc122 Cardinality for InterfaceName wsdl - - closed
Description
            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?
         
Origin
Katy Warr (source)
Resolution2006-03-27 accepted by originator
Limit cardinality of InterfaceName, ServiceName, and EndpointName to 1 in Section 2.1 and 2.2
lc123 Example Improvement suggestion wsdl - editorial - closed
Description
Suggest that all examples use samples from the WSDL primer
Origin
David Hull (source)
Proposal 1 2006-03-28
Use examples from the WSDL primer
Resolution 2006-04-03 accepted by originator
Accepted as proposed
lc124 Conformance section wsdl - editorial - closed
Description
            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
                        
Origin
Karl Dubost (source)
Owner
Jonathan Marsh
Proposal 1 2006-04-10
            Add a new section:
            
            
            6 Conformance
            
            
            An endpoint reference whose wsa:Metadata element has among its children
            the elements defined in [2.1 Referencing WSDL Metadata from an EPR]
            conforms to this specification if it obeys the structural constraints
            defined in that section.
            
            A WSDL description conforms to this specification when it incorporates
            directly or indirectly one or more of the [3.1 wsaw:UsingAddressing
            Extension Element] or the [3.3 WSDL SOAP Module] markers, and obeys the
            structural constraints defined in section [3 Indicating the use of
            Addressing] appropriate to that marker, and those defined in section
            [4.2 Action].
            
            An endpoint conforms to this specification if it has a conformant WSDL
            description associated with it, and receives and emits messages in
            accordance with the constraints defined in sections [4 Specifying
            Message Addressing Properties in WSDL] and [5 WS-Addressing and WSDL
            Message Exchange Patterns].
            
         
Resolution 2006-04-24 accepted by originator
Proposal 1 is accepted

Response to Reviewer

lc125 Define the class of products of your specification wsdl - editorial - closed
Description
         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.
         ]]]
         
Origin
Karl Dubost (source)
Owner
Robert Freund
Proposal 1 2006-04-09
            Add to the Abstract after the last text therein:
            
            The classes of products for which this specification is designed to be
            relevant include WSDL and WS-Addressing EPR consumers.
            
Resolution 2006-04-10 accepted by originator

Email to the originator

Accepted proposed text above

lc126 WS-Addressing typo 3.1 Using wsdl - editorial - closed
Description
         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
         
Origin
Karl Dubost (source)
Resolution 2006-04-03

Email to the originator

There is no typo, editors to see if use of the <el> tag might be useful to clarify

lc127 Application choice of synchronicity wsdl - - closed
Description

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

Origin
Todd Wolff (source)
Owner
Jonathan Marsh
Resolution 2006-04-10 accepted by originator
Close with no action

Response to Reviewer

lc129 Changes to wsaw:Anonymous wsdl - design - closed
Description
            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.
         
Origin
Jonathan Marsh (source)
Owner
Francisco Curbera
Proposal 1 2006-04-06

We therefore propose that wsaw:Anonymous be removed from this spec and features to constrain anonymous or hint at programming models be deferred to future specs.

Proposal 2 2006-04-06

Failing that, we ask that "unspecified" be added as a value for wsaw:Anonymous, and that this value be treated as the default when no wsaw:Anonymous element appears. The addition of an "unspecified" value enables the wsaw:UsingAddressing extension/assertion to act dually as a primitive and composite assertion, and compose with other mechanisms of indicating the handling of asynchronous messages as they are developed.

Proposal 3 2006-04-10

Remove the default. Lack of wsaw:Anonymous means there are no claims about Anonymous support.

Proposal 4 2006-04-16
            This is my take on expanding "option 4" in Jonathan's mail [1] ("Remove the
            default. Lack of wsaw:Anonymous means there are no claims about Anonymous
            support."). I am not proposing here the changes necessary to fully
            incorporate a resolution of the issue, only proposing a clarification of
            the assumptions clients would be able to make when no wsaw:Anonymous
            element is present.
            
            "A WSDL or policy based service description that includes the
            wsaw:UsingAddressing but no a wsaw:Anonymous marker makes no assertion
            regarding a requirement or a constraint in the use of the anonymous URI in
            EPRs contained in messages sent to the endpoint. In this cases, endpoint
            service descriptions SHOULD use additional metadata, such as WSDL bindings
            or additional policy assertions, to indicate any requirements or
            restrictions on the use of the anonymous URI by clients. However, in the
            absence of additional metadata, clients of the endpoint MAY assume that the
            service endpoint follows the behavior indicated by the 'optional' value of
            the wsaw:Anonymous marker. An endpoint MAY send a fault back to the client
            if a message received uses the anonymous URI in a way that is unsupported
            by the endpoint." 
            [1].
            http://lists.w3.org/Archives/Public/public-ws-addressing/2006Apr/0019.html
                        
Resolution 2006-04-24 accepted by originator
         A WSDL or policy based service description that includes the
         wsaw:UsingAddressing but no a wsaw:Anonymous marker makes no assertion
         regarding a requirement or a constraint in the use of the anonymous URI in
         EPRs contained in messages sent to the endpoint. In this cases, endpoint
         service descriptions have to rely on additional metadata,
         such as WSDL bindings or additional policy assertions, to indicate any requirements or
         restrictions on the use of the anonymous URI by clients. However, in the
         absence of additional metadata, clients of the endpoint MAY assume that the
         service endpoint follows the behavior indicated by the 'optional' value of
         the wsaw:Anonymous marker. An endpoint SHOULD send a
         wsa:OnlyAnonymousAddressSupported or a wsa:OnlyNonAnonymousAddressSupported
         fault back to the client if a message received includes a response epr
         with an [address] that is unsupported by the endpoint.
         
         
         In addition, remove the default. Lack of wsaw:Anonymous means there are no claims about Anonymous
lc130 Clarify section 4.1: Destination wsdl - - closed
Description
            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.   
         
Origin
Jonathan Marsh (source)
Proposal 1 2006-04-06
Perhaps this could be reworded to remove the MUST, for example "the value of [destination] ... typically matches the value of the {address} property."
Resolution 2006-04-10 accepted by originator
Proposal 1 accepted

MUST in conjunction with "additional runtime information" in section 4.1

lc131 UsingAddressing and soap:mustUnderstand wsdl - - closed
Description
            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.
            
         
Origin
Jonathan Marsh (source)
Resolution 2006-04-24 accepted by originator
Delete column 3 of table 3-1 and collapse the first two rows as they are now redundent
lc132 Reference Parameters vs. complete EPRs wsdl - - closed
Description
            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/>
                        
Origin
Jonathan Marsh (source)
Proposal 1 2006-04-11
            We request that section 4.3 specify that a whole EPR can be
            embedded in an endpoint/port.  If both an EPR and one of the *:address
            mechanisms are present, the address values MUST match.
         
Proposal 2 2006-04-17
            Here is a concrete proposal to resolve issue lc132.  This text would
            replace sections 4.1 and 4.3, add a new subsection and perhaps renumber
            the existing subsections in section 4.
            
            
            4.1 Destination
            
            
            The value of the [destination] message addressing property for a message
            sent to an endpoint typically matches the value of the {address}
            property of the endpoint component (WSDL 2.0) or the address value (if
            any) provided by the relevant port extension (WSDL 1.1). For a SOAP 1.1
            port described using WSDL 1.1, the value is provided by the location
            attribute of the soap11:address extension element.  For an endpoint or
            port extended as described in [4.x Extending WSDL Endpoints with an
            EPR], the value is provided by the wsa:To element.
            
            Additional runtime information could override the value of the
            [destination] message addressing property for messages sent to an
            endpoint, e.g. a runtime exchange might result in a redirection to a
            different EPR. Note that WS-Addressing does not define any normative
            mechanism for such redirection.
            
            
            
            
            4.3 Reference Parameters
            
            
            When a wsa:EndpointReference element is present in a wsdl20:endpoint or
            a wsdl11:port element, the value of the [reference parameters] message
            addressing property for a message sent to an endpoint MUST include the
            contents of the wsa:ReferenceParameters element, if one exists within
            that EPR.
            
            
            
            
            4.x Extending WSDL Endpoints with an EPR
            
            
            The wsa:EndpointReference element (see Web Services Addressing 1.0 -
            Core[WS-Addressing-Core
            <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#WSADDR-CORE#WSADDR-CORE> ])
               MAY be used as an extension child element of the wsdl20:endpoint or
               wsdl11:port elements. When present, the value of the [destination]
               message addressing property of the EPR MUST have the same value as the
               {address} property, if any, of the endpoint component.  For WSDL 1.1 the
               [destination] message addressing property MUST have the same value as
               the address supplied by the binding extension.  For example, in a SOAP
               1.1 port described using WSDL 1.1, the location attribute of the
               soap11:address element must have the same value as the wsa:Address
               element.
               
               
               
               
               4.x.1 WSDL 2.0 Component Model Changes
               
               
               Use of WS-Addressing adds the following OPTIONAL properties to the WSDL
               2.0 component model:
               
               A property of the Endpoint component, named {endpoint reference}. This
               property is of type wsa:EndpointReference, with a cardinality of 1. The
               property has the value of the wsa:EndpointReference element used as a
               child of wsdl20:endpoint, if any.  If no such extension exists, this
               property is absent.
               
               
               
               Although there are other ways to do it, I would probably reorganize and
               renumber Section 4 as follows:
               
               
               
               4. Specifying Message Addressing Properties in WSDL
               <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#mapvaluesinwsdl#mapvaluesinwsdl> 
               4.1 Extending WSDL Endpoints with an EPR
               
               4.2 Destination
               <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#destinwsdl#destinwsdl> 
                  4.3 Reference Parameters
                  <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#refpinwsdl#refpinwsdl> 
                  
                  4.4 Action
                  <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#actioninwsdl#actioninwsdl> 
                     
         
Resolution 2006-04-24 accepted by originator
         Proposal 1 above accepted as amended by the text below replacing paragraph 4.x in that proposal:
         
         A wsdl20:endpoint or wsdl11:port element MAY be extended using a  
         child wsa:EndpointReference element. When extended this way, the  
         [address] property of the child EPR must match the {address} property  
         of the endpoint component (WSDL 2.0) or the address value provided by  
         the relevant port extension (WSDL 1.1). For example, in a SOAP 1.1  
         port described using WSDL 1.1, the location attribute of the  
         soap11:address element must have the same value as the wsa:Address  
         element.
lc133 WS-Policy's review of Metadata LC1 meta - design - closed
Description
Metadata Document does not use WS-Policy Correctly see long message for details
Origin
WS-Policy WG (source)
Proposal 1 2007-02-26

Proposal A

Change nested policy assertions to be requirements, but
         keep definition of non-anonymous to be “not wsa:anonymous URI”.
         
         In 3.1.2 Change:
         The appearance of this element within a policy alternative indicates
         that the endpoint expresses explicit support for request messages with
         response endpoint EPRs that contain the anonymous URI
         ("http://www.w3.org/2005/08/addressing/anonymous") as the value of
         [address]. In other words, the endpoint guarantees support for
         anonymous responses.
         
         The absence of the wsam:AnonymousResponses policy assertion within a
         policy alternative does not indicate that the endpoint will not accept
         request messages with response endpoint EPRs that contain the anonymous
         URI as an address; it simply indicates the lack of any affirmation of
         support for anonymous URIs.
         
         To:
         The appearance of this element within a policy alternative indicates
         that the subject requires request messages that require responses to
         include response endpoint EPRs that contain the anonymous URI
         ("http://www.w3.org/2005/08/addressing/anonymous") as the value of
         [address]. In other words, the subject requires response instances to
         be sent as anonymous responses.
         
         The absence of the wsam:AnonymousResponses policy assertion within a
         policy alternative indicates that the subject prohibits response
         message instances using the anonymous URI as an address.
         
         In 3.1.3 change:
         
         The appearance of this element within a policy alternative indicates
         that the endpoint expresses explicit support for request messages with
         response endpoint EPRs that contain something other than the anonymous
         URI as the value of [address]. In other words, the endpoint guarantees
         support for non-anonymous responses. This assertion is deliberately
         vague; its presence indicates that some non-anonymous addresses will be
         accepted but doesn't constrain what such an address might look like. A
         receiver can still reject a request that contains an address that it
         doesn't understand or that requires a binding it doesn't support.
         
         As with the other assertions, the absence of the
         wsam:NonAnonymousResponses policy assertion within a policy alternative
         does not indicate that the endpoint will not accept request messages
         with response endpoint EPRs that contain something other than the
         anonymous URI address; it simply indicates the lack of any affirmation
         of support for them.
         
         
         To:
         The appearance of this element within a policy alternative indicates
         that the subject requires any request message that has responses to
         include response endpoint EPRs that contain something other than the
         anonymous URI as the value of [address]. In other words, the endpoint
         requires that any response instances use non-anonymous address URIs.
         This assertion is deliberately vague; its presence indicates that some
         non-anonymous addresses are required for instances of response
         messages, but doesn't constrain what such an address might look like. A
         receiver can still reject a request that contains an address that it
         doesn't understand or that requires a binding it doesn't support.
         
         The absence of the wsam:NonAnonymousResponses policy assertion within a
         policy alternative indicates that the subject prohibits response
         message instances using endpoint EPRs that contain something other
         than the anonymous URI address.
Proposal 2 2007-02-26

Proposal B

            In addition to the changes in proposal A
            
            In 3.1.3 Change
            The appearance of this element within a policy alternative indicates
            that the subject requires any request message that has responses to
            include response endpoint EPRs that contain something other than the
            anonymous URI as the value of [address]. In other words, the endpoint
            requires that any response instances use non-anonymous address URIs.
            This assertion is deliberately vague; its presence indicates that some
            non-anonymous addresses are required for instances of response
            messages, but doesn't constrain what such an address might look like. A
            receiver can still reject a request that contains an address that it
            doesn't understand or that requires a binding it doesn't support.
            
            The absence of the wsam:NonAnonymousResponses policy assertion within a
            policy alternative indicates that the subject prohibits response
            message instances using endpoint EPRs that contain something other
            than the anonymous URI address.
            
            To:
            The appearance of this element within a policy alternative indicates
            that the subject requires any request message that has responses to
            include response endpoint EPRs that contain a connectable URI as the
            value of [address]. This assertion is deliberately vague; its presence
            indicates that some connectable addresses are required for instances of
            response messages, but doesn't constrain what such an address might
            look like. A receiver can still reject a request that contains an
            address that it doesn't understand or that requires a binding it
            doesn't support.
            
            The absence of the wsam:NonAnonymousResponses policy assertion within a
            policy alternative indicates that the subject prohibits response
            message instances using endpoint EPRs that contain a connectable URI
            address.
         
Proposal 3 2007-03-02
Proposal C
Proposal 4 2007-03-02
Proposal D
Proposal 5 2007-03-06
Proposal E
Proposal 6 2007-03-15
Proposal F
Proposal 7 2007-03-19
Proposal G
Resolution 2007-04-02 accepted by originator
Proposal G accepted with the following modifications:
            
            3.1.1 sentence 3 is convoluted:
            
            Change:
            “
            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.
            “
            
            To (reads better and is more direct in its statement)
            “
            The wsam:Addressing assertion indicates that there are no restrictions 
            on the use of
            WS-Addressing, unless otherwise qualified by assertions in its nested 
            policy expression.
            “
            
            
            Examples in section 3.1.6:
            
            The examples are not realistic. The examples for proposal F are more 
            representative
            of actual support requirements a Client might be looking for.
            
            It is better to for proposal G to recast the same examples from the 
            proposal F .
            
            Change:
            “
            Consider the following example, where we have a client who does not care 
            whether the
            endpoint explicitly requires anonymous responses, and a WSDL which states
            that the endpoint does explicitly require anonymous responses.
            Example 3-7. Client looking for an endpoint which supports Addressing, 
            WSDL states
            explicit requirement for anonymous responses
            <wsp:Policy>
               <wsam:Addressing>
                  <wsp:Policy/>
               </wsam:Addressing>
            </wsp:Policy>
            The client's policy (above) states the requirement for Addressing, but 
            no requirement for
            explicit support of responses.
            <wsp:Policy>
               <wsam:Addressing>
                  <wsp:Policy>
                     <wsam:AnonymousResponses/>
                  </wsp:Policy>
               </wsam:Addressing>
            </wsp:Policy>
            The policy attached to the endpoint in the WSDL (above) requires explicit
            support for anonymous responses. The intersection of this policy with 
            the client's policy
            will be empty, so the client will miss a compatible endpoint.
            <wsp:Policy>
               <wsam:Addressing>
                  <wsp:Policy>
                     <wsam:AnonymousResponses wsp:Optional="true"/>
                  </wsp:Policy>
               </wsam:Addressing>
            </wsp:Policy>
            This is what the client's policy could be; by stating that the
            wsam:AnonymousResponses assertion is optional, there will be a non-empty
            intersection with endpoint policies that do and do not contain this 
            assertion.
            
            strict intersection. The strict intersection of this policy with the 
            client's policy will still be
            empty. The lax intersection, on the other hand, will not be empty, so 
            the client will find a
            compatible endpoint.
            These two
            This example shows the use of wsp:Optional, and how
            it can be used to produce non-empty intersections between client and 
            endpoint
            policies. For more detailed descriptions of the use of wsp:Optional, 
            wsp:Ignorable, and
            strict and lax intersection, please refer to the WS-Policy Primer [WS 
            Policy 1.5 - Primer].
            “
            
            To:
            “
            Example 3-7. Client looking for an endpoint which supports Addressing, 
            and which supports anonymous responses
            <wsp:Policy>
               <wsp:ExactlyOne>
                  <wsp:All>
                     <wsam:Addressing>
                        <wsp:Policy>
                           <wsp:ExactlyOne>
                              <wsp:All>
                                 <AnonymousResponses Optional=”true”/>
                                    </wsp:All>
                           </wsp:ExactlyOne>
                        </wsp:Policy>
                     </wsam:Addressing>
                  </wsp:All>
               </wsp:ExactlyOne>
            </wsp:Policy>
            
            Example 3-8. Client looking for an endpoint which supports Addressing, 
            and does not require support for responses (will intersect with anything)
            <wsp:Policy>
               <wsp:ExactlyOne>
                  <wsp:All>
                     <wsam:Addressing> <-- supports all response types -->
                        <wsp:Policy>
                        </wsp:Policy>
                     </wsam:Addressing>
                  </wsp:All>
                  <wsp:All>
                     <wsam:Addressing> <-- requires Anonymous responses -->
                        <wsp:Policy>
                           <wsp:ExactlyOne>
                              <wsp:All>
                                 <AnonymousResponses />
                              </wsp:All>
                           </wsp:ExactlyOne>
                        </wsp:Policy>
                     </wsam:Addressing>
                  </wsp:All>
                  <wsp:All>
                     <wsam:Addressing> <- requires nonAnonymous responses -->
                        <wsp:Policy>
                           <wsp:ExactlyOne>
                              <wsp:All>
                                 <NonAnonymousResponses />
                              </wsp:All>
                           </wsp:ExactlyOne>
                        </wsp:Policy>
                     </wsam:Addressing>
                  </wsp:All>
               </wsp:ExactlyOne>
            </wsp:Policy>
            
            For more detailed descriptions of the use of wsp:Optional, 
            wsp:Ignorable, and
            strict and lax intersection, please refer to the WS-Policy Primer [WS 
            Policy 1.5 - Primer].
            “
         
lc134 Policy Attachment to wsdl:portType or wsdl20:interface meta - design - closed
Description
            "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.
            
         
Origin
Anish Karmarkar (source)
Resolution 2007-04-23 accepted by originator
Add to Section 3 the language %quot; This assertion implies support for ws-addr core and soap binding.%quot;
lc135 Clarify text that the addressing assertion alone does not indicate restriction meta - editorial - closed
Description
            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."
            
         
Origin
Anish Karmarkar (source)
Resolution 2007-04-23 accepted by originator
Close with no action
lc136 Non-anon extensibility and policy intersection meta - design - closed
Description
         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".
         
      
Origin
(source)
Resolution 2007-05-14 accepted by originator
Closed with no action
lc137 Need for new Rec or TR on attaching policy to EPR meta - design - closed
Description
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.
Origin
(source)
Resolution2007-07-02 accepted by originator
Close with no action
lc138 Need new namespace for second last call meta - design - closed
Description
Need new namespace for second last call
Origin
Ram Jeyaraman (source)
Resolution 2007-05-14 accepted by originator
New namespace will be assigned at publication of next last call
lc139 Provide explanation of namespace stability in namespace document meta - design - closed
Description
Provide explanation of namespace stability in namespace document
Origin
(source)
Resolution 2007-05-14 accepted by originator

URI will not change as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a LC, CR or PR draft, results in non-backwardly compatible changes from a previously published LC, CR or PR draft of the specification, the namespace URI will be changed accordingly.

lc140 Update WS-Policy 1.5 namespace reference in WS-Addressing metadata schema meta - design - closed
Description
Update WS-Policy 1.5 namespace reference in WS-Addressing metadata schema
Origin
Ram Jeyaraman (source)
Resolution 2007-05-14 accepted by originator
Accepted as proposed
lc141 Action Property meta - design - closed
Description
            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.
         
Origin
Cindy McNally (source)
Proposal 1 2007-06-18
            1.Move the wsam:Action attribute from the interface fault element to the WSDL 2.0 interface operation infault/outfault element. 
            2.Change the default WSDL 2.0 action pattern for faults to: [tns] [delimiter] [interface name] [delimiter] [operation name] [delimiter] [direction] [delimiter] [fault name]
Resolution 2007-06-04 not accepted by originator
Close with no action
Resolution2007-06-18
Re-opened due to reviewer's objection
Resolution 2007-06-18 accepted by originator
Accepted as proposed by reviewer
lc142 WSP namespace - interoperability and forward compatibility meta - design - closed
Description
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.
Origin
Katy Warr (source)
Resolution 2007-06-04 accepted by originator
lc143 Editorial comment on 3.1.1 meta - editorial - closed
Description
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]).
Origin
Monica Martin (source)
Proposal 12007-06-18
In order to indicate that the subject supports WS-Addressing but does not require its use, an additiona policy alternative should be provided which does not contain this policy assertion. To indicate that the subject supports WS-Addressing but does not require its use, the compact authoring style for an optional policy assertion provided by WS-Policy v1.5 [link], may be used. The wsp:Optional attribute, as a syntactic short, can be used with the |wsam:Addres
Resolution2007-06-18 accepted by originator
proposal 1 above accepted
lc144 Editorial comment to 4.4.4 meta - editorial - closed
Description
complete description in 4.4.4 to be equivalent to that in 4.4.2
Resolution2007-06-18 accepted by originator
Accepted as proposed