Web Services Addressing WG Teleconference

30 Jan 2006


See also: IRC log


Andreas Bjärlestam (ERICSSON)
Francisco Curbera (IBM Corporation)
Vikas Deolaliker (Sonoa Systems, Inc.)
Paul Downey (BT)
Robert Freund (Hitachi, Ltd.)
Arun Gupta (Sun Microsystems, Inc.)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
David Hull (TIBCO Software, Inc.)
Yin-Leng Husband (HP)
David Illsley (IBM Corporation)
Anish Karmarkar (Oracle Corporation)
Paul Knight (Nortel Networks)
Mark Little (JBoss Inc.)
Nilo Mitra (ERICSSON)
David Orchard (BEA Systems, Inc.)
Tony Rogers (Computer Associates)
Tom Rutt (Fujitsu Limited)
Mike Vernal (Microsoft Corporation)
Katy Warr (IBM Corporation)
Pete Wenzel (Sun Microsystems, Inc.)
Prasad Yendluri (webMethods, Inc.)
Abbie Barbir (Nortel Networks)
Dave Chappell (Sonic Software)
Eran Chinthaka (WSO2)
Glen Daniels (Sonic Software)
Jacques Durand (Fujitsu Limited)
Marc Goodner (Microsoft Corporation)
Philippe Le Hégaret (W3C)
Amelia Lewis (TIBCO Software, Inc.)
Bozhong Lin (IONA Technologies, Inc.)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Gilbert Pilz (BEA Systems, Inc.)
Davanum Srinivas (WSO2)
Jiri Tejkl (Systinet Inc.)
Steve Vinoski (IONA Technologies, Inc.)
Steve Winkler (SAP AG)
Ümit Yalç?nalp (SAP AG)
Mark Nottingham (Yahoo)
Bob Freund
David Orchard, Paul Downey




<pauld> Scribe: dorchard

<pauld> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0092.html

Agenda review

No objections to agenda.

Call for corrections to the minutes

Minutes of F2F accepted: http://www.w3.org/ws/addr/6/01/19-ws-addr-minutes.html; http://www.w3.org/ws/addr/6/01/20-ws-addr-minutes.html

ai review


marc h: issue cr17 resolution

marc h: resolution accepted introduces some conflict in the spec

will add after cr 20 to agenda

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/att-0055/soap11onewayhttpbinding.html

<pauld> Scribe: pauld

soap 11 binding

dorchard: walks through his two SOAP 1.1 proposals
... both are 'one-way' first had no envelope in the response which received some push-back
... both return status code 202
... optionalality has caused confusion - is it at the SOAP or the HTTP level?

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/att-0072/soap11reqoptresphttpbinding.html

dorchard: 202 allows SOAP envelope in the response or not is the difference between the proposals

marc: is the envelope in the 202 response a response in SOAP terms, but rather an RM-Ack-like protocol response

<bob> Links are to 1) the one way proposal, and 2) the request optional response proposal

dorchard: SOAP 1.1 (1.2 either?) purposly blurs the lines here - my perspective
... something on top defines the distinction

anish: same question as Marc, service respons with 202 is different with responding 200, in both cases an envelope comes back
... 200 means done processing

dorchard: i don't think that's what SOAP says

anish: talking about HTTP level
... 202 is non-commital - processing may or may not be complete
... if a 202 includes a RM or whatever response ..

dorchard: SOAP 1.1 in particular doesn't give us any terminology or anything to hang our hat on to describe this distinction

<Nilo> but does not HTTP's application layer semantics require that the response in a 200 OK be a response to the original request?

anish: SOAP 1.1 doesn't have an MEP ..

dorchard: discussion of terminology - exchange, MEP I deliberately avoid using these SOAP 1.2 terms

anish: two distinct cases 1) 202 no body, 2) 202 with a body

dorchard: understand why you might choose to see it that way, but I disagree

paco: the replyto of non-anonymous means reply isn't going to be returned in the HTTP response, which we indicate with 202. which is OK
... we need to describe how this exchange takes place, but I'm agnostic how

<dorchard> From soap 1.1 spec "SOAP HTTP follows the semantics of the HTTP Status codes for communicating status information in HTTP. For example, a 2xx status code indicates that the client's request including the SOAP component was successfully received, understood, and accepted etc."

<TRutt> +q

anish: renaming soap optional response to soap optional ack could be one way forward

marc: want to push on the impact on our specification, in particular section 3.4 and how to formulate a reply

dorchard: isn't that a separate issue?

marc: what is OK to send back, a bare RM envelope, or do I have to follow rules in the addressing spec

<TRutt> There is a big use case for a reply with a soap header only in the envelope

dorchard: I don't follow

+1 to Tom

dorchard: WG has purposely avoided binding to a transport in our SOAP binding document

marc: section 3.4 is very specific about creating a SOAP reply, wouldn't this envelope be covered by our document?
... seems like the proposal goes outside of what's allowed in section 3.4

paco: i think david is trying to layer away this kind of detail, and seems acceptable to me

marc: I need to understand where we're at

