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

RE: i042: Extensibility Model

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 14 Feb 2005 10:43:52 -0800
Message-ID: <7DA77BF2392448449D094BCEF67569A50684EE3B@RED-MSG-30.redmond.corp.microsoft.com>
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, <public-ws-addressing@w3.org>

I wrote:
> >3) Clarify that extensions are allowed to modify the values of
> >   the existing Endpoint Reference Properties.  Note that this,
> >   combined with the ignore-unknown rule (2), may result in a
> >   difference of behavior between a processor that understands
> >   such an extension and one that does not.  Extension
> >   developers should consider whether they desire this
> >   "fallback to vanilla WS-A" behavior when designing such
> >   an extension.

and

> >5) Clarify that extensions may introduce new properties.

Umit asked:
> I have a clarification question about point 3. I am not clear how
> allowing extensibility to modify existing properties may mean,
> specifically with regards the roles, EPR minter and the recipient of
> the
> EPR. I am wondering who is allowed to modify the EPR's exising
> parameters in processing the extension and how this would affect the
> interaction using the modified EPR.
> 
> Modifying the properties of an EPR is only interesting from the
> perspective of the EPR recipient. Otherwise, I claim that it is not
> that
> interesting for the EPR minter.

A property communicates something from the minter to the recipient, so
it must be of interest to both parties to be worth describing as a
property.

> I am particularly curious about the
> [reference parameters] property. I will describe a scenerio where this
> is possible with (5) and (3).
>
> Lets assume that there is an extension property (5) in the EPR. This
> extension (say [add-new]) has the semantics of the to add a new
> parameter to the existing params, hence modifying the [reference
> params]
> property, which is (3).
> 
> The EPR minter sends an EPR which contains a new extension property
> [add-new] per 5.
> 
> The receiver gets the EPR, processes the extension. Its semantics is
> to
> add a new parameter to the existing refParams. It adds a new parameter
> and value.
> 
> The receiver then sends a message using the modified EPR, using the
> SOAP
> binding. The parameters now contain not only the opaque data (from the
> perspective of the recipient), but also stuff that the EPR recipient
> wanted to send to the endpoint.
> 
> I presume this scenerio is allowed with the extension proposal. Let me
> know whether I got this right.

Yes, that would be allowed, though it's a little odd.  If the minter
wants to add something to the [reference parameters] property they can
just include it there.  Likewise if you want to add a new header, the
[add-new] property could indicate that directly.

A client understanding the [add-new] property would add an additional
header into the message.  A client not understanding [add-new] would
ignore it and fall back to sending a message without the new header.  If
this isn't the behavior the minter wants, it needs to communicate to the
client in some other fashion (e.g. a required feature in WSDL) what the
client's minimal capabilities must be.

> --umit
Received on Monday, 14 February 2005 18:44:02 GMT

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