- From: David Hull <dmh@tibco.com>
- Date: Thu, 14 Jul 2005 23:42:55 -0400
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: David Orchard <dorchard@bea.com>, Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
- Message-id: <42D730BF.1010202@tibco.com>
Martin Gudgin wrote:
> I thought it was clear too. And it fits with the SOAP processing model
> and so works for endpoints which were deployed long before WS-A was a
> twinkle in the eye of it's multiple parents...
>
It's clear that if someone hands me a message with a wsa: header with
mU=true, and I know nothing about WSA, I fault.
I /thought/ it was also clear we're not talking about that case.
The main question is, what if someone hands me a message with (say)
wsa:ReplyTo, mU set however you like, but no wsa:Action (or a second
wsa:ReplyTo, or whatever other cardinality violation you like), and I
/do/ understand WSA.
Granted, if mU is true we may be on somewhat firmer ground, as the
receiver is then obligated to process the wsa:ReplyTo, and this could be
taken to bring in the rest of WSA by reference. I'm not convinced that
the processing model imposes this sort of processing requirement across
header blocks per se (and I rather hope it doesn't), but I'm 100%
convinced that a co-editor of SOAP 1.2 knows more about SOAP than I do.
In any case, if this is the behavior we want, we might want to sharpen
the language in the SOAP binding to say explicitly that, for purposes of
the SOAP processing model, processing any header also entails checking
the cardinality of the other header blocks.
If the wsa:ReplyTo doesn't have mU true, then I agree (or at least I
hope I'm agreeing) that the SOAP processing model provides no guidance
here. My understanding, though, was that we wanted the faulting
behavior in that case too. If so, it seems to be up to us to state that
explicitly, whether in the core, in the SOAP binding, or in the context
of the WSDL binding. Wherever we say it, we have to say it about the
SOAP infoset, not the abstract MAPs, since at the MAP level we can't
tell if wsa:ReplyTo (or wsa:To) was present or not.
Right now, the main thing that's clear to me is that the seemingly
simple question of when a WSA compliant processor throws faults for
cardinality violations (a.k.a. "When is WSA engaged?" or "When is WSA
validation required?") does not have an obvious answer. So far we've seen:
* When wsa:Action is present
* When any wsa: header is present
* When any wsa: header is present with mU true, and maybe other
times too.
Interestingly, each of these has been put forth as being perfectly
straightforward and obvious.
If any of these (or some other answer) is a clear consequence of the
current core/SOAP binding together with the SOAP processing model, I
should like to see a clear and explicit demonstration of the reasoning
so that we can capture it once and for all. If there is no clear
answer, I should like some assurance that either we will tighten up
core/SOAP or (my current guess) we will be able to settle the matter in
the WSDL binding.
As it is, I can hear WS-I warming up in the background.
> Gudge
>
> ------------------------------------------------------------------------
> *From:* David Orchard [mailto:dorchard@bea.com]
> *Sent:* 14 July 2005 22:32
> *To:* David Hull; Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* RE: LC 76 - What makes a msg WS-A?
>
> I thought it was clear. As soon as a single ws-a header is marked
> with mU, then a fault will be thrown if there are any missing
> headers like Action. If there are no headers marked with mU and
> there are missing headers, then it's up to the receiver to decide
> whether to throw a fault or ignore all the ws-a headers.
>
>
>
> Dave
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* Thursday, July 14, 2005 2:25 PM
> *To:* Martin Gudgin
> *Cc:* David Orchard; Katy Warr; public-ws-addressing@w3.org
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>
>
> Martin Gudgin wrote:
>
> +1
>
> Am I correct in reading that as "we should throw a fault if there
> is a wsa:ReplyTo but no wsa:Action" and we're back on the same
> page? I hope so, but when you say things like "I don't see why we
> want to mandate a fault in such a case." it seems like you're
> saying that we shouldn't (or at least shouldn't feel obliged to)
> throw a fault in such cases.
>
> Perhaps you could enumerate with which combinations of headers a
> WSA-compliant endpoint should and should not produce a fault? We
> can then check that against the rules in section 3 and know
> whether we need to have any further discussion.
>
>
>
> Gudge
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Orchard [mailto:dorchard@bea.com]
> *Sent:* 14 July 2005 22:03
> *To:* David Hull; Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* RE: LC 76 - What makes a msg WS-A?
>
> It seems to me that you can't pick and choose which headers to
> support. If there are any insufficient ws-a information (like
> contains a replyTo but no Action) then none of the ws-a
> processing can be invoked. It's not a smorgasborg.
>
>
>
> Dave
>
>
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org
> <mailto:public-ws-addressing-request@w3.org>
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of
> *David Hull
> *Sent:* Thursday, July 14, 2005 1:41 PM
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>
>
> Martin Gudgin wrote:
>
> I agree with your analysis of the three steps. I don't see why
> we want to mandate a fault in such a case. The client gets to
> decide whether he wants a fault or not based on whether he
> marks the header mU='true' or not...
>
> What would happen to the [reply endpoint] in this case (or
> rather, these cases, as mU may be true or not)? Would it be
> used as a reply address? Would it be silently ignored?
> Something else?
>
> In the first case, it seems strange to follow WSA rules but
> not complain about a missing mandatory header. In the second
> case, it seems less than robust to silently ignore a field
> that would otherwise have a significant effect on processing.
>
> Not sure about the third case.
>
>
>
>
> Gudge
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* 14 July 2005 21:21
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> Martin Gudgin wrote:
>
> Well, one could argue that the endpoint that accepts WS-A
> messages and the one that accepts non-WS-A message are not
> actually the same endpoint despite the fact that they're
> listening on the same URI, I suppose...
>
> Sure, but the multiplexing still has to be done one way or
> another.
>
>
>
>
> I'm still not seeing why the endpoint can't use the
> following sequence of steps;
>
>
>
> 1. Does the message contain a wsa:Action header?
>
> 2. If the answer to question 1. is 'Yes' then look for
> other wsa: * headers and populate abstract properties as
> appropriate.
>
> 3. If the answer to question 1 is 'No' then process the
> message using normal SOAP rules (including raising mU
> faults if there are any other wsa:* headers marked mU='true' )
>
> That will not produce a fault if a message contains an
> explicit wsa:ReplyTo (with no mU) but no wsa:Action,
> right? The test in step 1 fails and we go straight to
> step 3. So it's OK iff we don't want a fault in such a
> case. My understanding is we /do/ want a fault in such a
> case.
>
>
>
>
> Gudge
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* 14 July 2005 20:58
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> Martin Gudgin wrote:
>
> Why is it a problem if a message which doesn't have
> wsa:Action in it is NOT subject to 'validation' (what
> does that mean, BTW) by the receiver?
>
> Yeah, I'm not comfortable with the terminology either.
>
> The question is, should a WSA compliant /endpoint/
> throw a fault if it gets a message with (say) a [reply
> endpoint] and no [action]?
>
> If I understand right, you're saying that
> (straightforwardly), it should. That's certainly how
> I'd interpret the current core.
>
> Section 3 (specifically section 3.1) says that
> [action] is required (i.e., its cardinality is
> (1..1)), so the only question (and the one I think
> Katy was asking) is, when does section 3 apply?
>
> There appears to be consensus that endpoints should be
> able to accept both old-style and new-style requests
> without problem. This means that such an endpoint
> must be prepared to accept messages with no wsa:
> headers at all -- contrary to as strict reading of
> section 3. In particular, such an endpoint should
> /not/ fault if wsa:Action is absent unless other wsa:
> headers are present. In such a case, section 3 does
> not apply universally, and we want to be able to say
> when it does and doesn't apply.
>
> So what's the best way to say this? We can't use
> abstract properties, since they may be defined even if
> there are no wsa: headers in the incoming message. So
> we have to look at the incoming infoset. In short, an
> endpoint capable of handling both styles should apply
> the constraints in section 3 if the incoming SOAP
> message contains any wsa: headers, and should follow
> the pre-WSA behavior otherwise. This is fine as long
> as the underlying transport binding doesn't synthesize
> wsa: headers that aren't explicitly there. Otherwise,
> we'd need some other way of figuring out if the sender
> meant to use WSA.
>
> Does that make more sense? I believe this is a
> long-standing and thoroughly discussed issue. If you
> were thinking of something else, let's sort that out
> first.
>
>
>
> Gudge
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* 14 July 2005 20:29
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> Martin Gudgin wrote:
>
> OK, I'm confused.
>
>
>
> Why do you conclude that the answer to my question
> "Given that the wsa:Action header is mandatory,
> isn't it the presence of that header?" is 'No'.
>
>
>
> I would have come to the opposite conclusion;
>
>
>
> I have an endpoint that understands WS-Addressing.
> It receives a message that contains wsa:ReplyTo
> but no wsa:Action. It generates a fault. Seems
> pretty straightforward to me.
>
> Sure. That is a perfectly straightforward rule.
> In fact, it's implied by what we say in section 3.3.
>
> I thought you were trying to answer the question
> "When is an incoming message deemed to be a
> WS-Addressing message and therefore subject to the
> appropriate WS-Addressing validation?" with
> (rephrasing the reply as a statement) "It's
> subject to WSA validation if the wsa:Action header
> is present." And of course, this clearly won't
> work, since it specifically doesn't try to
> validate a message with wsa:ReplyTo and no wsa:Action.
>
> If you meant something else, then never mind.
> It's probably not worth sorting.
>
>
>
>
> I have an endpoint that doesn't understand
> WS-Addressing. It receives a message that contains
> one or more wsa: headers, it either ignores them
> or generates a mustUnderstand fault depending on
> whether those headers are marked
> mustUnderstand='true' or not. Again, seems pretty
> straightforward to me.
>
> Sure. As I said, we're talking about behavior of
> endpoints, not properties of messages.
>
> As DaveO says, the interesting case is that of an
> endpoint that wants to accept non-WSA messages
> without complaint but also handle WSA messages
> properly.
>
>
>
>
> Gudge
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* 14 July 2005 18:02
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> Martin Gudgin wrote:
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* 14 July 2005 16:32
> *To:* Martin Gudgin
> *Cc:* Katy Warr;
> public-ws-addressing@w3.org
> <mailto:public-ws-addressing@w3.org>
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> Is this really a question of how to
> support both WSA and old-style HTTP
> requests on the same endpoint?
> [MJG] I don't know, I didn't ask the
> original question.
>
> Hmm ... my message was in-reply-to yours, but
> the question was really aimed more at Katy.
> Maybe we need BPEL here :-).
>
>
>
> I.e., if I don't see any WSA headers at
> all, I assume it's an old-style request
> and act accordingly, but if I see anything
> WSA, I follow the rules in section 3?
> [MJG] I guess one could do that...
>
> Well, one should do /something/ to ensure that
> old-style requests are accepted as such.
>
>
>
> The tricky bit is that, since MAPs like
> [destination] and [reply endpoint] can
> default, a message with no wsa: elements
> on the wire could still be assigned values
> for some of its MAPs, since the /infoset/
> will still have values for the
> corresponding elements.
>
> [MJG] Which Infoset are you talking about?
> The XML Infoset has no such values.
>
> Sorry, I didn't get that quite right. I was
> going by section 3.2, particularly the
> descriptions of wsa:To:
>
> This OPTIONAL element (whose content is of
> type xs:anyURI) provides the value for the
> [destination] property. If this element is NOT
> present then the value of the [destination]
> property is
> "http://www.w3.org/@@@@/@@/addressing/anonymous"
> <http://www.w3.org/@@@@/@@/addressing/anonymous>.
>
>
> (and similarly for wsa:ReplyTo). I initially
> misread this as stating that the element
> defaulted, as opposed to the MAP. So s/since
> the /infoset/ will still have values for the
> corresponding elements/since the properties
> are defaulted in the absence of the
> corresponding elements in the infoset/. This
> sort of confusion could be seen as an argument
> against the two-layered approach (or simply as
> an argument that I read too quickly).
>
> In any case, you can't simply look at the
> abstract properties and say "some WSA
> properties are defined, so it's a WSA message".
>
>
>
> So either we have to drop down to look
> at the infoset level, and in particular at
> the non-defaulted elements in the infoset,
> or we have to find some marker that can't
> be defaulted away. This is why the
> [action] property looks significant here.
> But on the other hand, what if I include a
> wsa:ReplyTo element and no action? By the
> "it's WSA iff [action] is present" rule,
> that's not a WSA message and therefore not
> an error. This seems wrong.
> [MJG] Why does it seem wrong?
>
> It seems wrong not to fault for a message that
> contains a wsa:ReplyTo on the wire but not a
> wsa:Action.
>
>
>
> Put another way, when would one get a
> fault for omitting [action]?
> [MJG] Whenever another wsa: header is
> present in a message.
>
> In other words, the answer to your question
> ("Given that the wsa:Action is mandatory,
> isn't it the presence of that header?") is "No."
>
> This is why at the Berlin meeting we tried to
> make sure that all the possibilities were
> covered for various combinations of the MAPs.
> I believe we've satisfied ourselves that they
> are, but perhaps we need to revisit this work?
>
>
>
>
> Martin Gudgin wrote:
>
>> Given that the wsa:Action is mandatory,
>> isn't it the presence of that header?
>>
>>
>>
>> Gudge
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:*
>> public-ws-addressing-request@w3.org
>> <mailto:public-ws-addressing-request@w3.org>
>> [mailto:public-ws-addressing-request@w3.org]
>> *On Behalf Of *Katy Warr
>> *Sent:* 14 July 2005 16:07
>> *To:* public-ws-addressing@w3.org
>> <mailto:public-ws-addressing@w3.org>
>> *Subject:* LC 76 - What makes a msg WS-A?
>>
>>
>> Please could we discuss the following
>> in the context of LC76?
>>
>> When is an incoming message deemed to
>> be a WS-Addressing message and
>> therefore subject to the appropriate
>> WS-Addressing validation? Is it
>> based on the presence of any
>> WS-addressing Message Addressing
>> Property? For example, does a
>> message containing a reference
>> parameter (but no other WS-Addressing
>> information) need to result in a
>> MessageAddressingHeaderRequired?
>> Or, for example, does the
>> declaration of the wsa namespace
>> rendor the message WS-Addressing?
>>
>> Thanks
>> Katy
>>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Received on Friday, 15 July 2005 03:43:18 UTC