Web Services Addressing Working Issues List

$Date: 2006/01/26 23:49:36 $

$Revision: 1.33 $

Statistics

core soap wsdl test schema all total
unassigned 0 0 0 0 0 0 0
active 0 0 0 0 0 0 0
postponed 0 0 0 0 0 0 0
closed 24 7 18 0 1 6 56
dropped 10 2 1 1 0 0 14
total 34 9 19 1 1 6 70

Open Issues Summary

id owner title target type

Closed Issues Summary

id owner title target type
i001 David Orchard EPRs as Identifiers core design
i002 Mark Nottingham WS-Policy dependence core design
i003 Martin Gudgin WSDL MEPs wsdl design
i004 Martin Gudgin Security Model core design
i005 SOAP and WSDL references core design
i006 Marc Hadley Message Property Optionality soap design
i007 Marc Hadley Processing model of headers soap design
i008 Glen Daniels RefProps/RefParams as individual SOAP headers soap design
i009 Paul Downey Cardinality of properties and their values core design
i010 Anish Karmarkar EPR Robustness core design
i011 Harris Reynolds EPRs in To core design
i012 Robert Freund EPR Life Cycle core design
i013 Anish Karmarkar Serialising metadata into messages soap design
i014 Hugo Haas Metadata Update/Reconciliation core design
i015 Marc Hadley Redirection core design
i016 Glen Daniels Distinguishing RefProperty headers soap design
i017 Anish Karmarkar Purpose of the Action property core design
i018 Glen Daniels Protocol-specific markup in ReferencePs core design
i019 Hugo Haas WSDL Version Neutrality core design
i020 Anish Karmarkar Addressing and WSDL core design
i021 Hugo Haas WSDL Extension for Addressing wsdl design
i022 Greg Truty Relationship to the SOAP binding framework soap design
i023 Rebecca Bergersen Required properties in EPRs core design
i024 Rebecca Bergersen Self-Contained vs. referencing EPRs core design
i025 Martin Gudgin When Actions Collide core design
i026 Steve Vinoski Supporting Multiple Ports in EPRs core design
i027 Anish Karmarkar Pointing to WSDL location in EPRs core design
i028 Marc Hadley Implications of the presence of ReplyTo core design
i029 Harris Reynolds Disallowing Faults core design
i030 Requiring ReplyTo in Responses core design
i031 David Orchard Making wsa:Action Optional core design
i032 Use W3C XML Schema to describe the syntax all editorial
i033 Rebecca Bergersen Reference to WSDL definition in an EPR core design
i034 Anish Karmarkar Action Defaults wsdl design
i035 Marc Hadley Fixed action URI for faults wsdl design
i036 Greg Truty WS-Addressing MIME Media Type core design
i037 Harris Reynolds Replace QNames with anyURI all design
i038 Martin Gudgin Scope of message addressing properties core design
i039 Hugo Haas Spec name versioning all editorial
i040 Arun Gupta Processing Model for our SOAP Faults soap design
i041 Paul Downey Use Cases for Testing test design
i042 David Orchard Extensibility Model core design
i043 Marc Hadley Comparing RefPs core design
i044 Hugo Haas Definition of the Rules to Reply to a Message core design
i045 Action defaults don't work with URNs wsdl design
i046 Jonathan Marsh Comparison of URIs used as identifiers core design
i047 Marc Hadley Absolute vs. Relative URIs soap design
i048 Francisco Curbera EPR Comparison core design
i049 Jonathan Marsh 'default default' action URI for fault messages wsdl design
i050 Hugo Haas Misalignment of treatment of reply messages and fault messages core design
i051 Hugo Haas Binding of Message Addressing Properties in the SOAP underlying protocol soap design
i052 Anish Karmarkar What is a logical address? core design
i053 Schema Tweaks schema design
i054 Extending MAPs to add new endpoint types core design
i055 Jonathan Marsh Namespace URI content all editorial
i056 Anish Karmarkar Determining the value of the [destination] property from WSDL wsdl design
i057 Anish Karmarkar Determining the value of the [reference parameters] property from WSDL wsdl design
i058 Defining MAPs in WSDL service descriptions wsdl design
i059 Glen Daniels Support for asynchronous / multi-MEP usage of web services wsdl design +
i060 Jonathan Marsh Spec namespace splitting all design
i061 Francisco Curbera Action without UsingAddressing wsdl design
i062 "Fault:" interacts with [delimiter] wsdl design
i063 Definition of the WSDL 2.0 binding needs to be in terms of the WSDL component model wsdl editorial
i064 Jonathan Marsh Migration of @Action from WS-A 200408 to WS-A 1.0 all design
i065 Katy Warr What to do when SOAPAction and Default Action Pattern conflict? wsdl design
i066 Jonathan Marsh wsaw:UsingAddressing as a policy assertion wsdl design
i067 SOAP 1.2 support for Async wsdl design
i068 One-Way SOAP 1.1 Binding for HTTP wsdl design
i069 Katy Warr Complications due to wsaw:UsingAddressing and wsaw:Anonymous on endpoint wsdl design
i070 Katy Warr Allow for runtime override of WSDL address when generating [destination] MAP wsdl design

Detailed Listing

i001 EPRs as Identifiers search core - design - closed
Description
The Architecture of the World Wide Web, First Edition indicates that distinct resources must be assigned to distinct URIs. This must be considered when refining the mechanism for the service specific message headers.
Origin
Charter (source)
Owner
David Orchard
Proposal 1 2004-11-05
Proposal 2 2004-12-01
Proposal 3 2004-12-03
Remove Reference Properties from the specification, and remove all references to the use of EPRs as identifiers.
Resolution2005-01-18
Accept proposal 3.
i002 WS-Policy dependence search core - design - closed
Description
The WS-A Submission normatively references WS-Policy, which is not a recognized standard.
Origin
Charter (source)
Owner
Mark Nottingham
Resolution2004-10-26
We will not reference the WS-Policy spec.
i003 WSDL MEPs search wsdl - design - closed
Description
Which WSDL 1.1 or 2.0 MEPs will be supported? The charter requires "all WSDL 1.1 or 2.0," including asynchronous use of those MEPs.
Origin
Charter (source)
Owner
Martin Gudgin
Proposal 1 2004-11-11
Resolution2004-11-15
Gudge's list of MEPs is accepted, and his descriptive text will be the starting point for further work.
i004 Security Model search core - design - closed
Description
The charter requires the WG to deliver a "security model for using and communicating these abstract properties."
Origin
Charter (source)
Owner
Martin Gudgin
Proposal 1 2005-02-21
Resolution2005-03-01
Text accepted by WG
i005 SOAP and WSDL references search core - design - closed
Description
WS-A references SOAP 1.1 and WSDL 1.1; these are not recognized standards, and the charter states "deliverables for the SOAP 1.1 and WSDL 1.1 bindings must include language that the bindings are defined for backward compatibility only."
Origin
Charter (source)
Resolution
References to SOAP 1.1 and WSDL 1.1 will be normative, and optional for implementation. Our intent is to include both in the test suite.
i006 Message Property Optionality search soap - design - closed
Description
In some situations, information is required, when it could be optional; e.g., the To address that's also in the transport binding. Could it be made optional?
Justification

The specification currently mandates the serialization of some message addressing properties as SOAP headers in messages when they could be omitted without loss of information or is less than clear about their optionality:

  1. Anonymous address: <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
  2. <wsa:ReplyTo> - optional, "MUST be present if a reply is expected", "If the [reply endpoint] is absent, the contents of the [source endpoint] may be used to formulate a message to the source." I.e. it must be present, but if not use <wsa:From> instead.
  3. <wsa:From> - optional, can be used to provide a default for ReplyTo and FaultTo.
  4. <was:Action> is already being discussed elsewhere.
