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

RE: LC68 - Use-cases

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Mon, 27 Jun 2005 15:57:56 -0400
Message-ID: <80A43FC052CE3949A327527DCD5D6B27011FA85F@MAIL01.bedford.progress.com>
To: "Prasad Yendluri" <pyendluri@webmethods.com>
Cc: <public-ws-addressing@w3.org>


Hi Prasad!

No question that directory particulars are out of scope for WS-A... the
example was intended to demonstrate that the "mandatory" bit could be
used by an extension in order to make a message in a particular
environment more "self-describing", and more likely to result in
successful processing.  In other words, it was just an example of
something someone could do if the mandatory bit were there that would be
harder without it.

--Glen

> -----Original Message-----
> From: Prasad Yendluri [mailto:pyendluri@webmethods.com] 
> Sent: Monday, June 27, 2005 12:06 PM
> To: Glen Daniels
> Cc: public-ws-addressing@w3.org
> Subject: Re: LC68 - Use-cases
> 
> Glen,
> 
> I agree that having a way to mark extensions mandatory (or 
> fail) is useful (core issue of 68). However I consider the 
> usecase #2 a red herring. How a URI in an EPR is mapped to a 
> physical location is outside the scope for WS-A.
> 
> Regards, Prasad
> 
> Glen Daniels wrote:
> 
> >Hi folks:
> >
> >Here are a couple of scenarios which I think serve to 
> illustrate issues 
> >around LC68, and why I believe we should introduce some kind of 
> >@wsa:mandatory attribute.
> >
> >In general, I also think the text in the last paragraph of 
> section 2.5 
> >is problematic.  It seems like we're basically saying "sure, 
> you can do 
> >anything with extensions but you had better not do anything 
> that really 
> >changes anything since it can get ignored (despite us just 
> having told 
> >you that you CAN really change things)".  Yuk.
> >
> >#1 - Policy
> >
> >According to the current core spec (section 2.5), any 
> extension (which 
> >would include things like WS-Policy) that is not understood 
> is freely 
> >ignorable, and "standard processing" will ensue in these 
> cases.  This 
> >means that there is no way to express in an EPR the idea 
> that "you MUST 
> >use WS-Security when talking to this endpoint".  Despite the 
> fact that 
> >this concept is expressible in WSDL, and in Policy, the 
> rules for EPR 
> >extensions do not provide a mechanism to indicate that a specific 
> >policy is mandatory.
> >
> >#2 - Directories
> >
> >We know <wsa:Address> values are logical, not physical, URIs (even 
> >though in most cases thus far they are exactly the same as the 
> >transport URI used to contact the endpoint).  Therefore, an EPR user 
> >may need to do some kind of mapping in order to figure out how to 
> >actually convert a <wsa:Address> into something that can be used "on 
> >the wire".  We can posit an EPR extension which selects a particular 
> >directory service to be used with a particular EPR.  In this 
> case, it 
> >is not possible that the EPR user will be able to "guess" what to do 
> >with the <wsa:Address> outside the context of the directory service, 
> >therefore marking the extension as mandatory is appropriate.
> >
> ><wsa:EPR>
> > <wsa:Address>myURI:Fred</wsa:Address>
> > <ds:DirectoryService wsa:mandatory="true">
> >   http://MinnesotaGreenPages.com/
> > </ds:DirectoryService>
> ></wsa:EPR>
> >
> >Thanks,
> >--Glen
> >  
> >
> 
> 
> 
Received on Monday, 27 June 2005 19:58:06 GMT

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