See also: IRC log
<pauld> Scribe: dorchard
<pauld> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0092.html
No objections to agenda.
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
marc h: issue cr17 resolution
marc h: resolution accepted introduces some conflict in the spec
will add after cr 20 to agenda
<pauld> Scribe: pauld
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?
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
http://lists.w3.org/Archives/Public/public-ws-addressing-tests/2006Jan/0027.html
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