RE: LC 76 - What makes a msg WS-A?

Please correct me if inaccurate, but if
wsa:ReplyTo sent and wsa:Action omitted (assume all headers mU=false, then
the message is not a WS-A message.  Therefore, *if* the server chooses to
respond then it is not in the context of a WS-A message, i.e., wsa:Reply is
out-of-context in terms of WS-A.  The server's choice of endpoint to respond
to has nothing to do with WS-A in this case.

--
Matt Long
MV Squared Technologies
mlong@mvsquared.net
901-848-2640



--------- Original Message --------
From: "David Orchard" <dorchard@bea.com>
To: "David Hull" <dmh@tibco.com>, "Martin Gudgin" <mgudgin@microsoft.com>
Cc: "Katy Warr" <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
Date: 14/07/05 15:00


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] On Behalf Of David Hull
Sent: Thursday, July 14, 2005 1:41 PM
To: Martin Gudgin
Cc: Katy Warr; 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
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
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
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
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
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".

(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] On Behalf Of Katy Warr
Sent: 14 July 2005 16:07
To: 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







________________________________________________
Message sent using UebiMiau 2.7.2

Received on Thursday, 14 July 2005 21:23:35 UTC