See also: IRC log
<swinkler> regrets for the second half of the call. I have to drop at 2.
mnot: register for Berlin F2F,
room limited to 20
... minutes April 19th, April 20th approved
mnot: dhull oulines his new issue on semantics of wsa:UsingAddressing@wsdl:Required="false"
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0061.html
s/mnot: dhull:/dhull: /
<anish> as a side-note there is an issue (in my mind) about what the default value of wsdl20:required is
<uyalcina> I have raised an issue on that one in WSDL 2.0 wg
marsh: baffled as the relevance to WSDL required='false', why do we need to define how wsdl:required works in our spec
dhull: advertising a service with wsdl:required changes the semantics of our spec
discussion between paco and dhull regarding the scope of this issue over other bindings
<Zakim> anish, you wanted to find out whether the issue is -- how the server knows that ws-addr is engaged. Or is it more?
tom: clarification of issue; the case we talking about is where a client isn't using addressing and doesn't send wsa:action.
paco: should be possible to tell at the xml level if wsa is engaged
anish: is the issue about how the server can detect addressing is engaged?
dhull: possible to have bindings which don't work that way (scribe having difficulty hearing)
anish: so a strange binding that doesn't have something in the message to indicate addressing is in play may need something above current WSDL language
mnot: concerned that the current wording of the issue doesn't capture the discussion
daveo: i'm confused
umit: what's the likelyhood of this happening?
dhull: cites intermediary use-case
<scribe> ACTION: dhull to restate the new issue regarding wsdl required='true' semantics [recorded in http://www.w3.org/2005/05/02-ws-addr-minutes.html#action01]
mnot: volunteer for owning new issue regarding namespace split across two documents
<scribe> ACTION: jmarsh to promote discussion in issue i60 [recorded in http://www.w3.org/2005/05/02-ws-addr-minutes.html#action02]
marsh: had an action to move this forward. still like my original formulation, but modified it folowing discussion related to 'endpoint conformance'. Does a conformant endpoint have to reject messages without wsa headers? Conformance only applies where wsa headers are in play.
mnot: messages on the list are still very fresh and many will not have seen them, so will time limit this discussion
anish: reformulation isn't what i had in mind. An endpoint should conform to the soap binding specification which doesn't define how and when to send fault or reply messages. these are defined by WSDL MEPs and our specification
marsh: spec doesn't define what is a request-response MEP. We don't need to nail that down as it's in the domain of other specs.
anish: MEP in play belongs in the soap binding specification
umit: unclear why this is a conformance for soap or core specs, rather wsdl section.
paco: request-reply may exist regardless of there being a WSDL description
anish: not necessary rules have to be defined in WSDL
paco: specs don't mandate a reply has to be sent, just how fields are used when on is sent
marsh: that captures my intent
dhull: core and soap are bound together. reads section 3 regarding MAPs as implying a fault / reply must be sent. compliance testing would test sending a response as an assertion
marsh: spec should not define case when we don't use addressing.
dhull: sending a message to a conformant endpoint without addressing should be faulted.
marsh: core specification isn't testable on its own, only when used inanother context, such as soap
dhull: sounds like we're in agreement, solicits if anyone agrees we need more precise text. don't think normative statements belong in the core.
marsh: agreed (conformance to the core is ill defined)
daveo: agrees conformance to the core is not well defined
paco: one option is to put soap
binding and core together in the same document
... conformance can only be proven if core is paired with a
binding. that's a well defined statement and may allow the core
to remain separate.
anish: agrees
marsh: had action to clarify
fault to be returned if wsa:action header differs from http
action in soap 1.1/1.2
... soap 1.1 has a required soapAction header (WS-I BP)
... proposal allows soapAction to be empty
anish: we should clarify empty means open-quotes, closed-quotes to match WS-I BP
marsh: do we have to define empty given it's possible for people to not be using the BP?
mnot: suggests using BP as an example
<uyalcina> +1 to Marc
marc: we should use this chance to nail text to match the BP
<Marsh> "The SOAPAction HTTP header is required when using the SOAP 1.1 HTTP binding. The value of the SOAPAction HTTP header MUST either be identical to the value of the wsa:Action header, or be empty. The latter case supports the ability to obscure the wsa:Action header through SOAP-level security mechanisms, without requiring otherwise unnecessary transport-level security. Failure to have an identical value, or an empty value for SOAPAction, results in the Invalid M
anish: does anyone want to be non-BP compliant (at least in this case)?
tonyR: seems like low cost to allow non-BP cases
marsh: works for me
<scribe> ACTION: approved lc26 with Jonathan's original proposal combined with his updated proposal [recorded in http://www.w3.org/2005/05/02-ws-addr-minutes.html#action03]
RESOLUTION: approved lc26 with Jonathan's original proposal combined with his updated proposal
<mnot> ... leaving out ""
<Marsh> http://www.w3.org/2002/ws/addr/lc-issues/#lc28
ACTION- 3
marsh: outlines proposal
... editorial guidelines: we should use [] refps notation
consistantly ; it should be clear that echoing headers is at
the XML representation, not infoset level
marc: may have already done some of this in the latest editors draft
paco: fine with this
mnot: suggests editors to work on this direction and WG to review
discussion between marsh and marc regarding use and structure of notation
anish: suggest dropping use of serialized regarding infoset. prefers 'mapped'
discussion of serialising IRIs .. going off piste ..
RESOLUTION: close issue lc28 with Jonathan's proposal and adding word 'infoset' where appropriate
marsh: outlines proposal for lc36
<mnot> http://www.w3.org/2002/ws/addr/lc-issues/#lc36
<anish> things would be so much easier and non-convoluted if we just get rid of abstract props and keep only the infoset stuff
<uyalcina> looks good to me,
RESOLUTION: closed LC36 with Jonathan's proposal
marsh: outlines proposal for duplicate headers at the ultimate recipient
tonyr: suggests dropping term 'ultimate recipient'
marsh: we still need to target a particular node
anish: how do we determin if it's targetted at a particular node (as opposed to a role?)
marc: that's the joy of
soap!
... you can't have more than one of these targetted at a node,
which is stricter and not deterministic from looking at the
message
anish: can have multiple 'To's if they are targetted at differnet nodes?
mnot: action item is regarding faults
marc: glen had a use-case for this
anish: recipient node has to decide which roles it is playing
umit: unconvinced why we ended up with node rather than role. why did we do this?
marsh: glen and marc convinced us!
marc: suggests only having one To header (at most) but doesn't satisfy Glen's use-case
anish: questions reason for using node rather than role
mnot: role is in the infoset [node isn't]
marc: raises case where a node is playing two roles with two To's
dhull: thinks this is put out of scope by our spec; we should just be talking about the ultimate receiver
marc: ultimate receiver [node] always plays at least two roles
umit: likes proposed solution with role rather than node
marsh: would welcome amendment, but wants to be consistant with soap
anish: discussion of Glen's (WS-Routing) use-case
dhull: thinks wording regarding targetted and ultimate receiver is correct
<mnot> http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A507609A91@RED-MSG-30.redmond.corp.microsoft.com
dhull: wants clarification
regarding multiple faults and errors
... fault coming back should clarify which role being played by
a node caused the error
marc: soap 1.2 has a role element
tonyr: thinks it's 'actor'
<anish> there is both a 'node' element and an 'role' element
dhull: we're trying to avoid opening discussion to cover intemediaries
<anish> http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#faultactorelement
<anish> http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#faultnodeelement
marc: thinks we've covered intemediary processing
vikas: ignoring that an intemediary may exist is the safest way of working on the Internet
<scribe> ACTION: marc to respond to Jonathan's proposal for lc34 [recorded in http://www.w3.org/2005/05/02-ws-addr-minutes.html#action04]