Origin
Marc Hadley
Owner
Marc Hadley
Proposal 1 2004-11-08
  1. Omission of a <wsa:To> header block is semantically equivalent to its inclusion with a value of "http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous", a role of ultimate recipient (or maybe next depending on outcome of issue 7) and mustUnderstand="true" .
  2. <wsa:From> required if a reply is expected,
  3. <wsa:ReplyTo> only required if a reply is to be sent to an endpoint other than the one in <wsa:From>.
Resolution2005-01-19
Accept Marc's proposal.
i007 Processing model of headers search soap - design - closed
Description
The Addressing-defined SOAP headers need to specify their processing models.
Origin
Marc Hadley
Owner
Marc Hadley
Proposal 1 2005-02-04
Proposal 2 2005-03-01
Modified proposal 1, created during F2F
Resolution2005-03-01
Accept Proposal 2; additionally, note that the default target of headers is the ultimate receiver; extensions may change this.
i008 RefProps/RefParams as individual SOAP headers search soap - design - closed
Description
RefP's explicitly use the SOAP processing model, and force senders to send 1st class SOAP headers they don't understand. This could cause problems.
Origin
Glen Daniels
Owner
Glen Daniels
Proposal 1 2004-12-13

This proposal is based around the idea that other addressing headers (ReplyTo, From, etc) are EPRs, so why not To as well? (this was issue 16) We change the type of wsa:To from anyURI to EPR, and then reference properties associated with the destination EPR will naturally serialize inside the wsa:To header. The EPR above would end up serializing like this (ns declarations are assumed):

 <soap:Header>
 <wsa:To>
  <wsa:Address>http://address</wsa:Address>
  <wsa:RefPs>
    <objectID>5</objectID>
    <clusterKey>4f7g</clusterKey>
  </wsa:RefPs>
 </wsa:To>
</soap:Header>
 

This serialization makes it clear to anyone reading/processing the message that the refp's are associated with WSA, and in fact with the To address in particular. The problems with the "meaning" of inserting first-order headers go away, as do issues with knowing which headers are RefPs and therefore might require different security signatures, etc.

Proposal 2 2004-12-13

This proposal leaves wsa:To the way it is, and adds a new top-level header wsa:RefPs (depending on any decisions about merging/removing refProps and refParams, this might really be two headers wsa:ReferenceProperties and wsa:ReferenceParameters) to contain the refPs. The EPR above would serialize like this:

 <soap:Header>
 <wsa:To>http://address</wsa:To>
 <wsa:RefPs>
   <objectID>5</objectID>
   <clusterKey>4f7g</clusterKey>
 </wsa:RefPs>
</soap:Header> 
Proposal 3 2004-12-14

SOAP Headers that are added because they were part of an EPR's ReferenceProperties are marked by adding the following attribute: wsa:type="property"

SOAP Headers that are added because they were part of an EPR's ReferenceParameters are marked by adding the following attribute: wsa:type="parameter"

Complete Sample:

  <SOAP-ENV:Envelope> 
      <SOAP-ENV:Header> 
          <wsa:MessageID>msgid:1234567902282223</wsa:MessageID> 
          <wsa:To>http://www.example.com/services/someService</wsa:To> 
          <wsa:Action>http://www.example.com/someAction</wsa:Action> 
          <wsa:From>http://www.example.com/clients/someClient</wsa:From> 
          ... 
          <tns:resourceID wsa:type="property">DataChunk42</tns:resourceID> 
          <tns:expires wsa:type="parameter">32000</tns:expires> 
      </SOAP-ENV:Header> 
      <SOAP-ENV:Body> 
         ... 
      </SOAP-ENV:Body> 
 </SOAP-ENV:Envelope> 
 
Resolution2005-01-18
Proposal 3 accepted (no header to require understanding).
i009 Cardinality of properties and their values search core - design - dropped
Description
Some properties, e.g., ReplyTo, only allow one EPR as a value, when it may make sense to have multiple values; e.g., sending to many people. Also, some people might want to send multiple instances in the same message, e.g., multiple ReplyTo headers. Should this be disallowed?
Justification

The charter Scope #1 cites "a URI for destination address" (singular) whilst scope#4 describes "subsequent destinations" (plural). However the charter puts out of scope "new WSDL MEPs, composition of MEPs, or interaction patterns, such as pub-sub, callback or notification mechanisms".

This indicates that whilst addressing may be used in message exchanges with more than one message destination, it is firmly out of scope for this working group to define such message exchange patterns or how they should be processed.

We are also chartered to refine the WS-Addressing member submission which restricts the cardinality of message informational headers such as destination, source, reply, fault, action and message id to be at most one instance per message.

Allowing properties with a cardinality of greater than one introduces several issues surrounding how the list should be processed, such as:

  1. order (precedence) - is this important?
  2. quantification (how much more desirable is address A over B?)
  3. composition (send to at most one-of these, send here but not there, etc)
  4. recovery following failures

It's easy to imagine a list of To addresses, for example, being used in a multitude of simple to complex scenarios:

  1. distribution lists (send to all, ignore failures)
  2. load balancing (round-robin)
  3. fail-over (attempt each alternate address in turn)
  4. statistical (send to 5 random people out of these 100)
  5. policy driven (send fastest weekdays, cheapest weekends)
  6. combinations of the above

So defining how a list of properties introduces processing issues which are likely to be a very time consuming activity for this WG.

Defining a processing model for a list of properties could preclude such a list being used in the future for unforeseen purposes.

Origin
Paul Downey
Owner
Paul Downey
Proposal 1 2004-12-01
Status quo from the WS-Addressing member submission. Cardinality of EPRs constrained in the core to 0 or 1 and therefore also in any derived bindings.
Proposal 2 2004-12-01
Preclude use of multiple recipients in our current SOAP bindings. Unconstrained in the core, but no specific processing defined for multiple EPRs.
Proposal 3 2004-12-01
Cardinality of EPRs unconstrained in the core spec or bindings. No processing model defined for multiple EPRs. We will also provide an EPR 'processingStyle' URI value. This would default to a value indicating the current action for formulating a reply message should be undertaken with an undefined behaviour for multiple items. Extensibility could then provide a URI for mailing-list, load-balancing, fail-over, etc processing.
Resolution2005-01-18
Accept proposal 1 (status quo).
i010 EPR Robustness search core - design - dropped
Description
The EPR structure only requires an address at this point; more metadata is required to describe a Web service. Should more information be required to be included in EPRs?
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Resolution2004-12-13
Duplicate of i023.
i011 EPRs in To search core - design - dropped
Description
Why isn't the value of the To property an EPR?
Origin
Harris Reynolds
Owner
Harris Reynolds
Resolution2004-12-07
Duplicate of i008, i013, i016.
i012 EPR Life Cycle search core - design - closed
Description
At the moment there is no specification of the lifetime/lifecycle of an Endpoint Reference. In particular, 1) Is there a need to provide a mechanism for management of EPR lifetime? If yes, then what should it do? 2) Is there a need to make some statement concerning an implied EPR lifetime? If yes, then what?
Origin
Marc Hadley
Owner
Robert Freund
Proposal 1 2004-11-04
  1. WS-A will not define a lifetime mechanism for EPRs
  2. EPRs will be considered to live indefinitely.  Such statement shall be made simply in the spec
  3. Error 404 shall be returned for any EPR not recognized by an endpoint.  Such statement shall be made in in the faults section of the spec
 
Proposal 2 2004-11-09
  1. The specification will not define a lifetime/lifecycle model or mechanism for endpoint references; it will however state that WS-Addressing does not prevent lifecycle models for EPRs from being built by other specifications that use WS-Addressing.
  2. The specification will explicitly state that the time to live of an EPR is not being defined.