dorchard: use-case for the envelope is reliable messaging where the one-way message has been secured, but not processed

a header block which allowed a place for a intermediary to trigger if non-anonymous processing is allowed

<bob> zakim ack trutt

trutt: a header only response would meet most people's needs and allow the distinction

<Zakim> dhull, you wanted to strike "Any SOAP Envelope that is a response MUST be sent using a separate connection."

dhull: suggest striking "Any SOAP Envelope that is a response MUST be sent using a separate connection."

<dorchard> dorchard: would have liked to have a special defined header or attribute that provides a place for any spec that specifies a *To to indicate that it allows anon *To value. then intermediary has only one place to look and one dependency.

dhull: not helpful, and I don't think it adds anything, and may simplify the discussion

<TRutt> How about Request optional Soap Header Response?

<Zakim> anish, you wanted to mention a minor ed. concern about saying that '202' should be sent in case of success

anish: minor editorial suggestion: concerned about saying that '202' should be sent in case of success

dorchard: and a fault would come back on a 500?
... faults come back regardless of this binding
... this is additive to the existing SOAP 1.1 binding

tony: sending of a fault depends upon timing

<TonyR> tony: this is not so much a success response, as it is a non-failure acknowledgment

anish: wording of BP may be useful "upon successful outcome of a HTTP request"

dhull: /

dorchard: 1.1 allows sending back a response ; this binding enables sending back a response following a 202

discussion over meaning of 202 and existing SOAP 1.1 binding

dorchard: SOAP 1.1 doesn't distinguish who sent back the 202 response. in Addressing we say by definition you must use the SOAP 1.1 binding, but you may also chose to support this note

discussion spirals around the meaning of response .. document isn't stand-alone, it builds upon existing SOAP 1.1 binding

dhull: i find the sending of 202 with optional responses bothersome .. might just be wordsmithing

vikas: is there anyhing to reconnect a session?

dorchard: akin to 300 status codes, seems a little out of scope for this discussion

trutt: what we need to get back is a header, but what about a SOAP fault

paul: fault processing is governed by FaultTo, this is about ReplyTo being non-anonymous

marc: is this 202 with an envelope a reply message covered by the addressing specification, or not?

paco: would it help to have text to describe how this message exchange and the optional envelope relates to the addressing request-reply exchange? I think it might be helpful.

<dhull> Replace section 2 with: "In addition to the options provided by [SOAP 1.1], the HTTP [RFC 2616] response MAY also have a 202 status code. If so, the response body MAY be empty."

marc: do we need to add an opt-out clause to 3.4 to allow you to send another message ahead of the formulated reply?
... I think we need some very careful wordsmithing to pull apart these concepts (in core, soap and wsdl documents)
... to enable sending back an intermediate message without any addressing headers
... this seems like a separate message exchange outside of SOAP semantics

<dorchard> 10.2.3 202 Accepted

<dorchard> The request has been accepted for processing, but the processing has

<dorchard> not been completed. The request might or might not eventually be

<dorchard> acted upon, as it might be disallowed when processing actually takes

<dorchard> place. There is no facility for re-sending a status code from an

<dorchard> asynchronous operation such as this.

<dorchard> The 202 response is intentionally non-committal. Its purpose is to

<dorchard> allow a server to accept a request for some other process (perhaps a

<dorchard> batch-oriented process that is only run once per day) without

<dorchard> requiring that the user agent's connection to the server persist

<dorchard> until the process is completed. The entity returned with this

<dorchard> response SHOULD include an indication of the request's current status

<dorchard> and either a pointer to a status monitor or some estimate of when the

<dorchard> user can expect the request to be fulfilled.

anish: 202 is clear that SOAP message has been received, but not processed. Therefore any message sent back in 202 can't be the response

marc: worried about how this changes my current understanding of the SOAP processing model

<anish> dave -- if you don't like 'optional ack', can you suggest a better term. I'm quite open to a different term. As long as it does not use 'response' which is used by the 'soap request-response'

dhull: if i'm using anonymous address, i expect 200 with response; conversely if i don't get back a 200, or a fault e.g. 202 - that's not using anonymous response channel
... is that about right?

<dorchard> anish, I specifically like the term "response". It is most definitely a soap response

<marc> think we could make some clarifications in David's doc (section 2) to make it clear that the SOAP message in the HTTP response is not a SOAP response in the normally accepted sense.

<anish> dave, but how do you distinguish a 'response' sent with a 200 and a 'response' sent with 202. They are quite different.

<marc> i.e. normal SOAP processing rules do not apply, users should not expect mU processing etc

<anish> +1

dorchard: to send a SOAP envelope with a body and a response, you should send back a 200

dhull: interop danger that the RM Ack will be taken as the response

paco: how will that happen?

dull: split case, empty 202 could indicate the response or fault went elsewhere,

<TRutt> In WS-RX the ack to is out of band, it is pre negotiated on the sequence create request exchange

dorchard: someone could send back a 202 with a body and that would be the response, but we're talking envelopes not bodies ..

<TRutt> That is , there is no reply to or fault to for the ws-rx ack

