Web Services Addressing WG Teleconference -- 20 Jun 2005

<TRutt> I will be late on joining the call, I will keep the irc open until then

<Marsh> Jonathan_Marsh holds PaulD

<uyalcina> guys, we are moving to a different location.

All the minutes where accepted

Question was raised if there will be teleconf next week due to JavaOne

It was decided to still have a meeting next week

No meeting 4th July

LC71

<mnot> Jacek's mail: [[[

<mnot> I'd like to register my disagreement with this resolution.

<mnot> I recognize that the reason element is mandatory in faults, but this

<mnot> does not mean that WS-Addressing needs to mandate what exactly it will

<mnot> be as it is only a human-oriented informative string.

<mnot> For analogy, please note that HTTP also mandates a reason string in

<mnot> replies but the spec does not mandate what that string is going to be.

<mnot> For 200 the usual is "OK", but an implementation may choose "success"

<mnot> instead, or use a different language.

<mnot> Therefore I propose that WS-Addressing only suggests what the reason

<mnot> element could contain, perhaps noting that the presence of the reason

<mnot> element is in fact mandatory in both SOAPs. This way, the content of the

<mnot> reason element would not be a WS-Addressing conformance consideration.

<mnot> ]]]

<mnot> http://www.w3.org/2002/ws/addr/lc-issues/#lc71

hugo: agrees with Jacek

Resolution: Jaceks proposal was accepted

lc75/lc88

<mnot> Jonathan's proposal with disclaimer text: [[[

<mnot> "The value of [message id] uniquely identifies the message. When

<mnot> present, it is the responsibility of the sender to insure that each

<mnot> message is uniquely identified. The behavior of a receiver when

<mnot> receiving a message that contains the same [message id] as a previously

<mnot> received message is undefined. No specific algorithm for the generation

<mnot> of unique values of [message id] is given, however methods such as the

<mnot> use of an IRI that exists within a domain owned by the sender combined

<mnot> with a sequence number satisfies the uniqueness criteria but may not be

<mnot> the best practice from a security perspective."

<mnot> ]]]

<uyalcina> +1 to remove it as well

jeff: why should we have the text about No specific algorthe last sentencehm... ?

bob: during f2f we discussed algorithms
... it is just as an example

<mnot> [[["The value of [message id] uniquely identifies the message. When

<mnot> <mnot> present, it is the responsibility of the sender to insure that each

<mnot> <mnot> message is uniquely identified. The behavior of a receiver when

<mnot> <mnot> receiving a message that contains the same [message id] as a previously

<mnot> <mnot> received message is undefined.]]]

jeff: suggests to change from "undefined" to "undefined by the specification"

<steve_winkler> That's fine with me.

LC90

Resolution: The adjusted text was accepted as resolution. Undefined was changed to undefined by the spec

marsh: Do we need to say something at all?

<uyalcina> +1 to Jeff

??: Wasnt this text added as a resolution to another issue?

paco: wants a week to think about it

mnot: We will put it on the agenda for next week

lc101

anish: we should address lc104 first

LC104

anish: My preferred solution was to get rid of the abstract model

marsh: Some properties are not relevant in the abstract model

anish: What is the value of having the abstract model when we have the infoset?

mnot: We have had a formal vote on the abstract model

anish: New information is that it is not clear where things go in the abstract model

mnot: Yes we still need to deal with LC104

<dorchard> anish, I share your consternation with the abstract model. It's the same that BEA has with WSDL 2.0

anish: We can either get rid of the model or add text on how things are mapped to the abstract model

<Marsh> +1 to close

gudge: drop it

paco: yes, close with no action

anish: I can try to come up with a proposal, but I prefer to get rid of the abstract model

