W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

RE: Amended proposal for i059

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Mon, 19 Dec 2005 09:02:46 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D64165CC201E@uspale20.pal.sap.corp>
To: "David Hull" <dmh@tibco.com>
Cc: <public-ws-addressing@w3.org>
David, 
 
It is my impression that the wg has spent quite a long time hashing what
anonymous means and where it should go. The definition is now in the
SOAP binding document. Yes, it is a specific transport specific, but my
understanding is that it is the final position of the wg. I personally
do not want to reopen the discussion again with respect to its
definition. 
 
What is the new perspective/information that would lead us to do this? 
 
Perhaps this explains my position better. 
 
Thanks, 
 
--umit
 


________________________________

	From: David Hull [mailto:dmh@tibco.com] 
	Sent: Monday, Dec 19, 2005 8:49 AM
	To: Yalcinalp, Umit
	Cc: public-ws-addressing@w3.org
	Subject: Re: Amended proposal for i059
	
	
	Yalcinalp, Umit wrote: 

		David, 
		 
		We need to approach this from the perspective of problem
solving. 

	I'll bear that in mind.
	

		You seem to be changing the doc so that SOAP 1.1 and
SOAP 1.2 have equal footing.

	I don't that I'd put it that way.  Certainly the text falls out
differently for 1.1 and 1.2.  What I had meant to do was to pull out
text that applies to any version of SOAP(or possibly beyond the context
of SOAP; see below) and state it once instead of repeating it.  The full
structure is:
	

	1.	What are the rules for the WSDL markup (UsingAddressing,
Anonymous)?  This clearly has to go in the WSDL binding.  The WSDL
markup defines (among other things) when the anonymous endpoint is
allowed to occur in a response endpoint.  This is section 3.1, and
3.1.1, which I think is basically OK, modulo the changes regarding
response endpoints, which we seem to agree on.
		
	2.	What does the anonymous endpoint mean in general?  If
this goes beyond the scope of SOAP messages (e.g., SOAP request, binary
response, etc.), then this can't go in the SOAP binding.  This would be
the ideal place to set out the key idea of having anonymous tie the
inbound and outbound messages to a request response MEP, instead of
trying to define a "response channel" and just tie the individual
outbound message to it.  Though a purely technical point, it looks to
make the definitions considerably shorter and clearer.  Unfortunately,
the only places I know of where "request-response" is defined concretely
concretely are in HTTP and in the SOAP adjuncts.  This is where
introducing a transport-level MEP, independent of SOAP, could come in
handy (if anyone would like to advocate this, please jump in :-) 
	3.	What does the anonymous endpoint mean in the context of
SOAP, in general?  If we can say anything in general about SOAP, but not
beyond SOAP, it would go here.  My feeling is that we probably don't
need anything in this slot, though right now it currently holds the
material that would ideally go in slot 2  (section 3.1.2 in what I sent
out).  I agree that this and what follows is somewhat redundant with the
definition of anonymous in the SOAP binding.  Leaving potential process
issues aside, I lean toward taking the section (3.5) out of the SOAP
binding.  I don't believe it's concrete enough to be useful on its own.
To make it concrete enough to use, you have to talk about binding MEPs,
and that's not only necessary, but sufficient. 
	4.	What does anonymous mean for SOAP 1.1/HTTP and SOAP 1.2?
I believe what I put in 3.1.2.x is what belongs there.
		

		
		 
		(a) I like that you are more inclusive about response
endpoints and they should be extended to other response endpoints, to
cover acks to help other specifications. This is aligned with the CR
issue we result wrt the definition of anonymous in the SOAP binding. 
		 
		(b) I do not follow why we need yet another definition
of anonymous address here in Section 3.1.2. We already have the
definition which we tinkered with in the SOAP binding document. I really
can not follow what it adds in the WSDL document as stated.

	See above.
	

		
		 
		The last paragraph of this section, however, is in the
right direction. 
		 
		(c) You changed the slant by adding Section 3.1.2.1
which de-couples of the usage of the "Anonymous" marker and coupling it
with the usage of "anonymous" on the wire. 
		 
		I think first the wg has to decide whether the semantics
of the binding is with the extension and whether it is coupled with the
WSDL document as an extension or it is defined in the SOAP binding. 
		 
		This change presupposes that we actually move this
section to the SOAP binding document. If we were to do this, the writeup
would make more sense  as it talks about the behaviour from the
perspective of the presence of the anonymous addresses on the wire (to
be added to SOAP binding document) and then relating the semantics of
the markup <Anonymous> to constrain the behaviour (in WSDL binding
document), 
		 
		For example: 
		 
		{When the anonymous address is used, the outbound
message MUST be sent over the same HTTP connection as the inbound
message}. 
		 
		What does this usage apply to? What happens if the
Anonymous marker was "prohibited" in WSDL?

	This is an error condition.  A compliant processor that
advertises Anonymous "prohibited" will not send an application-level
message anonymously.  Stepping back a bit, there is a clean split
between whether an anonymous endpoint is used, which depends both on the
WSDL markup and the behavior of the sender, and what it means if it is
used.  There's no need to talk about the markup in the context of the
behavior.
	
	There is a separate issue of how we model the handling of the
SOAP fault that MUST be generated.  We'll have to deal both with SOAP's
generate/send distinction and probably WSDL's notion of "fault replaces
message" and "message triggers fault".  I think any problems in both
cases are basically to do with terminology.  However, dealing with this
has little to do with the Anonymous marker per se.  A "anonymous
prohibited" fault must be handled in the same way as a mustUnderstand
fault, or any other fault that occurs before WSA is engaged.
	

		
		 
		I really think that we should first answer the where the
SOAP binding extension goes before we go there... 
		 
		 
		Thanks, 
		 
		--umit
		 
		 
		 
		 
		 


________________________________

			From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
			Sent: Friday, Dec 16, 2005 2:23 PM
			To: public-ws-addressing@w3.org
			Subject: Amended proposal for i059
			
			
			In line with the discussion on Monday's call and
the email I just sent out, here is an amended version of the proposal
for UsingAddressing.  My additions and changes are shown in green.
Deleted text has been quietly omitted.  Points of interest:
			

			*	I have substituted "response endpoint"
for [reply endpoint] and wsa:replyTo, and defined "response endpoint" as
"[reply endpoint] or [fault endpoint] as the case may be". 
			*	I have tried to consistently use
"inbound message" for "request" and "outbound message" for response, in
line with WSDL use of "in" and "out" and in contrast to "request" and
"response" in the SOAP and HTTP context. 
			*	In combining my proposal with the
existing proposal, I noticed that much of the text in each was actually
independent of which version of SOAP is in use.  I have combined these
and boiled them down a bit, shortening both in the process. 
			*	I completely removed the text about
anonymous being "required" etc. from the SOAP section.  I believe this
is in line with Marc's comment about repeated text.  The first section
discusses when the anonymous URI can appear, the following sections
discuss what that means, and as far as I can tell the two are
independent. 
			*	All this notwithstanding, the core of
the original proposal for SOAP1.1/HTTP is basically intact.  In
generally, I believe this latest version has essentially the same
semantics as the previous one, but is briefer, (hopefully) clearer, and
applicable to both SOAP 1.1 and SOAP 1.2 

			As always, comments are welcome.
			
			
Received on Monday, 19 December 2005 17:00:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT