RE: issue 6432 - yet another proposal

If the subscriber sent the following:

<wse:Subscribe>
            <wse:Delivery>
                        <wse:NotifiyTo>
                            <wsa:Address>ftp://example.org/sockittome/

</wsa:Address>
                        </wse:NotifyTo>
            </wse:Delivery>
</wse:Subscribe>

... and the Event source had no capacity for sending events via the FTP 
protocol, how would that be different than the MC case that you assert
requires some special extensions to an endpoint that does not understand 
MC?

If the subscriber required 2048bit encryption of the event content and 
WS-Security was not supported by the source, is that different?

Of course not. Some means of achieving mutual compatibility of the 
requirements of the sink with the capabilities of the source is needed
in order to enable effective composition of the various WS-* specs. 

The W3C WS-Policy WG spent the better part of 18 months producing the 
WS-Policy 1.5 Framework and Attachments Recommendations
for just this use case - and lo and behold, WS-MC even defined a policy 
assertion vocabulary (as did WS-A and WS-Sec). Let's not
pretend that none of that happened - after all, this is the same working 
group that is producing WS-MEX, which is designed to 
enable exchange of the policy and other metadata of an endpoint, is it 
not?

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986





From:
"Chou, Wu (Wu)" <wuchou@avaya.com>
To:
"Asir Vedamuthu" <asirveda@microsoft.com>
Cc:
<public-ws-resource-access@w3.org>, "Li, Li (Li)" <lli5@avaya.com>
Date:
04/13/2009 02:27 PM
Subject:
RE: issue 6432 - yet another proposal
Sent by:
public-ws-resource-access-request@w3.org



It is a good idea to have a paper that explains how WS-MakeConnection (MC) 
composes with WS-Eventing and how it interworks with other WS-Addressing 
(WS-A)/WS-Eventing (WS-E) endpoints that do not support MC. We will also 
be interested to contribute to such a paper.
 
One particular question is: WS-A 1.0 Core specifies: "Comparison of 
[destination] property values is out of scope, other than using simple 
string comparison to detect whether the value is anonymous, that is, where 
[destination] has the value http://www.w3.org/2005/08/addressing/anonymous

." 
From WS-A Core, it seems that some extension from WS-A implementation is 
needed in order to detect and understand the special MC anonymous EPR.  If 
such extension is beyond the mandatory features of a WS-A endpoint, it 
would make sense to specify it as out-of-band to avoid additional 
requirements on a regular WS-A endpoint implementation. 
 
The concern is: if the WS-A implementation cannot identify the special MC 
anonymous EPR by the simple string comparison as specified in WS-A 1.0 
Core, it might treat the the special MC EPR as a regular EPR, and accept 
the event subscription to send events  to it (MC anonymous EPR). If that 
happens, it could cause a major problem and the events  won't be able to 
deliver. 
 
To be concrete, assume there is an event source that understands WS-E and 
WS-A, but does not support MC. When the event subscriber sends a Subscribe 
message using the MC extension:
<wse:Subscribe>
            <wse:Delivery>
                        <wse:NotifiyTo>
                            <wsa:Address>http://docs.oasis-open.org/ws-718 
rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000
</wsa:Address>
                        </wse:NotifyTo>
            </wse:Delivery>
</wse:Subscribe>
 
The event source checks the <wse:NotifyTo> EPR according to WS-A and 
decides it is neither “http://www.w3.org/2005/08/addressing/anonymous” nor 
“http://www.w3.org/2005/08/addressing/none” . Then it assumes it is an 
addressable EPR and will deliver notifications to it, which of course will 
fail.
 
This means using EPR alone to indicate MC style delivery will put an event 
source in one of the two situations:
1) The event source can be hit by a latent error because it does not 
recognize MC.
2) To avoid the latent error, the event source has to recognize the MC 
extension, even though it does not support MC.
 
- Wu Chou.
 
From: Asir Vedamuthu 
Sent: Friday, April 10, 2009 5:00 PM
To: Christopher B Ferris
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
 
> Any event sink would be foolish to engage in MC interchange with 
> an event source that did not advertise MC support in its policy.
 
Using WS-MakeConnection policy assertion to indicate the use of 
WS-MakeConnection protocol is possible. Earlier in the same mail thread 
[1], we mentioned that tiny subscribers are resource-challenged and may 
not have access to or may not understand metadata.
 
Anyway, such usages are outside the scope of WS-Eventing and should work 
with out-of-band agreements (and such agreements can be represented as a 
policy assertion).
 
Having said that, the Working Group should consider authoring a paper that 
explains how WS-MakeConnection composes with WS-Eventing using Doug’s 
quoted sample as a starting point. We will be happy to help.
 
[1] 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Apr/0027.html 

 
Regards,
 
Asir S Vedamuthu
Microsoft Corporation
 
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Thursday, April 09, 2009 6:32 AM
To: Asir Vedamuthu
Cc: public-ws-resource-access@w3.org
Subject: RE: issue 6432 - yet another proposal
 
Asir, 

It says that comparison of destination properties is out of scope. It does 
not say that it is disallowed. The reason that that 
statement is there is because URI comparison is non-trivial when you take 
into consideration all of the possible permutations 
of encodings that might be used. Many specs have deferred to 
straight-forward string comparison as a means of side-stepping 
the complexity. 

