anish: concern that if we go down this path, it may have implication with other issues.

Chair: continue discussion on the list

Issues

i001

hugo: discussion is around uri cum reference properties exacerbating problems that exist with uris as they stand
... simplicity argument is that reference properties are known to the provider and are not part of the externally usable (to the service provider) address
... disadvantage is that to secure a uri, then it must be secured in its entirety

hugo: Web arch says that resources are uniquely identified by uris.
... not ready to make a conclusion

Chair: wants to kep it moving along

<stevewinklr> +1 to clear terminology

Rutt: in order to reconcile spec with web architecture, then it will be necessary to refine the name to be something that will help
foster understanding

<anish> +1 to marc

Marc: analagy has been made that reference parameters are a lot like cookies, and that cookies are not used for addressing

Chair: from the web architecture, cookies are broken, and that they are used to carry addressing information (as well as other info)

issue 3

Chair: gudge not online

<rsalz> away away from my desk for 30 minutes, in case you care

<anish> +1 to hugo, this is tied with the issue currently being discussed in WSDL as to -- what is a node?

hugo: node is a logical entity that may be addressed uniquely

Chair: possibility is to accept the proposal and say that this is the list of starting point MEPS that will be covered
... asked for objection, none heard i003 is closed with gudge's proposal

and that MEPS covered will be part of our continuing discussions.

RESOLUTION: i003 is closed by accepting gudge's proposal for list of MEPs; supplied text will be starting point for further work.

i028

Marc: Several questions arised related to the scope of reply-to
... and with which MEPs reply-to had what meaning.
... bigger issues need to be resolved prior to i028's resolition

i029

Relates to semantics of Fault-to

Marc: ? must we define the implications of the presence or absence of each of these for each MEP?

Chair: may be part of a larger issue which is conformance to each of the documents of the specifications
... will try to raise this issue this week.

i019

hugo: wsdl 1.1 and wsdl 2.0 descriptions may both exist. What would then be the interprety of the action property

Chair: going forward, we may consider splitting hugo's sub-issue of default actions and closing the rest

marc: if action were optional, this issue would go away

anish: this is a bigger issue than action since we have reference to wsdl in other areas

Chair: let us split this up and record this as a new issue, can we close the remainder of i019?
... asked for objections/ hearing none, i019 is closed with the carve-out of the new issue to be posted

RESOLUTION: i019 is closed by accepting Hugo's proposed changes, except for those relating to the default action.

i021

hugo: we have a choice of making addressing ubiqutous, and we could request that address be defined in the soap bindings.
... addressing ought also to be represented in tools. In order to do this, one ought to define a soap 1.2 module

<anish> +1 to option #2

as well as a proposal to cover in WSDL 2.0

<marc> -infinity to option #1

<pauld> seems like ws-addressing is a good pilot for WSDL 2.0 extensibility .. so option#2

<GlenD> +1 to option 2

+1 to option 2

<GlenD> (it'll take an awful lot of +1's for option 1 to make up Marc's vote....:))

<anish> :-)

just calcualte the average vote in favor

Chair: WG will go forward with option 2.

Marsh: Believes issue needs more work concerning use over all versiosn of wsdl
... wsdl 1.2 offers one extension mechanism, 2.0 offers two. Believes debate would be meritotious as to which mechanism should be used.

Hugo: it was his intent to cover all of our bases in wdsl

Marsh: we could develop a proposal for the use of both extension models so that we could see the proposals side by side.

<scribe> ACTION: hugo: Will send another email with a refined proposal for i021 by Nov 26

i026

Multiple ports in EPRs

Chair: (aside) new issue, pls get involved in new multiple port and EPR issue.