<dhull> Paco, I'm not sure this particular case came up (but I may well have missed it)

<anish> at the f2f we decided on a one-way, which has not become request-optional-response on the ML

dorchard: object to the term "optional-ack"

<Zakim> dorchard, you wanted to object to "optional ack". Ack is a terrible term.

dorchard: my spec may allow 202 with a SOAP header, simply a kind of response, not necessarily an ack

<anish> request-optional-piggyback ? ;-)

trutt: it's a little more tricky as WS-RX may ack out of band
... will send mail on this

<dorchard> tom, you are absolutely right that ws-rx implies a "stateful" acksto, where the message itself isn't self-describing wrt soap response on current http connection.

<TRutt> s/ack out of bane/request for request for ack out of band ( in earlier create sequence exchange) (in earlier createSequence exchange)/

bob: you and anish have been working on wordsmithing in irc, seems to be of value. Can you undertake to tweek that?

dorchard: yes


<bob> http://www.w3.org/2002/ws/addr/cr-issues/#cr18

paul: issue is precise meaning of anonymous [destination] property, something we encountered during CR testing
... would like a clarification, possibly in the SOAP binding

dhull: may be binding specific

paul: at the moment we're ambigous and vendors have gone both ways
... Microsoft requires To to be specified for dispatch, and our spec allows that
... others default to the URI posted to, which is implicitly allowed

<anish> paul, i did not quite understand why u think a 'anon' URI for [destination] in a reply is ok. Is there place in the spec that you can point to, which says what it means?

<David_Illsley> From SOAP binding... 3.5... When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as the address of an EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint.

paco: related to CR20 about defaulting of To in a reply

<anish> right, we say what it means in the context of EPR not in the context of [destination]

<anish> which is a URI

paco: leaving things as they are, people to divine what anonymous means in various common cases is not helpful

marc: sees the two issues as being orthoganal

paco: it's about the meaning of anonymous, so I see them as being related

dhull: anywhere your binding defines the value of the immediate destination, that makes a sensible default value. We need to be constrained to something within the binding and the named SOAP property works
... anonymous destination means SOAP destination property
... [that's a proposal]

paco: are you saying that's limited to the HTTP binding?

<marc> the two things are orthogonal: this issue is about the meaning of an anon [destination] regardless of how that value arises in a message which can be via a default or explicit inclusion

dhull: it's SOAP, not HTTP specific

paco: may not work with other transports
... do you want to limit this to request-response?

dhull: no

marc: not sure that immediate destination is tied to request-response
... it has a meaning in response too

paco: we can't make a generic statement for all transports, we could break something

discussion around transports which might not provide an immediate destination

dhull: we could scope this to request-response

dull: in the case of proxies, anonymous may not be what you want to do

bob: lets take this to the list

trutt: i was originally thinking that a binding would provide the default, but interested in what the destination means

MikeV: sent an analysis to the testing mailing list


scribe: the spec is self consistant at the moment, and the meaning of anonymous is 'undefined'

MikeV: adding a defaulting mechanism would be adding a new feature

marc: how did this come up in the first place

paul: it's my fault!

marc: what's wrong with the status quo if the tests were at fault? unlikely to happen in the wild given how EPRs work

paul: would be happy if we explicitly stated 'anonymous to is undefined"

marc: we shouldn't preclude anonymous to given there may be use-cases such as two machines directly connected

anish: find the undefined problematic, but am puzzled what this means for response
... nowhere do we say that an anonymous destination means 'the back channel' even for the reply
... as it is, anonymmous for wsa:To is undefined for both request and response

trutt: it seems odd to but anonymous in To for an EPR. Are we using anonymous at runtime as an optimisation?
... will send another mail on this!

<anish> too many dragons in 'anonymous'

paco: anonymous doesn't always have meaning, not with all transports.
... I'm very weary about defaulting to property to anonymous. I'm not saying status quo is broken, just not very reasonable. Having to default to a meaningless value isn't useful.
... suggest we use a similar resolution to CR17
... doesn't make sense to treat optimisations on a per-transport baisis.

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0078

marc: defaults should be simple syntactic defaults, "no To means default is anonymous" regardless of context and state.

<anish> +1 to what marc said

marc: I'd rather have no defaults than context specific defaults

paco: usage of anonymous currently depends upon context, e.g. transport in use
... we're trading one problem for another

marc: defaulting stuff only should reply in syntactic situations. I agree anonymous depends upon transport, but that's really at another processing layer.
... common use cases deserve common defaulting mechanisms
... anonymous to on a HTTP response is the 99 case

trutt: inclined to disallowing anonymous to on a request

discussion of how draconiun proposals are ..

dhull: very dangerous to argue based upon the HTTP 'common' use-case as we want to go beyond that

<Zakim> anish, you wanted to say that it is a premature optimization (having a default)

anish: we're into premature optimisation when we talk about defaulting here. Validating addressing headers independent upon the context will be more complex with different defaults for request/response
... we could make the destination property optional

bob: let's work on this on the list, see you next monday

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006-02-02 00:49:03 $