OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Second cut


This cut has changes only to section 5, and a couple of those are deletions, so I thing it has a better chance of flying.  I basically did two things:
  • Deleted any reference I saw to "raw" format.  I think I got them all.
  • Added a paragraph at the bottom of the "CreatePullPoint" operation, which basically makes very explicit that the PullPoint accumulates precisely what it chooses to accumulate, no more, no less:
It is expected that some NotificationProducer implementations may choose to optimize the accumulation of messages in a pull point by bypassing physical transport mechanisms and placing Notification messages in the pull point directly.  In such cases, PullPoints created by the CreatePullPoint operation may or may not accumulate Notify messages sent to the given address, instead serving only as an indication for the NotificationProducer to accumulate Notifications for retrieval by the GetMessages operation at that address.
A couple of questions/comments:
  • In reviewing another document, I ran across a case where explicitly listing one scenario seemed to imply that other scenarios were excluded (the exception proves the rule).  Would it be better to say "In such cases, and for any other reason ...", or is that overkill?
  • We're basically saying that an optimized pullpoint (or any other) may choose simply to drop messages on the floor.  Should it fault instead?  Probably not.
  • I had originally tried to say that the created pullpoint would not be a valid address for physically sending Notify messages.  Besides being awkward, this is misleading since the pullpoint should be a valid address for sending physical GetMessages messages.  This is a mild argument for having Notify throw an unsupported operation fault if Notify is disabled.
  • Should we mention that NPs may refuse to allow subscriptions for pull points they didn't create (assuming they can somehow detect them, perhaps because they only accept subscriptions for NCs they created)?  An NP can refuse any subscription for any reason, so this is nothing new, but neither is the above paragraph.
  • Should we include something along the lines of "In the absence of policy assertions or other indications, Subscribers SHOULD NOT assume that a pull point is valid for subscriptions by NPs other than the one that created it [assuming that the pull point factory is not a third party].  Pull point factories SHOULD indicate through policy assertions or other indications whether their pull points support the Notify operation."?
Hope this helps.

wsn-ws-base_notification-1.3-spec-pr-01-take2.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]