Resolution2004-11-15
Proposal 2 accepted.
i013 Serialising metadata into messages search soap - design - dropped
Description
Should we define a means to serialise the service QName, port, and other metadata into SOAP messages that are constructed with that EPR?
Origin
Anish Karmarkar
Owner
Anish Karmarkar
Resolution2005-01-19
Closed with no action; RefPs can be used for this purpose.
i014 Metadata Update/Reconciliation search core - design - closed
Description
Do we provide a way to determine the precedence and relationship of existing metadata to that given in an EPR, in a generic fashion? If so, what? The Member submission talks about policy precedence in section 2.4; should that remain/be expanded upon?
Origin
Hugo Haas
Owner
Hugo Haas
Proposal 1 2004-12-15

I would therefore propose that we replace the following text in section 2.3:

The following rules clarify the relation between the behaviors of the endpoints represented by two endpoint references with the same [address] and the same [reference properties].

  • The two endpoints accept the same sets of messages, and follow and require the same set of policies. That is, the XML Schema, WSDL, and policy metadata applicable to the two references are the same.
  • In particular, the policies applicable to the two endpoints are the same regardless of the values of any embedded [policies]. Embedded policies are not authoritative and may be stale or incoherent with the policies associated with the endpoint.

by the following more general statement which applies to more than [policies]:

The following rules clarify the relation between the behaviors of the endpoints represented by two endpoint references with the same [address] and the same [reference properties].

The two endpoints accept the same sets of messages, and follow and require the same set of policies. That is, the XML Schema, WSDL, and policy and other metadata applicable to the two references are the same.

However, 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.

In case the embedded metadata of an EPR conflicts with the embedded metadata of another equivalent EPR, i.e. an EPR having the same [address] and [reference properties] properties, or with metadata for the referred endpoint obtained from another source, mechanisms that are outside of the scope of this specification, such as EPR life cycle [link to section 2.4 Endpoint Reference Lifecycle] or retrieving metadata from an authoritative source, SHOULD be used to resolve the conflict.

Resolution2005-01-10
Proposal one accepted, as amended by Paco.
i015 Redirection search core - design - dropped
Description
ReplyTo affects responses to "this" message; there isn't a way to tell someone to use an new EPR. There may be other scenarios that require separate semantics.
Origin
Marc Hadley
Owner
Marc Hadley
Proposal 1 2005-01-31
Drop this issue; functionality already available elsewhere.
Resolution2005-01-31
Dropped; functionality already available in WS-CAF.
i016 Distinguishing RefProperty headers search soap - design - dropped
Description
What is the relationship between SOAP headers that are generated from ReferenceProperties and those that are from WSDL?
Origin
Marc Hadley
Owner
Glen Daniels
Resolution2005-01-18
Duplicate of i008.
i017 Purpose of the Action property search core - design - closed
Description

a) The spec states that the [action] property is supposed to uniquely identify the semantics implied by the message. Is the value of the [action] property required to be distinct within the scope of WSDL messages/operations/interface/service (?), when using WSDL to describe the Web service? It seems to me that the [action] property would be distinct at least within the scope of an interface/operation. Is there any good reason not require it to be distinct? If not distinct, there should at least be guidance regd re-use of the [action] value to the creators of WSDL docs.

This subissue was resolved at the Melbourne F2F; Action is not required to be distinct.

b) What is the relationship of the operation-name mapping requirement of WSDL 2.0 to the [action] property? If the [action] property is required to be distinct this can satisfy the operation-name mapping requirement of WSDL 2.0. If the [action] property is not required to be distinct, it would still be possible to define a feature that requires it to be distinct and use this feature to satisfy the operation-name mapping requirement.

This subissue was resolved on the 2005-08-22 teleconference with proposal 2 (adding explanatory text, but no flagging mechanism in WSDL itself.)

Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 1 2005-01-03
subissue (b)
Proposal 2 2005-02-04
subissue (b)
Proposal 3 2005-05-23
subissue (b)
Resolution2005-08-22
Accepted proposal 2, with suitable editorial adjustments to align with WSDL.
i018 Protocol-specific markup in ReferencePs search core - design - dropped
Description
Different protocols (e.g., SOAP 1.1 vs. SOAP 1.2) have different markup for certain features; e.g., actor vs. role. If you want to be able to use those features ( one rationale for serialising referencePs as headers), you need to know which protocol you're using; this makes referencePs less abstract.
Origin
Glen Daniels
Owner
Glen Daniels
Resolution2005-02-07
Closed with no action; WG notes that multiple protocols can be accommodated by multiple attributes on RefPs, etc.
i019 WSDL Version Neutrality search core - design - closed
Description
The Member submission uses many WSDL 1.1-specific terms and concepts; we need to make the language equally applicable to WDSL 2.0. E.g., mapping operation names to URIs.
Origin
Hugo Haas
Owner
Hugo Haas
Proposal 1 2004-11-08
Resolution2004-11-15
Proposal 1 accepted; action defaults problem split to issue i034.
i020 Addressing and WSDL search core - design - closed
Description

Subissue a: WS-Addressing submission section 2 (and now the WSDL binding spec section 2) talks about the current limits of WSDL as a justification to not reuse WSDL syntactic structures. These limits do not exist and therefore the justification should be removed. The same section also talks about usecases where WS-Addressing "will" be used. Those usecases can also be satisfied without using WS-Addressing.

We resolved this subissue (2005-01-17) by making the necessary editorial changes.

Subissue b: EPR represents things that the service element in WSDL can represent. Why does ws-addressing not reuse existing syntactic structures, where they do meet the requirements, instead of inventing new ones?

We decided to drop this subissue (2005-01-17), as we have WS-Addressing submission as our starting point and there is not a whole lot of support to redesign it.

Subissue c: An EPR allows one to include (optionally) a service endpoint/port. If such an endpoint/port is included in an EPR, what is the relationship between the value of the [address] property and the URI value in the [service-port] property? We have said that the [address] property is a logical address and not necessarily the physical endpoint where messages can be sent and how the mapping between logical to physical takes place is an extensibility point. Is that true if a service QName is present in the EPR. I.e., should our spec say that if the service QName is present then the physical address is what is specified by the wsdl port.

This subissue was resolved on the 2005-09-12 teleconference: see resolution.

Subissue d: WS-Addressing talks about an Endpoint Reference, but does not say what an endpoint is. So what does an EPR refer to? WSDL also has the concept of an endpoint. What is the difference between the two, if any.

This subissue was resolved on the 2005-02-14 teleconference: add "Note that WSDL 2.0 has an Endpoint component [ref] which along with other WSDL 2.0 components can be used to describe a Web service endpoint. A Web service endpoint may in fact have multiple such descriptions. Similarly, multiple EPRs can be used to convey information needed to address a particular Web service endpoint. An EPR is intended to convey information required to address a Web service endpoint whereas a WSDL 2.0 description is intended to describe a Web service." after "A Web service endpoint is a (referenceable) ... needed to address a Web service endpoint." in the core.

Origin
Anish Karmarkar
Owner
Anish Karmarkar
Proposal 1 2005-01-18
subissue (c)
Proposal 2 2005-09-12
subissue (c), revised
Resolution2005-09-12
Accept proposal 2 for subissue c, noting that i052 covers the logical vs. physical aspect.
i021 WSDL Extension for Addressing search wsdl - design - closed
Description
Does there need to be an extension for WSDL to explicitly call out the use of Addressing?
Origin
Philippe Le Hégaret
Owner
Hugo Haas
Proposal 1 2004-11-05
Proposal 2 2005-04-19
Resolution 2005-04-20
Accepted Proposal 2, with modifications.
i022 Relationship to the SOAP binding framework search soap - design - closed
Description
The rules of the SOAP binding framework need to be reconciled with Addressing; e.g., precedence.
Origin
Marc Hadley
Owner
Greg Truty
Proposal 1 2004-12-17
Proposal 2 2005-02-18
Define a SOAP module
Resolution2005-03-01
  • Say explicitly in this section that we define a SOAP 1.2 module, the SOAP Addressing 1.0 module, and give it a URI: http://www.w3.org/YYY/MM/addressing/module
  • Add a section specific to the SOAP 1.1 binding of Addressing to give a URI to this extension (e.g., for WSDL 2.0 description), referring to the URI in the SOAP 1.2 section.