<mnot> ACTION: Anish to start discussion on how extensions map into a specific bucket for lc104 [recorded in http://www.w3.org/2005/06/20-ws-addr-minutes.html#action01]

LC101

glen: Why should we describe how to extend

anish: I want a common way for extension to support tools

umit: We should clarify with some text

<mnot1> ACTION: Umit to write proposal that describes abstract EPR extensibility for LC101 [recorded in http://www.w3.org/2005/06/20-ws-addr-minutes.html#action02]

LC69/LC108

mnot: Can someone write down a new proposal for i50 and also for lc69/108?

i050

<mnot1> Proposal: This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is "http://www.w3.org/@@@@/@@/addressing/role/anonymous".

<Marsh> property is -> property is an endpoint with an [address] of

marc: Wasnt there a proposal to fall back to wsa:From first?

<marc> comment above was me

paco: If i send a oneway message I dont want to listen to the backchannel

dorchard: Why do you choose a MEP with result, if you want true oneway?
... There is no way the sender can perclude a fault to be sent back
... The sender must have some way to check for faults, if it is interested

umit: What about the case when you are composing addressing with WSDL or BPEL?

paco: Im ok with status quo

<Paco> +1

<vikas> +1

<bob> +1

<Katy> +1

<mlpeel> +1

<MSEder> Can

<Nilo> +1

<marc> +1

<GlenD> +0

<uyalcina> +1 can live with

mnot: Who can live with status quo?

<hugo> Can live with

<dhull> +0

<marc> +=0 ?

<TonyR> +0.2

mnot: Who can not live with status quo?

<dhull> +1 to SAP

<GlenD> +1

<dhull> +0.5

<hugo> +1

<marc> +1

<bob> +1

<TRutt> can live with

<mlpeel> +1

<TonyR> +0.6

<Nilo> +1

<GlenD> (would add appropriate defaulting / faultTo stuff)

<marc> would also like t explore defaulting to wsa:From

<mnot1> ACTION: Katy to write up explicit "not allowed" URI proposal for i050 [recorded in http://www.w3.org/2005/06/20-ws-addr-minutes.html#action03]

LC20

<GlenD> +1

<TonyR> +1.6

dhull: I really dont like the current status

<MSEder> I would like to open a LC issue what is a Red Herring?

<marc> can we say protocol binding rather than transport

<GlenD> I agree substantially with David

<TRutt> +1 on protocol binding specific

<GlenD> "underlying protocol"

<TonyR> + 3.14 to protocol

<GlenD> ...that's not SOAP specific

<bob> protocol is very overloaded

dhull: Can we say specifically that anonymous means to use the underlying transport?
... also that it means to return to sender

<mnot1> ACTION: David Hull to write up proposal for LC20 [recorded in http://www.w3.org/2005/06/20-ws-addr-minutes.html#action04]

<mnot1> ACTION 4 = David Hull to write up proposal WRT "return to sender" semantics for anonymous for LC20

LC103

<mnot1> http://www.w3.org/mid/1191ECEA-0CEB-47B0-B915-BA21B2F8D196@Sun.COM

<mnot1> [[[Issue lc103 concerns the use of 'request' and 'response' in the description of message addressing properties. In line with the resolution to issue lc84 and the discussion of lc107, I propose that we replace the use of 'request' and 'response' with 'message' and 'reply'. This will avoid any confusion with the request-response MEP(s) defined elsewhere and make it clear that the text applies equally to composing a reply to a message received via

<mnot1> ]]]

<mnot1> via a 'one-way' MEP as it does to composing a reply to the first message of a request-response MEP.

dhull: I think that we should explicitly say where the text in 3.3 applies

<mnot1> ACTION: Anish to review Core section 3.3 to see if LC103 is still a problem [recorded in http://www.w3.org/2005/06/20-ws-addr-minutes.html#action05]

lc107

<mnot1> http://www.w3.org/mid/OFEC611FCB.8E34C4A2-ON8525700A.000C2A6E-8525700A.0014723F@us.ibm.com

paco: we should be more clear that this is not request-reply

Resolution: We should improve the terminology

<uyalcina> adios

- DRAFT -

Web Services Addressing WG Teleconference

20 Jun 2005

Attendees

Contents