See also: IRC log
No corrections to minutes; no objections to approving minutes of June 20.
<mnot> Request: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0104.html
<mnot> Anish's Response: http://www.w3.org/mid/42B8A1F0.9070407@oracle.com
<mnot> "The Addressing Working Group does not have additional requirements for the deliverables mentioned, but may have additional requirements for other, related deliverables in the near future. The WG believes that XMLP should commence development of the one-way MEP and binding, as the additional requirements are likely to be orthogonal to the delivery of them."
Discussion of whether the requirements to XMLP were clear enough and whether possible future requirements would indeed be orthogonal.
lc90: Paco: this is a valid way of doing things and we should close with no action.
dhull: we all agree we need a nonce to prevent replay attacks.
dhull and paco discussed what the spec was actually saying about using MessageId to determine uniqueness.
dhull doesn't like messageID + timestamp as a nonce; he would like the sentence recast to eliminate ambiguity
<mnot> chad, option 2: close the issue with no action
<Marsh-backup> Add "In this case, " to the start of the 2nd sentence
<pauld> chad, list options
Proposal: add "In this case" to the start of the 2nd sentence; no objections
RESOLUTION: Close lc90 by adding "In this case," to the beginning of the second sentence in the existing paragraph.
<Zakim> dorchard, you wanted to ask about "understanding"
Jonathan, after consulting internally, thinks this a big design change -- too big for the time we have
GlenD: I don't think we have to go as far as Jonathan is worried we'd have to. We could leave the portion about including WSDL rather fuzzy -- but mandatory.
Anish: agrees this is not time-consuming and would be a good thing to put in the spec.
mnot: a previous issue covered this point; do we really need to re-open this?
<dorchard> BEA has changed it's mind on this issue.
<GlenD> +1 reopen
<TonyR> happy to leave un-re-opened
<RebeccaB> +1 reopen
<dorchard> +1 to reopen after more discussion with my various eng teams
<Marsh-backup> Stay out of the trout pond - keep it closed.
<dhull> +1
Poll: should we re-open the issue about adding mustUnderstand
<anish> +1 reopen
<TomRutt> reopen issue
<pauld> please, no
<jeffm> yes
<TomRutt> +1 reopen
<vinoski> +1 reopen
<jeffm> +1 reopen
<Paco> -1
<pauld> -1
<bob> -1
<TonyR> -1
-1: leave it closed
<Marsh-backup> -1!
<Katy> 0
<GlenD> Alas, this will entail moving forward with a formal objection. :(
mnot: we had a clear direction on this before and it's contentious, so we should leave it closed.
<Marsh-backup> Gudge says "file -1 for me too"
<TomRutt> on LC 68 : the unclarity semantics of "extensibility" of epr, lead me to want to reconsider the use of a mustUnderstand on an EPR extension
<scribe> ACTION: Jonathan will write Jacek and explain why mustUnderstand will not be added to EPRs [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]
RESOLUTION: Closed with no action.
<mnot> Some transport bindings, notably SOAP/HTTP, provide a means of returning a message directly to the sender of that message, regardless of its contents. To allow for direct use of such a facility, WS-Addressing defines the URI "http://www.w3.org/@@@@/@@/addressing/sender" to indicate that the destination is the sender: This URI MAY be used as the [address] of the [reply endpoint] and/or [fault endpoint] addressing property, but SHOULD NOT be so used if the transpor
<mnot> n not to provide a return facility.
Jonathan: dhull's proposal seems to go beyond the original meaning
dhull: if there are other cases, we should handle them separately
Jonathan will do more research; issue goes back to the list.
Anish didn't get to this
Remains pending
Anish doesn't think there's an issue(s) here any more; recommends closing with no action
Can we close lc103 with no action? No objections
RESOLUTION: Closed with no action.
<mnot> http://www.w3.org/mid/OFEC611FCB.8E34C4A2-ON8525700A.000C2A6E-8525700A.0014723F@us.ibm.com
<mnot> http://www.w3.org/mid/1191ECEA-0CEB-47B0-B915-BA21B2F8D196@Sun.COM
Marc proposed using "message" and "reply"; this would not change Anish's stance on lc103
dhull: "reply" seems confusing because of "ReplyTo" and "FaultTo"
... "response" seems preferable, but explanation in text is acceptable.
No one objects to Marc's proposal
RESOLUTION: Use "Message" and "Reply" instead of "Request" and "Response", with a qualification of the scope of "Reply"
<mnot> ACTION: Jonathan to communication resolution of lc107 back to WSDL WG [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]
<mnot> http://www.w3.org/mid/OF327F07CB.D3861A9C-ON8025702D.005C5BD8-8025702D.005E3A7C@uk.ibm.com
Katy: runs through proposal for a "no reply" URI that can be used in replyTo EPRs
... alternately, we might define a "not valid" EPR for use with reply, fault, or source endpoints.
TomRutt: is this at the sender's discretion or would it be required at all? Katy: NoReply is a runtime decision
Paco: this is just a different way of expressing things, like omitting an endpoint; it may be a good compromise proposal.
<TomRutt> I wuld like to clarify that I could accept the IBM proposal if it was left to the client whether it is used or not.
Katy: this allows a default of the anonymous URI for omitted endpoints
dhull: is this aimed at the request/response or the one-way case? Katy: both
Paco: replies are not limited to the WSDL MEPs, so one-ways may come in answer to one-ways
TomRutt: would like to see this taken to the email list because of the lengthy discussion
<Zakim> dhull, you wanted to ask what part of WSA is affected by the one-way semantics
dhull: is this all in the context of section 3.3 or is more general? Katy: this affects the re-opened i50, so I think it affects only the section about formulating a reply.
<mnot> http://www.w3.org/mid/646CD56A-3711-44EB-8EDA-44257F15349E@Sun.COM
Jonathan: we had some concerns about a security section having SHOULDs: security are advice, not normative
<dhull> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
mnot: that may be true in the IETF, but it may not be the case for the W3C
Jonathan: otherwise we support Marc's proposed text.
<Marsh> Believe SHOULD vs. should is pretty much editorial...
Paco: still looking for feedback.
mnot: if there's no feedback by the next meeting, we'll re-open i4 and approve this text.
<hugo> http://www.w3.org/mid/42B71FBA.5060804@tibco.com
<mnot> ACTION: David Hull to continutally refine lc76 proposal to reflect other changes; make into spec text [recorded in http://www.w3.org/2005/06/27-ws-addr-irc]
mnot: adding subcodes does not seem like a substantial change (this in response to a concern that changing this section exposes WSA to another Last call
mnot: should we leave it in without comment, leave it with test cases, or identify it as "at risk"
<Zakim> dhull, you wanted to point out this may mesh with "return to sender" rule.
mnot: marking it as a feature at risk leaves our options open; we'll revisit this after the other issues are closed.