i023 Required properties in EPRs search core - design - closed
Description
Should [address], [selected port type] and [service-port] be required in EPRs?
Origin
Rebecca Bergersen
Owner
Rebecca Bergersen
Resolution2004-12-09
Address will be mandatory; other properties wil be optional (status quo).
i024 Self-Contained vs. referencing EPRs search core - design - closed
Description
Should EPRs be capable of carrying metadata both by value and by reference? Should there be a generic inclusion mechanism for metadata in EPRs? Best practices defined?
Origin
Rebecca Bergersen
Owner
Rebecca Bergersen
Proposal 1 2005-01-31
Add a metadata construct to EPRs.
Resolution2005-02-28
Resolution of i026 satisfyies the original concerns that led to this issue.
i025 When Actions Collide search core - design - dropped
Description
Are there any cases when a message requires two (or more) actions, and what are the semantics when there are multiple actions?
Origin
Greg Truty
Owner
Martin Gudgin
Resolution2005-01-24
WG Affirms that there should only be one action; current text is adequate.
i026 Supporting Multiple Ports in EPRs search core - design - closed
Description
In the situation where there are different protocols/transports/formats available for the same service, accessing the endpoint requires the client to choose among alternatives, each accessible in the standard manner through a port - but there are different ports for each protocol/transport/format alternative.  When such alternatives exist, the EPR must be able to  identify those multiple ports.
Origin
Rebecca Bergersen
Owner
Steve Vinoski
Proposal 1 2004-11-12
Augment the existing EPR with an optional element that contains by value information about alternative service ports and addresses.
Proposal 2 2004-11-12
Create a new reference container type that can hold one or more EPRs.
Proposal 3 2005-02-04
Add a metadata construct to EPRs.
Proposal 4 2005-02-24
Friendly amendment to proposal 3.
Resolution2005-02-28
Proposal 4 accepted, with the following changes;
  • all WSDL-related metadata and examples will move to the WSDL doc, in a separate Namespace where appropriate
  • the embedded WSDL appendix is normative
  • MUSTs in that appendix become SHOULDs
  • WSDL-related metadata isn't expressed as properties; only appear abstractly in the metadata property's infoset.
