See also: IRC log
<scribe> scribe: Nilo
minutes approved
minutes of may 16, that is
lc 60, 65 to be done
lc106 done
the wsdl part will be taken to the wsdl wg
room size discussion
internet access on thu but not on fri; lunch will be provided
Mark considering cancelling monday jun 7 telcon; will decide at the f2f
anish: should these be message addressing properties?
comment 1: editors will do the right thing
comment 2: agreed
<bob> agreed
comment3: hugo? says that the propsed language is becoming very specific
it make it difficult to use eprs for anything other than invokeing web services
<TomRutt> OK with the nits present
call this editorial and leave it to the editors to use this proposal to clarify "consuming application"
comment 4: use pre-defined
comment 5: anish: is this for consistent formats for uri
jonathan: should be consistent but also short
mark: could flatten the uri space
marc: would change message id and anonymous
jonathan: alternative proposal - remove ../id/.. and call it unspecifiedID
marc: leave it to the editors to finetune
jonathan: unspecifiedId
accept comment 5 and give it to the editors to shorten the uris
comment6: marc: this is wrong as this uri is for adderssing faults and not a generic soap fault
comment 6: no change
comment 7: tom: seems like it would be a large list of things a sender would or wouldn't have to do
<uyalcina> +1 to tom.
comment 7: is there isn't some proposed text by the f2f, then close this item with no change
<mnot> ACTION: Nilo to provide example for comment 7 of lc89 by june 1st. [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action01]
lc91, comment 1: agreed
lc91, comment 2: agreed
lc91, comment 3: mark: we have some unresolved intermediary issues
jonathan: this isn't about intermediaries
glen: but it enables support for them
anish: just because role = next and relay=true doesn't mean that it is targeted at the ultimate receiver....
tom: is there a conformance test that can be done
<mnot> Current text: When sending a message each property is represented using the appropriate element information item as a SOAP header block. The resulting header blocks are targetted at the ultimate recipient in the SOAP message path (note that extensions to WS-Addressing could be written to specify different targetting). 3.4 Binding Message Addressing Properties describes additional processing required when binding message addressing properties to SOAP header blocks.
marc: the abstract description does not talk about targeting
we could add something to the abstract spec to talk of targeting
tom: could something nromative we could say to disallow certain types of targeting
marc: do we need to address that nothing in the sentence is normative
david: isn't it generally true of soap that the defaul targeting is the ultimate receiver
anish: we decided to allow multiple copies of the same headre targeted to different roles. so we allow targeting of headers
marc: you need an extension to show how you have multiple To:
mark: leave it for the intermediary discussion
<anish> +1 to relay
comment 4: marc: it should be relayed, not replayed
marc: this text is essentially the saop processing model
comment 4: replace "replayed" with "relayed"
comment 5: mark: have we done something here already?
comment 5: accepted
for lc89 and 91 we have deferred two comments. No need to send email to Nilo
jonathan gives some explanations
anish: if there is %escaping, nothing would change
jonathan: yes
lc105 accepted.
jacek is objecting to having action as mandatory
mark: see nothing new here; discussed these points during i031
tom: requirements on the sending application may state what the action uri should be
<anish> i agree with Jacek to make [action] optional, but i agree that this is an issue that has been already resolved
maybe the wsdl has some statements on how to put this
umit: jacek doesn't like this action uri; he ahd some problems in wsdl
tom: are there any constraints on the sender to put a particular value there? if the wsdl has a value, does the sender have to put that value there?
are we very clear on what the sender should do?
jonathan: don't have our conformance statements for wsdl done yet
mark: no new information; ack Jacek that we aren't going to change the spec
<uyalcina> +1 to tom :-)
mark will respond to jacek
<mnot> ACTION: mnot to write back to jacek on lc70; no new information [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action02]
anish: are these SOAP headers?
yes, a SOAP 1.1 header
anish explains how SOAP1.1's fault is signaled
jonathan: would like to defer this
editors find this quite straightforward; but this is deferred to next week
action to think through this and come back next week
anish takes the action
<mnot> ACTION: Anish to look into lc72 and report back by 2005-06-01 [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action03]
marc: agrees with this
jonathan: would like to see just [action] not the whole string
mark: need to clarify the template a bit, and then deal with the different languages
jonathan: might be the [detail] element which takes the value of the action property
mark suggests that jonathan work with the editors.
no one objects
<mnot> ACTION: Jonathan to work with editors to clarify templating language in soap faults. [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action04]
mark: the next issue is whther this is required or optional
anish: this is english language element
jonathan: should it always be english, or if it is english it should be "..."
jeff: just say natural language
<Marsh> "[Reason] The English language reason element."
jonathan: clarify that this is the text that should be used when the language is english
marc: the reason element is M in SOAP1.2
anish confirms that it is M in SOAp1.1
lc71 closed with no change to the optionality of the reason; some editorial cleanup will be done
katy will respond to author
david: every error condition should have its own error code
this is not meant to be a complete set
jonathan: should there be a unique error for every MUSt in the spec?
david: there should be some normatievly specified way to tell what happened
umit: it looks like you need a subcode of the first fault rather than separate faults
<anish> concern about subcode -- SOAP 1.1 does not have subcodes, so mapping to soap 1.1 would be problematic
tom: we seem to be getting into reliable messaging
<bob> +1
david: not religious about how this is realised; just want it to be unambiguously identified
jonathan: seems reasonable; but could be more than we need; may have to go through the whole spec and look at all the MUSTs
mark: can the editors do this?
jeff: as a group we should decide on the policy/concept
jonathan: would like a point by point changes from the editors as a result of this
marc would prefer someone else do it
david will try to produce a definitive list of conditions which generate a fault and what to do.
<mlpeel> +1 to umit
umit thinks this is a good idea; will need it during testing
<mnot> ACTION: David Hull to come back with detailed proposal, with effects on other parts of the spec, for LC76 [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action05]
jonathan: a conformant ep should act in conformance to the spec, but if you don't send any wsa headers our spec will be silent on the behavior
tom: in wsdl spec we will have
conformance statements, but we are talking about the core
here
... need some statement in the core
david: ;look in section 3.2 of core
tom: an epr aware client will use wsa headers, but you don't want the ep to use eprs necessarily
<uyalcina> haven't we covered this already?
umit: may have been covered when we discussed wsdl=required
david: if someone gives me an epr, sender is not required to use wsa headers
umit: wsdl is one particular policy, but there can be other policies taht can determine how you use that epr
david: nervous about the potential leeway allowed
tom: as long as the text allows it, he is OK with it. No need to list everything one can do.
david: concerned about the precision and clarity of the text
anish: why is this a concern? if you are not using ws-addr, this spec has nothing to say about it
david: there should be leeway for sender to use ws-a headers without understanding ws-a
jeff: the spec can't prohibit you from doing anything it doesn't talk about
tom: close it with a statement in the minutes that says this is allwoed
lc61 closed with no change and it is allowed
david: we should explicitly talk about message versus end point compliance
mark: we have a lot of conformance issues; we should leave it open until all are sorted out
lc62 deferred until next week
lc88 is related to it.
mark: surprised by lc88 that you can reuse message id for retransmission
tom: reliability has specific things to say about retransmission
mark: message ids have many uses
david: subtle issues involved; by making them unique in space and time takes a very definite position
tom: is there any issue on the optionality of message id?
yes
tom: keep them separate
david: this is up to the sender of the message and his deployment environment; cannot have the receiver do the uniqueness constraint
it should be up to users of the spec to decide how to use it
bob: concerned with language; a retransmitted message has a different id, but if it is part of a digest there is a cost
find the language problematic
david: differnt application intent relaxes the uniqueness requirment
he'd like to see a SHOULD; may be reaosns in a deployment not to be so strict
bob: primarily objects to the "and time" issue..why not just say "unique"
tom: need to say something here about retransmission
agrees with bob re time
has to be unique except for retransmission
david: that why SHOULD is preferable, because of retransmission
<mlpeel> Retransmission is (or should be) transparent to WS-Addressing
bonb volunteers to put a definition of uniqueness
<mnot> ACTION: bob to propose combined resolution of lc75 and lc88 [recorded in http://www.w3.org/2005/05/23-ws-addr-minutes.html#action06]
jeff: need the right level of abstraction, it isn't about retarnsmission of packets
meeting adjourned 6 pm est