See also: IRC log
<Marsh> Jonathan_Marsh holds PaulD
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
<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
<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.
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
??: Wasn't 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
anish: we should address lc104 first
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]
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]
mnot: Can someone write down a new proposal for i50 and also for lc69/108?
<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]
<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
<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 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]
<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