i027 Pointing to WSDL location in EPRs search core - design - dropped
Description
EPRs have WSDL bits - e.g. PortType, ServiceName. But, no pointer to the actual WSDL itself is defined - why not?  W/o the WSDL do these values mean anything?   And if we assume the consumer of the EPR has the WSDL why can't we assume they know the PortType and ServiceName?
Origin
Doug Davis (source)
Owner
Anish Karmarkar
Resolution2004-12-09
Duplicate of i033.
i028 Implications of the presence of ReplyTo search core - design - dropped
Description
If a response message is expected then a wsa:ReplyTo MUST be included.   Does the absence of a wsa:ReplyTo imply a one-way message?   And does the presence of wsa:ReplyTo imply a two-way message?  
Origin
Doug Davis (source)
Owner
Marc Hadley
Resolution2004-12-08
Duplicate of i038.
i029 Disallowing Faults search core - design - closed
Description
wsa:FaultTo "may be absent if the sender cannot receive fault messages (e.g. is a one-way application message)." But it also says that in the absence of wsa:FaultTo the wsa:ReplyTo/From may be used. So, how does a sender really say that it doesn't want ANY fault messages at all but still be allowed to specify a wsa:From?
Origin
Doug Davis (source)
Owner
Harris Reynolds
Resolution2004-12-07
Add "when present" to the second sentence of [fault endpoint] of Core section three; remove third to fifth sentences of [fault endpoint of Core section three (so as to not imply a processing model); make similar changes in [reply endpoint] definition.
i030 Requiring ReplyTo in Responses search core - design - dropped
Description
While it would be nice to tell just from a message whether or not a response is coming back, I think the MUST requirement is too limiting. A sender may not know its address, it may be going through NAT gateways, or whatever. Also, if the response is just coming back, e.g., as an HTTP response, there is no need to require this element.
Origin
Rich Salz
Resolution2004-11-08
Duplicate of i006.
i031 Making wsa:Action Optional search core - design - closed
Description

There is some confusion as to what precisely wsa:Action is meant to represent in the current specification. However, most people seem to have the opinion that it is used to represent the semantics of the message contained in the SOAP body. In which case, this element is used for dispatching the message (similar to using an opcode in other distributed environments).

However, if wsa:Action is used to optimize dispatching so that the same semantics do not have to be obtained by parsing the entire SOAP body, this is purely an optimization. As such, its presence or lack thereof does not affect the architecture/model defined by the specification; it is entirely feasible to implement the equivalent distributed application without wsa:Action, albeit in (perhaps) a less performant manner.

Origin
Mark Little
Owner
David Orchard
Proposal 12004-11-06
Make wsa:Action optional
Resolution2004-12-08
Retain the status quo; action is mandatory.
i032 Use W3C XML Schema to describe the syntax search all - editorial - closed
Description

The current text uses an informal pseudo-EBNF to describe the XML syntax of the WS-Addressing header. See, for example, Example 2-1 in the editor's copy (as of 4-Nov-2004).

  1. Should we describe the specification using XML Schema?
  2. Should such a schema replace the "pseudo-schema"?
  3. Should such a schema be normative?
Justification
This syntax is not defined within this document (nor by any normative-quality reference that I can find). This syntax is not XML. This syntax has no mapping to the Infoset. This syntax is not useful to any widespread XML processors. The final recommendation will need to have a schema, anyway.
Origin
Rich Salz
Proposal 12004-11-05
Replace the fake stuff with xsd fragments, include a complete normative schema in an appendix.
Resolution2004-11-15
Retain the pseudo-schema for convenience; add normative XML Schema where appropriate. Use of XML is restricted to XML 1.0.
i033 Reference to WSDL definition in an EPR search core - design - closed
Description
According to the Member submission, "Endpoint references are suitable for conveying the information needed to access a Web service endpoint..."  However, in order to assure that the information needed to access a Web service endpoint, a reference to the WSDL definition of a service is sometimes required and in those cases must be included as part of the EPR construct.
Justification
This requirement derives from several common use cases. For example, in a communication chain there may be intermediaries that can accept incoming messages and, in a fully dynamic manner, further dispatch or route those onward. This is what we do with our products.  The trick is that the next recipient might use a completely different protocol/transport/format than what the message came in on. For this case it is necessary to perform a fully dynamic dispatch by using the target's WSDL definition and to build dynamic proxies and to bind to the service over one of the protocol/transport/format combinations it supports. The whole definition is required so there is access to all the possible bindings for the service. The WSDL definition is also used in cases where consumer applications want to avoid compiling in static port type information, and instead want, for flexibility purposes, late (runtime) binding to the service.
Origin
Rebecca Bergersen
Owner
Rebecca Bergersen
Proposal 1 2004-11-10
  1. Extend section 2.1, Information Model for Endpoint References, to include the following:

    [definition] : URI (0..1)
    The optional element that provides an link to the WSDL service
    definition.
  2. Extend section 2.2, Endpoint Reference XML Infoset Representation, to include the following:

    Example 2-1. @@@
    <wsa:EndpointReference>
      ...
      <wsdl:serviceDefinition>xs:anyURI</wsdl:serviceDefinition>
      ...
    </wsa:EndpointReference>

    and to include the following as a description of the additional information:

    /wsdl:serviceDefinition
    This optional element provides a link to the WSDL service
    definition.
Resolution2004-12-09
Coordinate with WSDL WG to assure that @wsdli:wsdlLocation can also refer to WSDL 1.1 descriptions; illustrate its use in examples, on EPRs with portType and with service ref.
i034 Action Defaults search wsdl - design - closed
Description

Section 3.3 describes a WSDL 1.1-specific mechanism for determining a default Action MIH. If the service has a WSDL 2.0 description, another mechanism needs to be used, which is actually defined by the WSDL 2.0 specification.

Also, if there is a WSDL 1.1 and WSDL 2.0 description available, which is the implicit value of the action property? If in a year's time we release WSDL 2.1, what happens? I believe that there is an implicit value of the action URI recognized by the recipient of the addressing information for the description of the service made in each version of WSDL. Those are equivalent for the purpose of our specification.

Origin
Hugo Haas
Owner
Anish Karmarkar
Proposal 1 2004-12-08
WSDL 2.0 Component Designators -> WSDL 1.1
Proposal 2 2004-12-17
WSDL 1.1 Default Actions -> WSDL 2.0
Resolution2005-01-10
Proposal 2 accepted.
i035 Fixed action URI for faults search wsdl - design - closed
Description
The specification defines a default action pattern that is used to generate an action URI for WSDL input and output messages. The pattern uses a fixed URI ( http://www.w3.org/2004/10/addressing/fault) for fault messages - why ?
Justification
One of the justifications for requiring a wsa:Action header in SOAP messages is that it provides information that would otherwise require a processor to look at other parts of the message and can be used for dispatching messages. Having a fixed URI for all fault messages reduces the usefulness of wsa:Action in messages that are faults to a simple 'this is a fault message' indicator (something that the SOAP Recommendation already defines the criteria for) and requires inspection of the message body to determine which WSDL fault message is being conveyed.
Owner
Marc Hadley
Proposal 12004-11-15
Eliminate the fixed URI and extend the default action pattern to generate unique URIs for each fault message as well as the input and output message. Retain the capability to easily differentiate a fault action from a non-fault action.
Resolution2005-01-17
From Jonathan's proposal; accept WSDL 1.1 proposal as is and accept the [target namespace]/[interface name]/[fault name]Fault proposal for WSDL 2.0.
i036 WS-Addressing MIME Media Type search core - design - closed
Description
It would be generally helpful for the working group to define a MIME Media Type for WS-Addressing.
Justification
It's a minor issue, but a MIME Media Type would make it easier to embed WS-Addressing EndpointReferences in MIME packages, or to identify the content type when passing EndpointReferences around.
Origin
James Snell (source)
Owner
Greg Truty
Resolution2004-12-07
Decline to define a media type.
i037 Replace QNames with anyURI search all - design - closed
Description
There are several places where we use QName's for attribute values (e.g., RelatesTo/@RelationshipType) and for content (e.g., ServiceName). Should we replace those with URI's?
Justification
Everyone else is doing it. :) The TAG finding can be interpreted as encouraging it.
Origin
Rich Salz (source)
Owner
Harris Reynolds
Resolution2004-12-07
Status quo for WSDL elements, URI for relationshipType attribute value; use a slash, not a hash.
i038 Scope of message addressing properties search core - design - closed
Description
What is the expected scope of each message addressing property. E.g. Does the presence of a wsa:ReplyTo in the response message of a request-response MEP indicate that future messages in the same 'logical' conversation should be sent to the EPR in the ReplyTo.
Justification
During discussion of issue 028 it emerged that there were different views on the scope of message addressing properties. Some WG members (myself included) assumed that message addressing properties were scoped to a particular instance of an MEP while others believe that their impact can extend beyond that scope. The specification doesn't appear to support any one view.
Origin
Marc Hadley (source)
Owner
Martin Gudgin
Resolution2005-01-17
MarcH's edits to spec, along with Paco's adjustments to core, accepted.
i039 Spec name versioning search all - editorial - closed
Description
Our drafts are currently called: Web Services Addressing — (Core|(SOAP|WSDL) Binding) As we may want to create another version of this technology (e.g. minor revision for bug fixing), I believe that it would be good to indicate versioning in the name of the technology to differentiate between different versions. There may also be some confusion with the Member Submission called: Web Services Addressing (WS-Addressing)
Justification
Most specs (XML, HTML, SOAP, WSDL, etc.) have a version number, which makes it easy to talk about a particular version of a technology (e.g. SOAP 1.1 versus 1.2). Also, versioning is typically considered as a good thing.
Origin
Hugo Haas (source)
Owner
Hugo Haas
Proposal 1 2004-11-24
Change the titles to: Web Services Addressing 1.0 — (Core|(SOAP|WSDL) Binding)
Resolution2004-12-07
Change titles to: "Web Services Addressing 1.0 - (Core|(SOAP|WSDL) Binding)". Editors and Team have appropriate latitude WRT short name and cross-refs.
i040 Processing Model for our SOAP Faults search soap - design - closed
Description
The SOAP binding states the following: "If neither is present faults may be sent to the [source endpoint]." We deleted similar text in core in the [fault endpoint] description, should we delete the above?
Origin
Marc Hadley
Owner
Arun Gupta
Resolution2005-01-19
Remove the following from the SOAP Binding spec, Section 3, 1st para: "They are sent to the [fault endpoint], if present and valid. Otherwise they are sent to the [reply endpoint] if present. If neither is present faults may be sent to the [source endpoint]."
i041 Use Cases for Testing search test - design - dropped
Description
What particuar use cases should we test for in CR? E.g. WSDL MEPs, SOAP bindings, etc. See also the charter.
Origin
Mark Nottingham
Owner
Paul Downey
Resolution2005-08-22
Issue dropped (CR-focused, not pertinent to WD).
i042 Extensibility Model search core - design - closed
Description

We discuss the fact that extra elements/attributes might appear in the infoset of an EPR in section 2.2, but we do not discuss any sort of a processing model for these extensions.

Also, The abstract properties list in section 2.1 doesn't have any statement about extensibility.

Also, We should decide if we want to support a "mustUnderstand" marker on extensions a la SOAP/WSDL, or if we want to discuss "ignoreUnknown" semantics for unrecognized extensions/properties.

Origin
Glen Daniels
Owner
David Orchard
Proposal 1 2005-02-04
Resolution2005-02-21
Accept proposal 1.
i043 Comparing RefPs search core - design - dropped
Description
What form of comparison do we require to determine equivalence; in particular do we need to define a canonicalization that is performed prior to comparison?
Origin
Marc Hadley
Owner
Marc Hadley
Proposal 1 2005-01-31
Remove section about comparing EPRs.
Proposal 2 2005-01-31
Add text suggesting EXCC14N, warning of false positives.
Proposal 3 2005-01-31
Proposal 2 + discourage refparams that use QNames in content.
Resolution2005-02-27
Dropped with no action as a result of i048 resolution.
i044 Definition of the Rules to Reply to a Message search core - design - closed
Description

The Core spec, section 3.2 Formulating a Reply Message states:

The reply to a WS-Addressing compliant request message MUST be compliant to WS-Addressing and be constructed according to the rules defined in this section.

However, this section only defines an example and no rules.

Origin
Hugo Haas
Owner
Hugo Haas
Proposal 1 2005-01-17

Spell out rules for replying to a message:

  1. select reply endpoint, fault, or source EPR, depending on the type of message being replied and the information found in the first message
  2. use the EPR's [address] property as the [destination] MAP
  3. use the [message id] MAP as the [relationthip] URI with the right relationship type
  4. echo the EPR's [referance properties] and [reference parameters] as SOAP headers
Proposal 2 2005-02-01
Proposal 3 2005-02-14
Resolution2005-02-14
Proposal 3 accepted.
i045 Action defaults don't work with URNs search wsdl - design - closed
Description

There is a potential problem in the Action defaulting algorithm we've selected. It works great for http: URIs as the namespace, and continues the http hierarchy by adding new path components separated by slashes.

However, slash isn't allowed as a path component by all URI schemes. Notably, URNs don't allow slash as far as I can tell, and you often see paths delimited by ":" instead. If a URN is used as a targetNamespace (which seems reasonable, though we can argue whether this trend will wither or flourish), you might end up with a default Action like:

urn:com:microsoft:schemas:thisWsdl/dohicky/sendMoneyRequest

which is a bad URN.

Origin
Jonathan Marsh
Proposal 1 2005-01-17
Resolution2005-01-24
Accept Proposal 1.
i046 Comparison of URIs used as identifiers search core - design - closed
Description
Several of the URIs defined by WS-Addressing are used primarily for identification rather than primarily dereferencing: [message id], [relationship], and [action]. In other specifications, how to compare values of these properties is usually defined. WS-Addressing would benefit from a section like this as well.
Origin
Jonathan Marsh
Owner
Jonathan Marsh
Proposal 12005-01-15
I propose we essentially copy the WSDL 2.0 section on this into the WS-A spec.
Proposal 2 2005-01-31
Resolution2005-01-31
Proposal 2 accepted, without enhancements.
i047 Absolute vs. Relative URIs search soap - design - closed
Description
The following message addressing properties are URIs: [destination], [action], [message id], [relationship/relatesto], [relationship/type]. In addition the message addressing properties [source endpoint], [reply endpoint] and [fault endpoint] each contain [address] properties that are also URIs.
Origin
Marc Hadley
Owner
Marc Hadley
Proposal 1 2005-02-04
Resolution2005-02-14
All Message Properties whose values are URIs must be serialised as absolute URIs in the SOAP binding.
i048 EPR Comparison search core - design - closed
Description
The section on comparing EPRs was originally intended to contextualise RefProps vs. RefParams; now that RefProps are gone, does it make sense to keep this text? If so, it needs to be considerably tightened up.
Justification
The text now states that two EPRs with the same URL and different ref. params. have the same metadata. This leaves out an important use case of Web service gateways/routers which is one of the most pervasive Web services products in the industry. In a gateway architecture we encounter situations where a single external address (http, smtp, message queue o whatever) front ends a variety of services deployed inside the enterprise. These have typically different metadata, including both different WSLD and policies, etc. This not uncommon arrangement will not be supported by the resolution above, since the implication is that all services would need to be different copies of the same one - same WSDL etc. Note that this kind of restriction is also completely absent from WSDL 2.0 for example, where two endpoints are not restricted to have separate addresses.
Origin
Francisco Curbera
Owner
Francisco Curbera
Proposal 12005-01-25
Remove the section on EPR comparison (2.3 in the core) and any corresponding text.
Proposal 2 2005-02-20

Clarify 2.3 to say:

The following rule clarifies the relation between the behaviors of the endpoints represented by two endpoint references with the same [address];

  • The two endpoint references refer to the same endpoint that accepts a set of messages, follow and require a set of policies that are defined by a (set of) XML Schema(s), WSDL(s), and policies and other metadata applicable. Hence, these endpoint references are designed to utilize the set of messages, policies and descriptions that apply to the specific endpoint.
Resolution2005-02-27
Remove section 2.3 and replace with "Since this specification provides no concept of identity, it does not provide any mechanism to determine equality or inequality of EPRs, nor does it specify the consequences of equality or inequality. Note that it is possible to provide a comparison function that is applicable within a limited scope" along with examples illustrating this.
i049 'default default' action URI for fault messages search wsdl - design - dropped
Description
The resolution for Issue 35 removed the fixed default action URI for fault messages and replaced it with a algorithm similar to that for non-fault messages. However, I believe we need a fixed URI for people to use when returning a fault that is NOT described in WSDL. If a fault isn't described in WSDL, then people used to be able to use the fixed URI. That option is no longer available to them.
Justification
If we don't add a 'default default' then faults not described in WSDL will have to define a specific action, whereas they might wish to utilize a default fixed value. And they may have nowhere to define that specific action because the fault is NOT described in WSDL; they can't use explicit association (wsa:Action) because there is no where to hang the attribute.
Origin
Martin Gudgin
Owner
Jonathan Marsh
Proposal 1 2005-02-04

Add text along the following lines to section 3

3.4 Default Action URI for faults NOT listed in WSDL

In some systems not all faults can or will be listed in a WSDL description. Such faults still need an action URI. Faults not listed in a WSDL description MAY use the following action URI; http://www.w3.org/ws/2005/02/addressing/fault

Proposal 2 2005-02-07
Proposal 3 2005-02-22
Resolution2005-03-01
Issue dropped with no change.
i050 Misalignment of treatment of reply messages and fault messages search core - design - closed
Description

Section 3 of the core spec presents faults as a type of reply: "A reply in this case can be either an application message, a fault, or any other message."

However, normal replies and faults are treated differently by WS Addressing processors, as the rules expressed in issue i044's resolution show:

  • for a reply to be sent back, the incoming message MUST have wsa:ReplyTo header;
  • the meaning of wsa:FaultTo, OTOH, is that if present, it specifies where faults should go; otherwise, other rules (e.g. the MEP's or the binding's) apply.
Justification

The discussion around i044 (see thread) has shown that:

  • replies and faults work under different models/philosophies in the case of a reply to an incoming message: for the latter, it when wsa:FaultTo is absent, the processor behaves just as if Addressing wasn't in use; for the former, the absence of wsa:ReplyTo is a violation of the Addressing specification.
  • this difference may cause confusion.
Origin
Hugo Haas (source)
Owner
Hugo Haas
Proposal 1 2005-02-15
Make wsa:ReplyTo optional in case of a message to which a reply is expected; this way, both wsa:FaultTo and wsa:ReplyTo can be absent and other rules (e.g. the binding rules) may apply.
Proposal 2 2005-02-15
Make wsa:FaultTo mandatory for messages which can trigger faults.
Proposal 3 2005-02-15
Leave wsa:ReplyTo and wsa:FaultTo as is, but clearly point out the difference of behavior between the two and the motivation behind this.
Proposal 4 2005-02-15
Status quo.
Proposal 5 2005-03-07
"Minimal"
Proposal 6 2005-03-14
Minimal proposal #2, expressed as rules for formulating a reply.
Resolution2005-03-21
Proposal 6 accepted.
Resolution2005-07-19
See lc69 resolution.
i051 Binding of Message Addressing Properties in the SOAP underlying protocol search soap - design - closed
Description

We define as message addressing properties concepts that happen to exist in certain SOAP underlying protocols. A good example is the [action] message addressing property and the action parameter of the application/soap+xml media type carried by HTTP's Content-Type header.

We need to clearly define the relationship for this information when it appears in different places, i.e. whether they are independent, equal, or related another way.

Justification

Questions arose about the relationship of this similar information appearing in different places[3]. Core hints that [action] and SOAP Action are similar for example[4] though the description provided is SOAP 1.1 specific.

We should provide a basis for such equivalence rules for a variety of message addressing properties and bindings.

Origin
Hugo Haas (source)
Owner
Hugo Haas
Proposal 1 2005-02-18
Add feature, properties
Proposal 2 2005-02-28
SOAPAction-specific
Resolution2005-03-01
From Proposal one, accept point 1 (definition of a feature), point 2 (definition of properties) in the SOAP binding document, and additionally a separate, Addressing-specific Action property. From Proposal 2, accept SOAP 1.2-specific text; for SOAP 1.1, add "When issuing a SOAP HTTP Request, the value of the SOAPAction property (after "" defaulting) SHOULD be equal to the value of the [action] message addressing property."
i052 What is a logical address? search core - design - closed
Description
In the core spec, it is stated that the [address] property and the wsa:Address EII may be a logical address for the service endpoint. The last published WD described wsa:Address as a 'logical address or identifier'. The word 'identifier' was removed in the current ed. draft. I'm not sure if this was an oversight or an effect of resolving issue 001.
Justification
The core spec uses the term "logical address" without explaining what it means. I have been getting some questions from our implementation team as to what a logical address means and how it is used. AFAIK, this is a new term that is being introduced without any explanation or definition of the term.
Origin
Anish Karmarkar (source)
Owner
Anish Karmarkar
Proposal 1 2005-02-21
Resolution2005-03-01
Remove sentences that refer to "logical address."
i053 Schema Tweaks search schema - design - closed
Description
Improvements and corrections to the schema.
Proposal 1 2005-02-27
Add attribute wildcards to ReferenceParamatersType and PoliciesType so there is consistent attribute extensibility throughout.
Proposal 2 2005-02-27
The spec says @RelationshipType defaults to "http://www.w3.org/2005/02/addressing/reply" but this isn't indicated in the schema. Although we don't want to require schema validation in order to construct the property value correctly, is there a reason we shouldn't describe this defaulting in the schema? Propose defaulting it in the schema.
Proposal 3 2005-02-27
Add @blockDefault="#all" to xs:schema.
Proposal 4 2005-02-27
Add @elementFormDefault="qualified" to xs:schema.
Proposal 5 2005-02-27
We seem to mix styles on the names of types; some end in "Type", others don't. Append "Type" to AttributedURI, AttributedQName, FaultCodesOpenEnum, FaultCodes, AttributedNonNegativeInteger.
Proposal 6 2005-02-28
Define RetryAfter as xs:unsignedLong
Proposal 7 2005-03-08
Promote metadata element to top level of schema
Resolution2005-02-27
Accept proposal #1, #2, #5.
Resolution2005-03-07
Accept proposal #3, #4; reject #6; add ednote asking for feedback on type of RetryAfter.
Resolution2005-03-14
Accept proposal #7.
i054 Extending MAPs to add new endpoint types search core - design - closed
Description

Asynchronous applications may define interactions in which an incoming message may produce outgoing messages to any number of different endpoints.  To take a concrete example, a service may be required to receive a message and do one of

  1. Send a fault to a fault destination.
  2. Send application data to a "normal processing" destination.
  3. Send (possibly different) application data to a "special processing" destination.

It is not clear from section 3 of the core spec exactly how to handle this in terms of Message Addressing Properties.

Justification
The WSA charter dictates that "The components must be extensible to enable other mechanisms such as new kinds of relationships between correlated messages, policies, or service semantics to be built upon Web Services Addressing." and section 3 amplifies this, saying that "Message addressing properties collectively augment a message with the following abstract properties to support one way, request reply, and any other interaction pattern..."
Origin
David Hull (source)
Proposal 1 2005-03-17
[endpoints] MAP with (qname, EPR) tuples
Proposal 2 2005-03-18
Clarify existing MAP extensibility model.
Proposal 3 2005-03-21
Clarify that MAPs aren't extensible.
Resolution2005-03-21
Proposal 2 accepted.
i055 Namespace URI content search all - editorial - closed
Description

As many of you are aware, there is an ongoing debate on what kind of resource should be placed at the namespace URI. The TAG has been unable to recommend a practice in this area, despite a lot of discussion.

The W3C, AIUI, has a policy that there should be some document at the namespace URI, but does not enforce a particular format. In general namespace URIs seem to return HTML documents.

There are also many proponents of RDDL, which is simply an XHTML document with some machine-processable XLinks in it pointing to associated resources like schema.

Origin
Jonathan Marsh (source)
Owner
Jonathan Marsh
Proposal 12005-04-07
Place a RDDL document at each of the namespace URIs defined by WS-A. Provide a "latest schema" link as well as dated links to the schema. State in the document that the resources (schemas) at the dated links are immutable, the list of dated schemas may grow to incorporate fixes, and the latest schema link will always point to the latest. A necessary related change to the specs is for sections of the specs which say that a schema is available "at" the namespace URI to be updated to say "through" the namespace URI, or some such.
Proposal 2 2005-04-18
RDDL document
Resolution2005-04-20
Accept proposal 2.
i056 Determining the value of the [destination] property from WSDL search wsdl - design - closed
Description
The WSDL binding spec does not define how to determine the value of the [destination] property when sending messages to a Web service described in WSDL (and when WS-Addressing is also being used for that Web service).
Origin
Anish Karmarkar (source)
Owner
Anish Karmarkar
Proposal 1 2005-04-11
In the absence of additional information, the value of the destination property is the same as the value of the wsdl20:endpoint/@address attribute in case of WSDL 2.0 or the value of {http:address|soapbind:address}/@location attribute in case of WSDL 1.1.
Proposal 2 2005-04-11
Modify the proposal at [3] (for issue i021) as follows:
  1. allow the element wsaw:UsingAddressing to be a child element of wsdl20:endpoint/wsdl11:port
  2. create an optional attribute wsaw:UsingAddressing/@destination of type xs:anyURI. The value of this attribute, if present, specifies the value of the [destination] property.
Proposal 3 2005-04-11
Proposal 2, defaulting to Proposal 1
Proposal 4 2005-04-11
Allow the wsa:EndpointReference element to be included as the child element of wsdl20:endpoint or the child element of wsdl11:port. When using the wsa:EndpointReference in an wsdl20:endpoint/wsdl11:port the usual WS-Addressing/binding rules apply.
Proposal 5 2005-04-11
Proposal 4, defaulting to Proposal 1
Proposal 6 2005-04-22
Revised
Proposal 7 2005-09-29
Three options from the F2F
Resolution 2005-09-29
Accept option 1 from the F2F proposals.
i057 Determining the value of the [reference parameters] property from WSDL search wsdl - design - closed
Description
The WSDL binding spec does not define how to determine the value of the [reference parameters] property when sending messages to a Web service described in WSDL (and when WS-Addressing is also being used for that Web service).
Origin
Anish Karmarkar (source)
Owner
Anish Karmarkar
Proposal 1 2005-04-11
Modify the proposal at [3] (for issue i021) as follows:
  1. allow the element wsaw:UsingAddressing to be a child element of wsdl20:endpoint/wsdl11:port
  2. create an optional child element wsaw:UsingAddressing/wsa:ReferenceParameter. The value of this element, if present, specifies the value of the [reference parameters] property.
Proposal 2 2005-04-11
Allow the wsa:EndpointReference element to be included as the child element of wsdl20:endpoint or the child element of wsdl11:port. When using the wsa:EndpointReference in an wsdl20:endpoint/wsdl11:port the usual WS-Addressing/binding rules apply.
Resolution 2005-09-29
Accept option 1 from the F2F proposals.
i058 Defining MAPs in WSDL service descriptions search wsdl - design - closed
Description
i056 and i057 cover the specifics of describing the [destination] and [reference parameters] properties, respectively. This issues serves to assure that the description of all MAPs are addressed; in particular, we should either provide mechanisms for the following properties, or an explanation of why they are not describable in WSDL; [source endpoint], [reply endpoint], [fault endpoint], [action], [message id], [relationship].
Justification
Our charter says that the WSDL binding will include "the mechanisms for defining Web Services Addressing property values in WSDL 1.1 and WSDL 2.0 service descriptions."
Origin
Mark Nottingham
Resolution2005-04-20
The following properties were found by the WG to represent run-time
information and therefore static description of them doesn't have
sufficient utility to warrant adding WSDL extensions to control their
values:
  [source endpoint]
  [reply endpoint]
  [fault endpoint]
  [message ID]

[relationship] is a pair of IRI values, of which one (message
identifier) is run-time and not directly describable in WSDL.
Describing a relationship alone does not provide much value.

We already are designing mechanisms to control [action].
i059 Support for asynchronous / multi-MEP usage of web services search wsdl - design - closed
Description
This issue serves as a placeholder for the stuff falling into the "async" bag. How do we correctly and interoperably specify the behavior for callbacks, asynch responses, etc. over multiple transports in a consistent way? How do the various layers of MEPs (application, WSDL, SOAP) bind to each other? Etc.
Action Items
2005-11-28: Jonathan Marsh to maintain option 3 as a separate proposal. (pending)
Justification
Our charter indicates that we must specify how the MAPs are to be used in order to achieve asynchrony with all WSDL 1.1 and 2.0 MEPs. At present there is no interoperable way to do this, partially due to limitations or omissions which exist in the current SOAP and WSDL specs. In order for the WS-Addressing group to declare victory (and build a functional test suite), these limitations/omissions must be remedied, and WS-Addressing must also appropriately adapt (if necessary) to support these patterns.
Origin
Glen Daniels (source)
Owner
Glen Daniels
Proposal 1 2005-10-24
Async Extension for SOAP 1.1 / HTTP
Proposal 2 2005-10-31
Proposal 3 2005-12-01
Element with attribute, no default
Proposal 4 2005-11-29
3 + SOAP 1.2
Proposal 5 2005-12-18
revision
Resolution2005-12-19
Accept proposal 5 changes up to and including section 3.2, revising examples to include async.
i060 Spec namespace splitting search all - design - closed
Description
The proposed resolution for issue i021 plans to use a marker defined in the WSAW namespace introduced by one of the WS-A specifications to flag the use of WS-Addressing in a WSDL description.  The intent is to use the WSAW namespace to identify the WS-Addressing specification and the version of it. However given WS-A is now split into three separate specifications the chosen namespace where this marker is defined needs to identify this group of specifications and their "common" version, there by inhibiting independent versioning of the specifications. Hence this brings up a generic issue with splitting semantics of a namespace across multiple inhibiting the ability to versioning those specifications independently.
Origin
Prasad Yendluri
Owner
Jonathan Marsh
Resolution2005-06-03
Closed with no action.
i061 Action without UsingAddressing search wsdl - design - closed
Description
If the WSDL does not include wsaw:UsingAddressing in either wsdl:binding or wsdl:port but one or more wsdl:portType/wsdl:operation contain wsaw:Action, the expected behavior in such a case is unclear.
Origin
Arun Gupta (source)
Owner
Francisco Curbera
Resolution 2005-09-29
i062 "Fault:" interacts with [delimiter] search wsdl - design - closed
Description

We define the default action value for WSDL 1.1 faults as

[target namespace][delimiter][port type name][delimiter][operation name]Fault:[fault name]

IIRC part of our reasoning for using "Fault:" as part of the structure rather than [delimiter] was that having a constant number of delimiters in the pattern makes it easy to deconstruct the URI into its constituent parts (all our actions have the same number of delimiters, though the delimiter might also appear in the [target namespace]).

However, [delimiter] can be ":" which interacts with "Fault:" in a way that negates that advantage.

Origin
Jonathan Marsh (source)
Resolution2005-08-29
replace "Fault:" with "[delimiter]Fault[delimiter]"
i063 Definition of the WSDL 2.0 binding needs to be in terms of the WSDL component model search wsdl - editorial - closed
Description
Our specification does not use the WSDL 2.0 component model, even though it describes a WSDL 2.0 extension.
Origin
Hugo Haas (source)
Resolution2005-08-29
Accept issue as editorial and direct editors to use provided proposal as a starting point.
i064 Migration of @Action from WS-A 200408 to WS-A 1.0 search all - design - closed
Description
The @Action attribute serves identical purposes in the two versions – they set the [action] property which is semantically the same thing in both the 200408 and 1.0 versions. We propose a non-normative appendix to suggest ways users can author WSDLs that allow a client to choose either version of Addressing, and that unambiguously generate the same [action] values regardless of the version of addressing chosen. This appendix would highlight the divergence of the default pattern between the 200408 and 1.0 versions and advise on how that difference can be managed.
Origin
Jonathan Marsh (source)
Owner
Jonathan Marsh
Proposal 1 2005-08-30
Proposal 2 2005-10-10
Resolution2005-10-10
Accept proposal 2.
i065 What to do when SOAPAction and Default Action Pattern conflict? search wsdl - design - closed
Description

What is the correct behaviour for gen'ing wsa:Action in the client when the HTTP 1.1 SOAPAction is set ( i.e. not "") and there is no wsaw:Action explicitly specified in the WSDL?

The problem is that, the default action pattern for wsa:Action cannot be guaranteed to generate a wsa:action to match SOAPAction.

Origin
Katy Warr (source)
Owner
Katy Warr
Proposal 1 2005-10-17
In the absence of wsaw:Action, use SOAPAction in preference to defaultAction pattern.
Proposal 2 2005-10-17
In absence of wsaw:Action, use default Action Pattern (as stated currently). Relax the restriction that Action MUST equal SOAPAction (but recommend that they SHOULD equal)
Resolution2005-11-07
Accept proposal 1.
i066 wsaw:UsingAddressing as a policy assertion search wsdl - design - closed
Description
It should be possible to reuse wsaw:UsingAddressing in a domain-neutral policy framework.
Origin
Jonathan Marsh (source)
Owner
Jonathan Marsh
Proposal 1 2006-01-05
Generalise UsingAddressing element
Proposal 2 2006-01-05
Bless reuse as a framework-generic assertion
Resolution 2006-01-19
i067 SOAP 1.2 support for Async search wsdl - design - closed
Description
i059 addresses how async should be handled for SOAP 1.1. How should it be expressed in terms of SOAP 1.2?
Origin
Split from i059
Proposal 1 2005-11-29
Resolution 2006-01-19
Moved to SOAP Binding; see CR15
i068 One-Way SOAP 1.1 Binding for HTTP search wsdl - design - closed
Description
Where and how should the SOAP 1.1 HTTP-specific behaviours be described?
Origin
Split from i059
Proposal 1 2005-12-18
Section 3.4 (final disposition not necessarily in WSDL Binding doc)
Resolution 2006-01-19
Moved to SOAP Binding; see CR15
i069 Complications due to wsaw:UsingAddressing and wsaw:Anonymous on endpoint search wsdl - design - closed
Description

The wsaw:UsingAddressing element can appear on the binding and the endpoint (port) of the wsdl. Similarly, the associated wsaw:anonymous element can appear on the binding or endpoint.

Bearing this in mind, the following points require clarification in the WSDL specification:

  1. Is it acceptable to specify wsaw:Anonymous on the endpoint if the corresponding wsaw:UsingAddressing is specified on the binding?
  2. The spec indicates that it is not possible to specify wsaw:UsingAddressing on the port if it is already specified on the binding ("Alternatively, the wsaw:UsingAddressing element MAY be instead included as a child on the wsdl20:endpoint (or wsdl1.1:port)...").

So if the binding does not specify WS-Addressing, it is possible to override this at the endpoint. However, there is no mechanism to do the converse (i.e. to switch off the requirement for WS-Addressing at the endpoint if it is defined at the binding). Why are we allowing one without the other?

Origin
Katy Warr (source)
Owner
Katy Warr
Proposal 12006-01-05
Remove the ability to associate the wsaw:UsingAddressing and wsaw:Anonymous from the endpoint altogether.
Resolution2006-01-19
No change to specification.
i070 Allow for runtime override of WSDL address when generating [destination] MAP search wsdl - design - closed
Description
The WS-A WSDL spec appears to be too restrictive wrt [destination] MAP. We need to relax the wording of section 4.1 in order to allow for runtime overrides of the WSDL address.
Origin
Katy Warr (source)
Owner
Katy Warr
Resolution2006-01-20
point the editors to the resolution of i056 and especially at "in the absence of additional information", and add an example for it (runtime override)