Re: issue 6432 - yet another proposal

Yeah, what he said.

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:
Gilbert Pilz <gilbert.pilz@oracle.com>
To:
Asir Vedamuthu <asirveda@microsoft.com>
Cc:
Christopher B Ferris/Waltham/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
Date:
04/09/2009 01:34 AM
Subject:
Re: issue 6432 - yet another proposal



Who said that all WS-Eventing implementations must recognize the MC-Anon 
URI? Sending a Subscribe with a NotifyTo address that is an instance of an 
MC-Anon URI to an Event Source that does not support or recognize MC-Anon 
URIs is ultimately no different than fat-fingering a normal HTTP NotifyTo 
address such that the pathname is incorrect. The Subscribe will succeed 
but no Notifications will ever be delivered. This is a natural result of 
the decoupled, one-to-many nature of the pub/sub paradigm.

This is why, if an Event Source does not affirm that it supports WS-MC via 
the wsmc:MCSupported policy assertion, a Subscriber cannot be sure WS-MC 
will be supported and cannot even expect that the Subscribe operation will 
fail if it is not.

- gp

Asir Vedamuthu wrote: 
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