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: Anonymous address: <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To> <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. <wsa:From> - optional, can be used to provide a default for ReplyTo and FaultTo. <was:Action> is already being discussed elsewhere. Origin Marc Hadley Owner Marc Hadley Proposal 1 2004-11-08 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" . <wsa:From> required if a reply is expected, <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: order (precedence) - is this important? quantification (how much more desirable is address A over B?) composition (send to at most one-of these, send here but not there, etc) 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: distribution lists (send to all, ignore failures) load balancing (round-robin) fail-over (attempt each alternate address in turn) statistical (send to 5 random people out of these 100) policy driven (send fastest weekdays, cheapest weekends) 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 WS-A will not define a lifetime mechanism for EPRs EPRs will be considered to live indefinitely. Such statement shall be made simply in the spec 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 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. 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). Should we describe the specification using XML Schema? Should such a schema replace the "pseudo-schema"? Should such a schema be normative?