In Section 3.0, notification requirements are specified. In each
subsection, 3.1, 3.2, 3.3, a specific requirement is listed. However in
a couple of subsections identify what is NOT a requirement. And another
subsection at the same section level as a formal requirement, lists a
caveat to the previously numbered requirement.
For ease of readability, each subsection 3.x, should list a specific
requirement. If there is a caveat or other note to the requirement, then
it should appear as another subsection, 3.x.y, of the requirement (i.e.,
3.x) to which it is referring.
For example, section 3.6 should probably be moved to section 3.1.1.
Also, section 3.7 should probably be moved to 3.3.1.
It there is a caveat or exception to a particular requirement, then I
would like to know about it in the context of what I'm reading at the
time.
Also, on another item, we've talked about not requiring an event
notification sender to verify reception of a particular notification
message to a notification recipient. We did this (I guess) to save us
the work of having to figure out how to do this. However, I think this
idea is fundamentally in conflict with the other requirement that end
users can specify reliability and quality-of-service to be attached to a
particular notification registration. If the user specified that an
event must be delivered to the intended recipient, and emphasizes this
point with an associated reliability or QoS parameter, then it is
critical that we provide enough information as possible as to the status
of the notification delivery.
Just my $0.02
Randy