W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Draft Resolution for Issue 41

From: Jacek Kopecky <jacek@systinet.com>
Date: Fri, 8 Mar 2002 17:29:20 +0100 (CET)
To: amr.f.yassin@philips.com
cc: xml-dist-app@w3.org
Message-ID: <Pine.LNX.4.44.0203081723540.6396-100000@mail.idoox.com>
 Amr,
 I prefer solution 2. In some cases putting the target URI in the
envelope may be undesirable (security considerations, for
example) or even impossible (when the source does not know/care 
where exactly the message goes after reaching some intermediary).
 Even WS-Routing by Microsoft, for example, does not make it 
mandatory for the source to specify the final target, although it 
is possible.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Fri, 8 Mar 2002 amr.f.yassin@philips.com wrote:

 > Jacek,
 > 
 > Shall we add it to the core or make it optional?
 > 
 > Solution 1: (Add it to the core)
 > "Modify (Part 1 Section 7: Use of URI in SOAP) to reflect that the 
 > envelope SHOULD include the target URIs especially if the application uses 
 > intermediaries and make it part of the XMLP core."
 > 
 > 
 > Solution 2: (Make it application dependent)
 > "It is the responsibility of the application designer to provide the 
 > appropriate target URIs at the appropriate points of the message path, or 
 > of a routing extension, not of the SOAP core."
 > 
 > What do you think?
 > 
 > Amr Yassin
 > 
 > 
 > 
 > 
 > 
 > 
 > Jacek Kopecky <jacek@systinet.com>
 > 03/07/2002 02:37 PM
 > 
 >  
 >         To:     AMR F Yassin/BRQ/RESEARCH/PHILIPS@AMEC
 >         cc:     xml-dist-app@w3.org
 >         Subject:        Re: Draft Resolution for Issue 41
 >         Classification: 
 > 
 > 
 > 
 >  Amr, 
 >  I'm afraid the text you quote does not address the issue. I 
 > think the proposal should rather be to say: 
 >  "While the target URI is not normatively in the envelope, if an 
 > application uses intermediaries, it must configure somehow 
 > (either statically or using dynamic routing protocol) the message 
 > path. Part of this configuration is the successive target URIs. 
 > Therefore it is the responsibility of the application designer to 
 > provide the appropriate target URIs at the appropriate points of 
 > the message path, or of a routing extension, not of the SOAP 
 > core."
 >  What'dya think? 8-)
 > 
 >                    Jacek Kopecky
 > 
 >                    Senior Architect, Systinet (formerly Idoox)
 >                    http://www.systinet.com/
 > 
 > 
 > 
 > On Thu, 7 Mar 2002 amr.f.yassin@philips.com wrote:
 > 
 >  > Hi,
 >  > 
 >  > I was assigned to write down a proposal to resolve issue 41. 
 >  > 
 >  > <Issue_41>
 >  > The target (program, service or object) URI (TBD) is not mentioned in 
 > any 
 >  > normative way in the SOAP envelope. While this does not conflict with 
 > the 
 >  > requirements, I believe it's an important (and possibly debatable) 
 >  > decision. This decision precludes sending an RPC invocation through an 
 >  > intermediary that uses different protocol bindings for sending and 
 >  > receiving XP messages. [1]
 >  > </Issue_41>
 >  > 
 >  > Proposal:
 >  > 
 >  > I propose to close this issue since it was addressed in Part 1 section 
 > 2.1 
 >  > and 2.2
 >  > 
 >  > <Sec_2.1>
 >  > A SOAP node can be the initial SOAP sender, the ultimate SOAP receiver, 
 > or 
 >  > a SOAP intermediary, in which case it is both a SOAP sender and a SOAP 
 >  > receiver.
 >  > ...
 >  > A SOAP node MUST be identified by a URI
 >  > </Sec_2.1>
 >  > 
 >  > 
 >  > <Sec_2.2>
 >  > In processing a SOAP message, a SOAP node is said to act in one or more 
 > 
 >  > SOAP roles, each of which is identified by a URI known as the SOAP role 
 > 
 >  > name. 
 >  > </Sec_2.2>
 >  > 
 >  > 
 >  > ________________________________________
 >  > Amr Yassin      <amr.f.yassin@philips.com>
 >  > Research Member
 >  > 
 > 
 > 
 > 
 > 
Received on Friday, 8 March 2002 11:29:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT