Re: WS-Eventing issue 6424 proposal

This does raise another issue about the use of WS-Addressing itself.  We 
don't really have a clear statement about whether WS-Addressing is 
required or not for each spec.  Yes each spec makes use of EPRs in the 
Body but that's independent of whether WSA itself is used to send the 
message - meaning, are the WSA headers required?  There is no technical 
reason why a Subscribe() could not be sent w/o any WSA headers.  While I 
suspect that most people will turn WSA on when they use these specs, do we 
really want/need to mandate it?  Should constrained devices that live in a 
very simple environment be required to have the extra overhead?  Seems 
more like the mandate of a profile than of a composible spec.

STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |

Gilbert Pilz <> 
Sent by:
03/06/2009 08:17 PM

Geoff Bullen <>
"Chou, Wu (Wu)" <>, Doug Davis/Raleigh/IBM@IBMUS, Li Li 
<>, "" 
Re: WS-Eventing issue 6424 proposal

Sort of but, to me, a proposal is a proposal. If we were to accept this 
proposal than I would expect that the text about wsa:To would be added to 
the spec. If 6424 is really just about the use of infoset, then I think we 
should remove the addition of the wsa:To from the proposal and raise 
whatever motivated its inclusion as a separate issue. This is consistent 
with our treatment of 6587, "Consistent text for 'Notational Conventions'" 
on this weeks concall.

- gp

p.s. Why did the requirement to include wsa:To get added to this proposal? 
It doesn't seem to have anything to do with the use of infoset.

Geoff Bullen wrote: 
Your point is well taken.  However, 6424 is really about if we should use 
Infoset in the specs and then an example of how to do such a thing, that 
we can use as a ?template? for making the changes in all the specs.  I 
think we need to agree (or not) on using Infoset and the template first .
What you seem to be having issue with is the ?content? of the changes 
proposed by the Eventing Editor in order to  fulfill the obligation to 
update the Eventing spec to use Infoset.  I think that is a different 
issue, and you are right, you can?t really create that issue till an 
Editor?s draft of the changes are available (assuming we decide to use 
Does that make sense?
From: Gilbert Pilz [] 
Sent: Friday, March 06, 2009 3:43 PM
To: Geoff Bullen
Cc: Chou, Wu (Wu); Doug Davis; Li Li;;
Subject: Re: WS-Eventing issue 6424 proposal

I'm confused. Currently the description of wse:Subscribe contains no 
mention of wsa:To. Wu has just posted a proposal for 6424 (
) that adds the following to WS-Eventing:

The REQUIRED [event source] property provides the value of the 
WS-Addressing wsa:To element.
So how can it be that this has no connection to issue 6424? How can I 
raise an issue against a proposal that hasn't been accepted?

- gp

Geoff Bullen wrote: 
if you think this is a real issue, then you should probably file a 
separate bug for it, as it does not seem to have any real connection with 
issue 6424.
From: [] On Behalf Of Gilbert Pilz
Sent: Friday, March 06, 2009 3:18 PM
To: Chou, Wu (Wu)
Cc: Doug Davis; Li Li;;; Geoff Bullen
Subject: Re: WS-Eventing issue 6424 proposal
I know I should have said this earlier, but I'm a bit concerned that 
WS-Eventing is requiring the presence of a header which is optional in the 
WS-Addressing specification that defines that header:
This OPTIONAL element (whose content is of type xs:anyURI) provides the 
value for the [destination] property. If this element is NOT present then 
the value of the [destination] property is 
I foresee implementation problems due to the fact that the presence or 
absence of the wsa:To header may be solely under the control of the 
WS-Addressing message handler and may not be controllable by the code that 
creates the wse:Subscribe message.

- gp

Chou, Wu (Wu) wrote: 
Many thanks for your comments and suggestions, especially the one 
regarding the cardinality. Here is an updated Infoset draft (v7) of the 
Subscribe Section of Eventing (clean+marked copies). We really moved a 
long way with all comments and contributions received.
- Wu Chou.

Received on Saturday, 7 March 2009 15:33:01 UTC