Issue verification: 2.23, 2.36, 2.39

["Rick Cobb" <rcobb@KnowNow.com>]

Verified against base draft j; I have tiny quibbles with 2.23 & 2.39.

2.23: Is subscription a WS-Resource? Approach taken as agreed, but...

	Lines 469-472: Unequivocally YES
	Lines 1106-1114 (and many others): Support for optionality, 
		as specified in the proposed recommendation.

	The text from the proposed recommendation has been 
	incorporated, so the dependency on WS-RL is gone.
	However, lines 469-472 state with absolutely
	no ambiguity that a subscription reference is always 
	to a WS-Resource.  I think this is as intended, however,
	as a non-participant in WS-RF, I find it somewhat
	confusing. I interpret this to mean that the reference
	has the appropriate form for a WS-Resource, but no
	implied WS-Resource semantics?

2.36: Specify baseline Policy behaviour: OK

	Subscription durability (Pause/Resume) line 1292-1294: OK
	Message durability: No relevant text in Base: OK
	Pull Notification: OK
		lines 868-1104
		Since PullPoint is a separate interface now, AFAICT, 
		there is no need for a baseline policy; either you 
		know where there are pull point creators that can
		create pullpoints that are reachable 
		by both your notification producer and your consumer, 
		or not, and the notification producer doesn't know 
		the difference anyway.
	Message continuity (Lines 1156 - 1464): OK
	Flow control (lines 630-631): OK
		No normative text associated with this, however, I 
		the use of it as an example in the SubscriptionPolicy
		element description provides adequate guidance to 
		implementors that there is no guaranteed flow control.
	Reliability (lines 277-283): OK
		In the new introductory text for "production vs. 
		delivery", I think we imply quite strongly that 
		reliable delivery is not considered to be in scope 
		of the proposal.  I disagree with
		Sanjay's earlier assertion in [1] that this 
		should be covered in the NotificationConsumer.Notify()
		section, since this section emphasizes the
		responsibilities of the consumer, not the
		producer or the delivery channel.

2.39: Tighten up the semantics of  "send/delivery": Done well enough,
but...

	OK uses of "send":
		In the context of "send a fault": OK
		Non-normative text associated with motivation for the
pull interface: Questionable, but OK
		In the context of "send a WS request": OK
		In the context of "send a comment to": OK
		Line 141: "send information to": OK

	I'd change these:
		Line 521: Should be "NotificationProducer should produce
messages for the NotificationConsumer".
		Line 1531: Should be "refuse to *produce* messages to
Notification Consumers that are not known to be authorized."

	The term "deliver" is not used anywhere in the document.
	The term "delivery" is used exactly as intended in all cases.
	
[1]
http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200504/m
sg00023.html