As for your implied assertion that _all_ implementations need to 
understand MC, that is ludicrous. No one has suggested that, nor is it 
necessary. Why do you think we spent all that time developing WS-Policy? 
MC has a policy assertion. Any event sink would be 
foolish to engage in MC interchange with an event source that did not 
advertise MC support in its policy. 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986 

From: 
Asir Vedamuthu <asirveda@microsoft.com> 
To: 
Christopher B Ferris/Waltham/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org> 
Date: 
04/08/2009 11:08 PM 
Subject: 
RE: issue 6432 - yet another proposal
 




A WS-Addressing-aware implementation or library is NOT required to run 
character by character comparison to infer that a WS-MakeConnection 
extension is required to speak with an Event Sink. 
“Comparison of [destination] property values is out of scope, other than 
using simple string comparison to detect whether the value is anonymous, 
that is, where [destination] has the value "
http://www.w3.org/2005/08/addressing/anonymous".” [1] 
An Endpoint Reference with encoded special semantics (WS-MakeConnection 
URI) ONLY makes sense IFF both sender and receiver understand the special 
semantics. This means, an Event Source (that is unaware of 
WS-MakeConnection) will not issue a fault that the Event Source does not 
understand the special semantics encoded in an Endpoint Reference. 
What is the justification to require all WS-Eventing implementations to 
recognize WS-MakeConnection URI? 
[1] 
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#msgaddrpropsinfoset 
Regards, 
  
Asir S Vedamuthu 
Microsoft Corporation 
  
From: public-ws-resource-access-request@w3.org [
mailto:public-ws-resource-access-request@w3.org] On Behalf Of Christopher 
B Ferris
Sent: Wednesday, April 08, 2009 1:29 PM
To: public-ws-resource-access@w3.org
Subject: Re: issue 6432 - yet another proposal 
  
Jeff is correct. Opacity is not a quality of an URI. It is a principle: 
you should not infer anything from the 
structure (or the content) of the path component of the URI. Note the use 
of the word "should" - I'll come back to that 
later. 

For instance, just because an URI ends in .pdf does NOT mean that the 
client/agent that uses that URI in a GET 
should expect to receive an application/pdf media type in the response 
entity body. 

So, repeat after me, opacity is not a quality, it is a principle. One URI 
is neither more, nor less "opaque" than another. 
Period. 

Now, what Asir may be alluding to is that the MC Anon URI is constructed 
from a URI template: 

       http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=

{unique-String} 

Here's where the opacity principle can be ignored: when the URI authority 
provides explicit information as to how to 
interpret the structure of the URI, as the WS-Make Connection spec [1] 
does. One can do a character for character 
match of the string 

       http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id= 

If it matches the first 58 characters of another URI, then that (other) 
URI is a MCanon URI. 

I refer you to the TAG finding that specifies that such practice is just 
fine thank-you very much [2] (3nd bullet in conclusions section): 

"* Assignment authorities may publish specifications detailing the 
structure and semantics of the URIs they assign. Other users of those URIs 
may use such specifications to infer information about resources 
identified by URI assigned by that authority." 

[1] 
http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-spec-os.html#_Toc162743905 

[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061204.html 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry Standards
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris

phone: +1 508 234 2986 

From: 
Jeff Mischkinsky <jeff.mischkinsky@oracle.com> 
To: 
Yves Lafon <ylafon@w3.org> 
Cc: 
Gilbert Pilz <gilbert.pilz@oracle.com>, Asir Vedamuthu 
<asirveda@microsoft.com>, Doug Davis/Raleigh/IBM@IBMUS, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> 
Date: 
04/08/2009 03:16 PM 
Subject: 
Re: issue 6432 - yet another proposal 
Sent by: 
public-ws-resource-access-request@w3.org

 
 





hi,
 My understanding of the use of "opaque" wrt to URI's is that you 
are not supposed to infer anything from the structure of the URI, not 
that specific uri's don't have specific "meanings"/semantics as 
defined in specs.
 Otherwise it is totally meaningless to define a uri and give it 
semantics.
So this argument and asir's response don't make sense to me. You can 
certainly tell that the 2 uri's in question are different and you can 
certainly know what the semantics of using them are. So i don't see a 
problem.
  -jeff
On Apr 08, 2009, at 2:34 AM, Yves Lafon wrote:

> On Tue, 7 Apr 2009, Gilbert Pilz wrote:
>
>> WS-Addressing 1.0 - Core defines two "special" URIs;
>> "http://www.w3.org/2005/08/addressing/anonymous" and
>> "http://www.w3.org/2005/08/addressing/none". Messages targeted to 
>> either
>> of these URIs are processed differently from messages targeted to
>> "normal" URIs such as "http://webserivce.bea.com/. . .".
>
> Well, they are different, but unless you know WS-Addressing, or 
> unless you resolve http://www.w3.org/2005/08/addressing/anonymous 
> and find out the relationship between this URI and the WS-Addressing 
> spec.
> If you resolve http://webservice.bea.com/... you will probably have 
> information about the endpoint, or you may know it in advance from 
> another document. So both URIs are opaque, unless you know their 
> semantic.
>
>
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
>

--
Jeff Mischkinsky  jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware  +1(650)506-1975
               and Web Services Standards                             500 
Oracle Parkway, M/S 2OP9
Oracle  Redwood Shores, CA 94065

Received on Monday, 13 April 2009 20:13:37 UTC