RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice

I always figured it would depend on the sender of the message to decide 
that - in this case the service.  If a service accepts an extension on the 
request there may or may not be any semantic difference (or extension 
element) on the response. And since the extensibility section of each spec 
already mentions that mU headers should be used to ensure that the 
receiver understands extensions [1], and this is stated w/o regard to the 
message being a request or response, I would think we should already be 
covered.  no?

[1] Senders MAY indicate the presence of an extension that has to be 
understood through the use of a corresponding SOAP Header with a 
soap:mustUnderstand attribute with the value "1". 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
04/06/2009 11:31 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
Bob Freund <bob.freund@hitachisoftware.com>, 
"david.Snelling@UK.Fujitsu.com" <david.Snelling@UK.Fujitsu.com>, 
"member-ws-resource-access@w3.org" <member-ws-resource-access@w3.org>, 
"member-ws-resource-access-request@w3.org" 
<member-ws-resource-access-request@w3.org>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
"public-ws-resource-access-request@w3.org" 
<public-ws-resource-access-request@w3.org>
Subject
RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice






One another point. I noticed this sentence [1] in the latest draft of the 
specification http://www.w3.org/2002/ws/ra/edcopies/wst.html. Should we 
add this statement to the section 
http://www.w3.org/2002/ws/ra/edcopies/wst.html#extensions? 
 
[1] ?Since the response may not be sent to the original sender, extension 
specifications should consider adding a corresponding SOAP header value in 
the response to signal to the receiver that the extension is being used.?
 
From: Ram Jeyaraman 
Sent: Monday, April 06, 2009 4:23 PM
To: 'Doug Davis'
Cc: Bob Freund; david.Snelling@UK.Fujitsu.com; 
member-ws-resource-access@w3.org; 
member-ws-resource-access-request@w3.org; 
public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: RE: [Bug 6730] Transfer: Redundant SOAP Processing Advice
 
Thanks Doug,
 
Your suggested changes look good to me!
 
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Sunday, April 05, 2009 6:34 PM
To: Ram Jeyaraman
Cc: Bob Freund; david.Snelling@UK.Fujitsu.com; 
member-ws-resource-access@w3.org; 
member-ws-resource-access-request@w3.org; 
public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: Re: [Bug 6730] Transfer: Redundant SOAP Processing Advice
 

Ram wrote: 
...
> 1. Section 3.1
> 
> The sentence
> 
> "Implementations may respond with a fault message using the standard
> fault codes
> defined in WS-Addressing (e.g., wsa:ActionNotSupported). Other 
> components of the outline above are not further constrained by this 
> specification."
> 
> should not be removed.

Why? This really doesn't say anything other than "Hey, you may fault 
for some reason". Isn't this true of all message in all WS-* specs? 
Why does this need it? 

> 2. Section 3.2 
> 
> The sentence
> 
> "In addition to the standard fault codes defined in WS-Addressing, 
> implementations MAY use the fault code wst:InvalidRepresentation if 
> the presented representation is invalid for the target resource. See
> 5 Faults. Other components of the outline above are not further 
> constrained by this
> specification." 
> 
> should not be removed.

I agree that the part about InvalidRepresentation probably should 
remain but I think the WSA part can be dropped since, like above, 
that just normal stuff.  So, how about just: 

Implementations MAY use the fault code wst:InvalidRepresentation if 
the presented representation is invalid for the target resource. See 
5 Faults. Other components of the outline above are not further 
constrained by this specification. 

> In addition to Dave's proposal plus the suggested changes above, I 
> suggest the following:
> 
> 1. A few paragraphs in section 3.3 (Delete) need to be removed:
> 
> "Extension specifications MAY define extensions to the Delete 
> request, enabled by OPTIONAL header values, which 
> specifically control preconditions for the Delete to succeed and 
> which may control the nature or format of the response. Since the 
> response may not be sent to the original sender, extension 
> specifications should consider 
> adding a corresponding SOAP header value in the response to signal 
> to the receiver that the extension is being 
> used."
> 
> "Specifications which define extensions for use in the original 
> Delete request which control the format of the 
> response MUST allow processing the Delete message without such 
extensions."

+1 

> 2. A few paragraphs in section 4.1 (Create) need to be removed:
> 
> "Extensions specifications MAY also define extensions to the 
> original Create request, enabled by OPTIONAL SOAP 
> headers, which constrain the nature of the response, as discussed in
> remarks on the CreateResponse below.Similarly, 
> they may require headers which control the interpretation of the 
> wst:Create as part of the resource creation 
> process."
> 
> "Such specifications MUST also allow processing the Create message 
> without such extensions."
> 

+1 

-Doug