[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stopping notifications
Martin Bjorklund wrote:
Andy Bierman <email@example.com> wrote:
The agent has to send something if a manager sends an RPC request
during notification mode, even if it is a quick 'operation-failed' reply.
There's nothing in the draft that specifies this behaviour.
Just letting the manager hang until it times out seems wrong.
Well it's wrong to try to send anything in notification mode...
The agent cannot assume the manager will always send the correct PDU.
The agent must always respond appropriately to an <rpc> request.
RFC 4741 says so.
The immediate issue is whether or not the draft needs to say
anything about this situation.
I think it is better to just say the agent MAY allow RPC requests
to be processed after <create-subscription>, but if not, the
agent MUST respond with an appropriate <rpc-error>.
(Define an error-app-tag like 'notification-exclusive-mode' for
an operation-failed error-tag).
IMO, there is already code to close down the session in case
it is dropped, and this is not nearly as hard to support as
allowing any RPC method.
This is obviously implementation dependent. In my implementation, I
would have to add code to detect this case and send an
'operation-failed' error instead of handling the request.
This argument washes out.
You would need special code to know you are in notification mode
so you should ignore the subsequent <rpc> requests.
I think my solution above allows the 'normal' code path
to be utilized, allows an implementer to easily reject requests
in notification mode, and allows a manager to easily tell
if interlaced RPCs are supported (without needing yet another capability).
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.