This section documents the messaging and message handling protocols defined in SIF. A messaging protocol consists of sending a SIF_Message
to initiate an operation, receiving back a SIF_Ack; a message handling protocol consists of processing an incoming SIF_Message
and responding with a SIF_Ack and possibly sending follow-up SIF_Messages. This section is independent
of transport layer details, aside from encryption and authentication level impacts associated with individual messages.
Unless otherwise noted, all protocols assume successful communication over the appropriate transport layer;
agent and ZIS implementations should also be prepared to handle transport layer errors and exceptions, directly or wrapped in
a SIF_Ack/SIF_Error by underlying code.
This section documents how Agents should send individual messages, and the resulting post-conditions upon success or failure, along with any necessary steps to take. These correspond to each of the operations an Agent can initiate.
An Agent must register with the ZIS to participate in a Zone. To do so, it sends a SIF_Register
message. An Agent may at any time re-register by sending another SIF_Register message.
The ZIS updates the Agent's registered settings accordingly.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_Register message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place your Agent's name, supported versions and maximum buffer size for receiving messages
into SIF_Name, SIF_Version and SIF_MaxBufferSize, respectively.
Specify whether your Agent is Push- or Pull-mode in SIF_Mode. If SIF_Mode is Push,
specify the protocol information for the ZIS to use when delivering messages to your agent in SIF_Protocol;
optional compression settings may be included in the Accept-Encoding SIF_Protocol/SIF_Property.
If desired, supply optional information regarding your Agent and/or application in SIF_NodeVendor,
SIF_NodeVersion, SIF_Application and SIF_Icon.
|
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is now registered in the Zone. The Access Control settings for your agent (SIF_AgentACL are in
SIF_Status/SIF_Data). |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. Note particularly category 5. If an Accept-Encoding
SIF_Protocol/SIF_Property was specified, the ZIS may return error code 10
(ZIS does not support the requested Accept-Encoding value). Your agent SHOULD
re-attempt registration without, or with another, Accept-Encoding value. |
Messaging protocol complete (failure). |
An Agent removes itself from a Zone by sending a SIF_Unregister message to the ZIS. Successful
completion of this operation removes all settings associated with the Agent, including the objects it is currently
providing and subscribed to in the zone; the Agent's message queue is also deleted. Note that a successful
SIF_Unregister message may, depending on the ZIS implementation, remove access control settings that
have been manually configured by a Zone administrator and that may need to be re-configured for a subsequent
successful SIF_Register.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_Unregister message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is now removed from the Zone. | Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
An Agent registers with the ZIS to be the default Responder, or Provider, for one or more
SIF objects in one or more contexts by sending a SIF_Provide
message to the ZIS. The Agent must have access control rights at the ZIS to successfully register
as a Provider for an object.
Note that upon successful completion of SIF_Provide that your Agent is still the Provider
of any objects for which it was previously registered as the Provider. To unregister as the Provider
of given objects, use SIF_Unprovide. To replace all objects your Agent provides in one
operation, use SIF_Provision.
As of version 2.0 of this specification, SIF_Provision is the preferred method for registering an
Agent as a Provider, and provisioning an Agent in general. Support for SIF_Provide may be removed
in a future major release of this specification.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_Provide message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. For each object your Agent would like to provide, place a SIF_Object element with an
ObjectName and optionally one or more SIF_Context names (which default to SIF_Default if omitted).
Your Agent's support for SIF_ExtendedQuery can be specified in SIF_ExtendedQuerySupport for each object.
|
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is now the Provider of each of the objects specified in the SIF_Provide message, in the
applicable context(s). Any request sent by an Agent for one of these objects without explicitly specifying
a particular Responder in SIF_Header/SIF_DestinationId will be placed in your Agent's message queue. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. Note particularly category 4, code 3 (no permission to provide)
and category 6, code 4 (object already has a Provider). |
Messaging protocol complete (failure). |
Your Agent unregisters with the ZIS as the default Responder, or Provider, for one or more
SIF objects in one or more contexts by sending a SIF_Unprovide
message to the ZIS. Note that any
SIF_Requests for these objects already pending in your Agent's queue will still be delivered.
As of version 2.0 of this specification, SIF_Provision is the preferred method for unregistering an
Agent as a Provider, and provisioning an Agent in general. Support for SIF_Unprovide may be removed
in a future major release of this specification.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_Unprovide message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. For each object your Agent would like to provide, include a SIF_Object element with an
ObjectName and optionally one or more SIF_Context names (which default to SIF_Default if omitted). |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is no longer the Provider of each of the objects specified in the SIF_Unprovide message, in the
applicable context(s). SIF_Requests will no longer be routed to your Agent by default, but this
does not prevent other Agents from sending requests directly to your Agent (if permitted by access control rights). |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
An Agent registers with the ZIS to receive SIF_Events for one or more SIF objects
in one or more contexts by sending a SIF_Subscribe
message to the ZIS. The Agent must have access control rights at the ZIS to successfully subscribe
to events for an object.
Note that upon successful completion of SIF_Subscribe that your Agent is still subscribed to objects
to which it had previously subscribed. To unregister as a Subscriber
of given objects, use SIF_Unsubscribe. To replace all objects to which your Agent subscribes in one
operation, use SIF_Provision.
As of version 2.0 of this specification, SIF_Provision is the preferred method for registering an
Agent as a Subscriber, and provisioning an Agent in general. Support for SIF_Subscribe may be removed
in a future major release of this specification.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_Subscribe message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. For each object your Agent would like to subscribe to, place a SIF_Object element with an
ObjectName and optionally one or more SIF_Context names (which default to SIF_Default if omitted). |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is now subscribed to each of the objects specified in the SIF_Subscribe message, in the
specified context(s) if included. Any SIF_Events for these objects will be placed in your Agent's queue. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. Note particularly category 4, code 4 (no permission to subscribe). |
Messaging protocol complete (failure). |
To stop receiving SIF_Events for one or more objects in one or more contexts, an Agent sends a
SIF_Unsubscribe
message to the ZIS. Note that if there are events already pending in your Agent's queue for these objects,
they will still be delivered after a successful SIF_Unsubscribe.
As of version 2.0 of this specification, SIF_Provision is the preferred method for unregistering an
Agent as a Subscriber, and provisioning an Agent in general. Support for SIF_Unsubscribe may be removed
in a future major release of this specification.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_Unsubscribe message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. For each object your Agent would like to cease receiving events, include a SIF_Object element with an
ObjectName and optionally one or more SIF_Context names (which default to SIF_Default if omitted). |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is now unsubscribed from each of the objects specified in the SIF_Unsubscribe message, in the
applicable context(s). SIF_Events for these objects will cease to be placed in your Agent's queue. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
The SIF_Provision message provides an Agent the ability to register the objects it provides and to
which it subscribes in a single operation, replacing whatever settings the ZIS has on record for the Agent. In effect
it is an alternative to SIF_Provide, SIF_Unprovide, SIF_Subscribe and SIF_Unsubscribe,
though an Agent may choose to use this message or those, or a combination of these messages.
This message also
allows the Agent to fully describe the operations it will perform in a Zone beyond those that can be
communicated with SIF_Provide
and SIF_Subscribe, including the types of events it will publish, the requests to which it will respond with or without
being the Provider for requested objects, and the objects for which it sends requests.
The Agent must have the appropriate access control settings to successfully register any of the corresponding information included
in SIF_Provision. Note that the list of access control settings can be determined by examining the SIF_AgentACL
object returned in the SIF_Register or SIF_GetAgentACL message protocols.
Note that SIF_Provision will also fail if the Agent is attempting to provide an object that is already provided
by another Agent in the applicable Zone Context. The list of Providers in a Zone can be found in SIF_ZoneStatus.
As of version 2.0 of this specification, SIF_Provision is the preferred method for provisioning an Agent.
Support for SIF_Subscribe, SIF_Unsubscribe, SIF_Provide and SIF_Unprovide
may be removed in a future major release of this specification.
| Step | Process | Flow Control |
| 1 |
Prepare a Include Include Include Include Include |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent is now registered with the corresponding settings in the Zone. Any previously recorded settings with regard to the operations your Agent performs have been replaced. | Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
When an application adds, changes or deletes data represented in one or more Zone Contexts, its Agent SHOULD
publish the corresponding Add, Change or Delete SIF_Event to the Zone. Upon
successful delivery of a SIF_Event to the ZIS, the ZIS places the event in the queue for any
Agents subscribed to events for the object, including your Agent if it is a subscriber.
| Step | Process | Flow Control |
| 1 |
Prepare a Specify the name of the object that is being added, changed or deleted in
For a
For a |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | The event has been successfully received by the ZIS. It will be placed in the queue of any Agents registered as subscribers to events for the given object. | Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
An Agent can request data from another Agent at any time by sending a SIF_Request message. Agents use one of two
query mechanisms in requests. SIF's
default query mechanism, SIF_Query, is used to request objects of a given type, matching optional query conditions, optionally
returning a subset of object elements. SIF_ExtendedQuery is used to select elements from
one or more objects, joined together, if necessary, on RefId-based conditions. Before delivering a request with a
SIF_ExtendedQuery to a Responder, the ZIS checks that the Responder supports SIF_ExtendedQuery
for all referenced objects.
| Step | Process | Flow Control |
| 1 |
Prepare a |
If using |
| 2 | In SIF_Query, specify the object name being requested in SIF_QueryObject/@ObjectName.
Optionally specify the subset of elements/attributes to be returned from each object in
SIF_QueryObject/SIF_Element; note that parent elements of specified elements/attributes are returned as well.
If your Agent would like to specify query matching conditions, include SIF_ConditionGroup. Alternately an example of an object allowed for use in query-by-example can be placed in
SIF_Example.
|
Send SIF_Message to ZIS over appropriate transport. Go to step 4. |
| 3 | Include a SIF_ExtendedQuery. If your Agent did not specify
SIF_DestinationId, the SIF_Request will be routed to the Provider for SIF_From/@ObjectName.
If your Agent would like to override this routing mechanism, include SIF_DestinationProvider set
to the object name for which the ZIS will determine the Provider and route the request accordingly. |
Send SIF_Message to ZIS over appropriate transport. |
| 4 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 5 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 7. |
| 6 | The request has been successfully received by the ZIS. It will be placed in the queue of the appropriate Responder
as specified in SIF_Header/SIF_DestinationId or determined by SIF_ExtendedQuery/SIF_From/@ObjectName
or SIF_ExtendedQuery/SIF_DestinationProvider. |
Messaging protocol complete (success). |
| 7 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 8 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
An agent can "ping" the ZIS or check that it's online and/or "awake" by sending
a SIF_Ping message to the ZIS. If the agent receives
a successful acknowledgement, the ZIS is awake; the ZIS may also reply that it is asleep. As
a ZIS may be offline completely, Agents should be prepared to handle transport errors directly
or wrapped in a SIF_Ack/SIF_Error by underlying code.
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place an empty SIF_Ping
element in SIF_SystemControlData.
|
Send SIF_Message to ZIS over appropriate transport.
|
| 2 |
Receive SIF_Ack in response.
Is SIF_Error present?
|
If yes, go to Step 8. |
| 3 |
Is SIF_Status/SIF_Code 0?
|
If no, go to Step 5. |
| 4 | The ZIS is awake. | Messaging protocol complete (success). |
| 5 |
Is SIF_Status/SIF_Code 8 (ZIS is asleep)?
|
If no, go to Step 7. |
| 6 | The ZIS is asleep. | Messaging protocol complete (success). |
| 7 |
Messaging protocol has failed due to a SIF_Status/SIF_Code of
7 (your Agent sent a duplicate SIF_MsgId).
|
Messaging protocol complete (failure). |
| 8 |
Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included.
|
Messaging protocol complete (failure). |
A Push-mode Agent can send
a SIF_Sleep message to the ZIS to change its state
to "asleep," indicating that the ZIS should not send the Agent messages until it "wakes up"
by sending a SIF_Wakeup message or re-registering with SIF_Register.
A Pull-mode Agent can also changes it state to "sleeping," but this has no effect other than indicating
to other Agents via SIF_ZoneStatus that it is "sleeping" and not processing messages in its queue.
Sending a SIF_Wakeup or SIF_GetMessage will indicate that the Agent is "awake,"
as will re-registering with SIF_Register.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place an empty SIF_Sleep
element in SIF_SystemControlData. |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent's state has been set to "asleep" in the ZIS. This is reflected to other Agents
in SIF_ZoneStatus and if your Agent is a Push-mode Agent, the ZIS will stop
delivering messages to your Agent. To "wake up," send a SIF_Wakeup message, or re-register
with SIF_Register. Pull-mode Agents may also send SIF_GetMessage. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
An Agent can send
a SIF_Wakeup message to the ZIS to change its state to "awake," whether sleeping
or not; this state is available to other Agents via SIF_ZoneStatus.
Upon success, the ZIS may begin delivering messages to a Push-mode Agent again, if previously sleeping.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place an empty SIF_Wakeup
element in SIF_SystemControlData. |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 | Your Agent's state has been set to "awake" in the ZIS. This is reflected to other Agents
in SIF_ZoneStatus and if your Agent is a Push-mode Agent and it was previously
asleep, the ZIS will resume delivering messages to your Agent. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
To retrieve the current status of the Zone (SIF_ZoneStatus),
send a SIF_GetZoneStatus message to the ZIS.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place an empty SIF_GetZoneStatus
element in SIF_SystemControlData. |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 |
SIF_Status/SIF_Data contains the current status of the Zone in SIF_ZoneStatus. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
To retrieve your Agent's current access control list settings from the ZIS (SIF_AgentACL), send a SIF_GetAgentACL message to the ZIS.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place an empty SIF_GetAgentACL
element in SIF_SystemControlData. |
Send SIF_Message to ZIS over appropriate transport. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 6. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 |
SIF_Status/SIF_Data contains your Agent's current access control list settings in the Zone in
SIF_AgentACL. |
Messaging protocol complete (success). |
| 5 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 6 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
Agents can request that a ZIS cancel SIF_Requests, pending or in process, by sending a list
of SIF_RequestMsgIds in a SIF_CancelRequests message. If an Agent abandons or restarts a data
collection using SIF_Requests, whether or not the response stream has started, it is RECOMMENDED
that the Agent send one or more SIF_CancelRequests messages to the ZIS. Such data collections can place
a heavy load on responding Agents, where often all data of a specific object type is requested,
and cancelling requests may spare Zone resources. Cancelling of responses can also reduce the number of response packets
the receiving/cancelling agent needs to process and discard.
If the cancelling Agent wishes to receive a "final" SIF_Response from the ZIS for each cancelled message, it can
specify Standard in SIF_CancelRequests/SIF_NotificationType. If the cancelling Agent does not desire
or require "final" SIF_Responses, the Agent can specify None in SIF_NotificationType.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Add a SIF_CancelRequests
element in SIF_SystemControlData. |
|
| 2 | Specify Standard in NotificationType if your Agent desires or requires a "final" SIF_Response
be returned by the ZIS for each cancelled message (SIF_Response/SIF_MorePackets = No). Otherwise
specify None. |
|
| 3 | Add a SIF_RequestMsgIds element and add a child SIF_RequestMsgId element for each SIF_Request
that the Agent wishes to cancel. |
Send SIF_Message to ZIS over appropriate transport. |
| 4 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 8. |
| 5 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 7. |
| 6 | The ZIS has accepted the SIF_CancelRequests message. Your Agent will receive
or not receive "final" SIF_Responses per the specified NotificationType. |
Messaging protocol complete (success). |
| 7 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 8 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
Pull-mode Agents retrieve the next message in their queue by sending
a SIF_GetMessage message to the ZIS. Note that as individual messages
may have specific minimum encryption/authentication levels attached to them by senders, a Pull-Mode Agent should always
use the highest encryption/authentication levels it supports when contacting the ZIS to avoid individual messages
being discarded when contacting the ZIS using lower encryption/authentication levels than might be required for receipt
of a given message.
| Step | Process | Flow Control |
| 1 | Prepare a SIF_Message/SIF_SystemControl message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place an empty SIF_GetZoneStatus
element in SIF_SystemControlData. |
Send SIF_Message to ZIS over appropriate transport. Always use the highest encryption/authentication levels
that your Agent supports to maximize the number of messages that can be returned to your Agent. |
| 2 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 7. |
| 3 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 5. |
| 4 |
SIF_Status/SIF_Data contains the next SIF_Message in your agent's queue. |
Messaging protocol complete (success). Process the returned SIF_Message
according to Agent Message Handling Protocols below. |
| 5 | Is SIF_Status/SIF_Code 9? |
If yes, there are no messages available for your Agent. Message processing complete (success). |
| 6 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 7 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. If a Push-mode Agent sends SIF_GetMessage, note particularly category 5,
code 9 (agent registered in Push mode). |
Messaging protocol complete (failure). |
Push-Mode Agents end Selective Message Blocking (SMB) by sending a final SIF_Ack to the ZIS.
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_Message/SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. From the message being unblocked/removed from the queue, place the SIF_Header/SIF_SourceId
value into SIF_OriginalSourceId and place the SIF_Header/SIF_MsgId value into SIF_OriginalMsgId.
Place 3 (final SIF_Ack) into SIF_Code/SIF_Data.
|
Send SIF_Message to ZIS over appropriate transport.
|
| 2 |
Receive SIF_Ack in response.
Is SIF_Error present?
|
If yes, go to Step 6. |
| 3 |
Is SIF_Status/SIF_Code 0?
|
If no, go to Step 5. |
| 4 | The referenced message has been unblocked and removed from your Agent's queue. The ZIS resumes delivery of events to your Agent. | Messaging protocol complete (success). |
| 5 |
Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId).
|
Messaging protocol complete (failure). |
| 6 |
Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included.
|
Messaging protocol complete (failure). |
Pull-mode Agents acknowledge messages received in response to SIF_GetMessage and remove them from their queue by sending a SIF_Ack
message to the ZIS. SIF_Ack is also sent by Pull-Mode Agents to invoke and end Selective Message Blocking (SMB).
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_Message/SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. |
If your Agent is invoking SMB, go to Step 3. If your Agent is ending SMB, go to Step 4. |
| 2 |
From the message being acknowledged/the message to be removed from the queue, place the SIF_Header/SIF_SourceId
value into SIF_OriginalSourceId and place the SIF_Header/SIF_MsgId value into SIF_OriginalMsgId.
Place 1 (immediate SIF_Ack) into SIF_Code/SIF_Data or an appropriate error description in
SIF_Error. If your Agent indicates a transport error or places 8 (receiver is sleeping) into
SIF_Code/SIF_Data, the message
will be acknowledged but remain in your Agent's queue.
|
Send SIF_Message to ZIS over appropriate transport. Go to Step 5.
|
| 3 |
From the SIF_Event being blocked, place the SIF_Header/SIF_SourceId
value into SIF_OriginalSourceId and place the SIF_Header/SIF_MsgId value into SIF_OriginalMsgId.
Place 2 (intermediate SIF_Ack) into SIF_Code/SIF_Data.
|
Send SIF_Message to ZIS over appropriate transport. Go to Step 5.
|
| 4 |
From the SIF_Event being unblocked, place the SIF_Header/SIF_SourceId
value into SIF_OriginalSourceId and place the SIF_Header/SIF_MsgId value into SIF_OriginalMsgId.
Place 3 (final SIF_Ack) into SIF_Code/SIF_Data.
|
Send SIF_Message to ZIS over appropriate transport.
|
| 5 | Receive SIF_Ack in response.
Is SIF_Error present? |
If yes, go to Step 9. |
| 6 | Is SIF_Status/SIF_Code 0? |
If no, go to Step 8. |
| 7 |
If your Agent did not invoke or end SMB for a
If your Agent invoked SMB by sending an intermediate
If your Agent ended SMB by sending a final |
Messaging protocol complete (success). |
| 8 | Messaging protocol has failed due to a SIF_Status/SIF_Code of
8 (ZIS is asleep) or 7 (your Agent sent a duplicate SIF_MsgId). |
Messaging protocol complete (failure). |
| 9 | Messaging protocol has failed due to a SIF_Error
condition. See Error Codes with
SIF_Category and SIF_Code, and examine SIF_Desc and SIF_ExtendedDesc,
if included. |
Messaging protocol complete (failure). |
This section documents how Agents should respond to incoming messages, and the resulting post-conditions upon success or failure, along with any necessary steps to take.
Note that in handling any SIF_Message, an Agent may return a SIF_Ack with
SIF_Status/SIF_Code 8 (receiver is sleeping) or 7 (already
have this SIF_MsgId from you) if a duplicate message is detected. These responses are typically omitted from the handling protocols below.
Upon receipt of a generic message from the ZIS, in most cases it may be safely assumed that the message XML is well-formed, and perhaps even valid, but the Agent should take the following steps to determine whether the XML is well-formed, optionally validate the message, and check that the message is of a valid type before handing the message off to the respective message handling protocol below.
| Step | Process | Flow Control |
| 1 | If your transport layer implementation rejects XML that is not well-formed and optionally that is invalid, go to Step 3, 5, 7 or 9 depending on the extent of that implementation. Otherwise, is the XML message well-formed? | If yes, go to step 3. |
| 2 | Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. If your Agent can scan the incoming message as UTF-8 encoded text to locate SIF_Header/SIF_SourceId
and SIF_Header/SIF_MsgId, these values can be placed in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Otherwise include these elements with empty values, including an xsi:nil attribute value of
true on SIF_OriginalMsgId. Include a SIF_Error element with a SIF_Category
of 1 (XML Validation) and a SIF_Code of 2 (message is not well-formed). |
Go to step 12. |
| 3 | Is the root element of the message unprefixed with a local name of SIF_Message? |
If yes, go to step 5. |
| 4 | Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Error element with a SIF_Category
of 1 (XML Validation) and a SIF_Code of 3 (generic validation error). |
Go to step 12. |
| 5 | Is the namespace for SIF_Message a namespace of a major version of SIF your Agent supports? Is
SIF_Message/@Version present with a value that your Agent supports? (If omitted, interpret
SIF_Message/@Version as 1.1.) |
If yes, go to step 7. |
| 6 | Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Error element with a SIF_Category
of 12 (Generic Message Handling) and a SIF_Code of 3 (version not supported). |
Go to step 12. |
| 7 | If your Agent does not validate messages, go to step 9. Otherwise choose a validation schema based
on the value of SIF_Message/@Version. Does the message validate? |
If yes, go to step 9. |
| 8 | Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Error element with a SIF_Category
of 1 (XML Validation) and an appropriate SIF_Code from the corresponding choices in
Error Codes. |
Go to step 12. |
| 9 | If the namespace for SIF_Message is for a previous major version of SIF, handle according to
the specification for SIF_Message/@Version. Otherwise, is the message type (the child element of SIF_Message)
SIF_Event, SIF_Request,
SIF_Response, SIF_Ping (Push-mode only), SIF_Sleep (Push-mode only),
SIF_Wakeup (Push-mode only), or SIF_CancelRequests (Push-mode only and your Agent chooses
to support this optional message)? |
If yes, go to step 11. |
| 10 | Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Error element with a SIF_Category
of 12 (Generic Message Handling) and a SIF_Code of 2 (message not supported). |
Go to step 12. |
| 11 | Process per the corresponding message handling protocol below. | Message handling is complete. |
| 12 | If your Agent is a Push-mode Agent, return the SIF_Ack to the ZIS. If your Agent is a Pull-mode
Agent send the SIF_Ack to the ZIS per SIF_Ack (Pull-Mode) above. |
Message handling is complete. |
A ZIS places a SIF_Event in your Agent's queue when an event occurs in a Zone Context with regard to an
object for which your agent
has subscribed to receive events. A SIF_Event is delivered when it is the next message pending delivery
in the queue.
An event may apply to one or more contexts; these are listed in SIF_Header/SIF_Contexts.
If SIF_Contexts is not present, the context for the event is SIF_Default.
The type of event is specified in SIF_EventObject/@Action, the corresponding data object is in SIF_EventObject.
A Change or Delete event may contain a partial object, but it must include the necessary attribute(s) and element(s)
to uniquely identify the object being changed or deleted. These keys/identifiers are typically communicated in the root attributes of
an object.
| Step | Process | Flow Control |
| 1 | Does your Agent invoke Selective Message Blocking (SMB) for all events, or does this event indicate to your Agent that it will invoke SMB? | If no, go to Step 3. |
| 2 |
Prepare a
If your Agent is a Push-Mode Agent, return the
If your Agent is a Pull-Mode Agent, send the If an error occurs, it is RECOMMENDED
that your Agent publish a |
Message handling complete. |
| 3 |
If your Agent is a Pull-Mode Agent, process the event per your Agent's business rules. When complete or if an error occurs,
acknowledge the message and remove it from your Agent's queue per If your Agent is a Push-Mode Agent, it has one of two options: process the event, then acknowledge it; or acknowledge the event, then process it. The advantage of first processing the event is the ability to return a descriptive error, if necessary, to the ZIS when acknowledging the message. The disadvantage of first processing is that if the processing is long running, the connection from the ZIS to your Agent may time out, which will lead to the event being redelivered to your Agent in another delivery attempt, to possibly run into another time-out. To avoid the latter, it is RECOMMENDED that your Push-Mode Agent first acknowledge the event, then process it, unless event processing is known to always occur within a reasonable amount of time. Agents that first acknowledge then process SHOULD persist the event locally until processing is complete, as the event is removed from your Agent's queue upon successful acknowledgement, otherwise the event will be lost in the case of an application or system error that affects your Agent's ability to complete processing of the event.
Choose an option and process the event according to your Agent's business rules. When acknowledging:
Prepare a
If an error occurs regardless of the option chosen, it is RECOMMENDED
that your Agent publish a |
Message handling complete |
A ZIS places a SIF_Request in your Agent's queue when an Agent sends a request directly to your Agent,
or when an Agent sends a request without a SIF_DestinationId and your agent is registered as the Provider
for the object requested in SIF_Query, or in the case of SIF_ExtendedQuery when your agent is registered
as the Provider of the object specified by the Requester in SIF_ExtendedQuery/SIF_DestinationProvider or
SIF_ExtendedQuery/SIF_From/@ObjectName. The ZIS will not send your Agent a SIF_ExtendedQuery
unless your Agent has registered its support for that query type using SIF_Provide or SIF_Provision.
A SIF_Request is delivered when it is the next message pending delivery
in your Agent's queue.
Any error that occurs while generating SIF_Responses
during SIF_Request handling MUST be sent to the Requester
with SIF_MorePackets set to No, at which point the response stream ends.
| Step | Process | Flow Control |
| 1 | Examine SIF_Header/SIF_Contexts to determine the context for the request; if none is specified, the context
is SIF_Default. |
Go to Step 3 if the context is supported. |
| 2 |
Prepare a Add a Add Send the |
Message handling complete. |
| 3 | Examine the SIF_Version element or elements specified in the SIF_Request message. If more than one version is supported, select
the highest version number supported. |
Go to Step 5 if a version is supported. |
| 4 |
Prepare a Add a Add Send the |
Message handling complete. |
| 5 | Examine the SIF_MaxBufferSize specified in the SIF_Request message. |
Go to Step 7 if it is greater than or equal to the minimum buffer size your Agent can support. (The buffer size of individual packets will be handled below). |
| 6 |
Using the SIF version selected in Step 1, prepare a Add a Add Send the |
Message handling complete. |
| 7 | Is SIF_ExtendedQuery specified? |
If yes, go to Step 10. |
| 6 | The query type is SIF_Query. Examine the object name being queried in SIF_QueryObject/@ObjectName. |
Go to Step 8 if the object is supported. |
| 7 |
Prepare a Add a Add Send the |
Stop processing the message. |
| 8 | Examine the query represented, if any, by SIF_ConditionGroup, or SIF_Example in the case of objects that support query-by-example, and determine whether it is supported. |
Go to Step 12 if neither SIF_ConditionGroup nor SIF_Example is present,
or if the query represented by SIF_ConditionGroup or SIF_Example is supported. |
| 9 |
Prepare a Add a Add Send the |
Stop processing the message. |
| 10 | Examine the query represented by SIF_ExtendedQuery, and determine whether it is supported.
|
Go to Step 12 if the query is supported. |
| 11 |
Prepare a Add a Add Send the |
Stop processing the message. |
| 12 |
Note that Push-Mode Agents should acknowledge receipt of the If a Push-Mode Agent elects to successfully acknowledge the request before processing, it can do so. Otherwise it should acknowledge receipt of the request upon completion of response generation. Pull-Mode Agents can choose to acknowledge receipt of the request here or at the end of response generation. Initialize packet counter to 1. |
|
| 13 | Prepare a SIF_Response message with SIF_DestinationId set to SIF_SourceId and SIF_RequestMsgId set to SIF_MsgId from the SIF_Request message.
When handling SIF_ExtendedQuery, copy the requested columns into SIF_ExtendedQueryResults/SIF_ColumnHeaders. |
|
| 14 | Add one or more of the matching objects into SIF_ObjectData, for SIF_Query, or rows into SIF_ExtendedQueryResult, for SIF_ExtendedQuery,
until no more will fit within the specified buffer size.
If no objects or rows will fit within SIF_MaxBufferSize, go to Step 15 with the SIF_Error/SIF_Category set to indicate
Request and Response and SIF_Error/SIF_Code and SIF_Error/SIF_Desc to indicate that SIF_MaxBufferSize cannot be honored.
Otherwise, note that only requested columns are returned when processing SIF_ExtendedQuery. When processing SIF_Query, if the requester specified only
certain elements be returned, that the Responder needs to return only those elements and their parent elements and attributes. Not supporting
a requested element/attribute does not exclude the object from the response stream; include the parent elements/attributes of any missing elements,
including the object itself.
|
If no errors occur in retrieving/adding matching objects, go to step 16. |
| 15 | Set SIF_PacketNumber to the current packet counter and SIF_MorePackets to No.
Add an appropriate SIF_Error element to the SIF_Response and send the SIF_Response to the ZIS. |
Go to Step 19. |
| 16 | Set SIF_PacketNumber to the current packet counter value and set SIF_MorePackets appropriately. Send the SIF_Response to the ZIS. |
|
| 17 | Examine the SIF_Ack returned by the ZIS. |
If an error occurred, stop processing the SIF_Request message. Go to Step 19. |
| 18 | Determine if more objects or rows match the specified conditions. | If yes, increment the packet counter and go to Step 13; otherwise, go to Step 19. |
| 19 | If your Agent has not yet acknowledged receipt of the incoming request, acknowledge successful receipt of the request, or return a descriptive error to the ZIS. | Message handling complete. |
A ZIS places a SIF_Response in your Agent's queue when a responder sends a response packet to your Agent
per a SIF_Request previously sent by your Agent. It is delivered when it is the next message available for
delivery to your Agent.
| Step | Process | Flow Control |
| 1 |
SIF_RequestMsgId indicates which of your SIF_Requests this packet is in response to. Is
SIF_Error present?
|
If no, go to Step 3. |
| 2 |
The Responder's handling of your Agent's If your Agent is a Pull-Mode Agent, acknowledge the message per
If your Agent is a Push-Mode Agent: Prepare a |
Message handling complete. Any resources associated with the request can be released. |
| 3 |
If your Agent is a Pull-Mode Agent, process the response per your Agent's business rules. When complete or if an error occurs,
acknowledge the message and remove it from your Agent's queue per If your Agent is a Push-Mode Agent, it has one of two options: process the response, then acknowledge it; or acknowledge the response, then process it. The advantage of first processing the response is the ability to return a descriptive error, if necessary, to the ZIS when acknowledging the message. The disadvantage of first processing is that if the processing is long running, the connection from the ZIS to your Agent may time out, which will lead to the response being redelivered to your Agent in another delivery attempt, to possibly run into another time-out. To avoid the latter, it is RECOMMENDED that your Push-Mode Agent first acknowledge the response, then process it, unless response processing is known to always occur within a reasonable amount of time. Agents that first acknowledge then process SHOULD persist the response locally until processing is complete, as the response is removed from your Agent's queue upon successful acknowledgement, otherwise the response will be lost in the case of an application or system error that affects your Agent's ability to complete processing of the response.
Choose an option and process the response according to your Agent's business rules. When acknowledging:
Prepare a
If an error occurs regardless of the option chosen, it is RECOMMENDED
that your Agent publish a |
Message handling complete. If SIF_MorePackets is No, this is the last packet associated with the request
your Agent will receive; any resources associated with the request can be released.
|
The ZIS is pinging your Agent to see if it is reachable, "awake" and/or processing messages.
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. If your Agent is "awake," include a SIF_Status element with a SIF_Code
of 1 (immediate SIF_Ack). Otherwise you may optionally notify the ZIS that
your Agent is asleep by returning a SIF_Code of 8 (receiver is sleeping).
|
|
| 2 |
Return the SIF_Ack to the ZIS.
|
Message processing complete (success). |
The ZIS has changed its state to "asleep" and is either not processing incoming messages or all incoming messages
will be acknowledged with a SIF_Ack/SIF_Status/SIF_Code value of 8 (receiver is sleeping); delivery of
queued messages to your Agent is halted. Your
Agent SHOULD avoid sending messages to the ZIS until receipt of a SIF_Wakeup message,
or be prepared to handle transport errors or the aforementioned acknowledgement.
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Status element with a SIF_Code
of 1 (immediate SIF_Ack). Change your Agent's ZIS state to "asleep."
|
|
| 2 |
Return the SIF_Ack to the ZIS.
|
Message processing complete (success). |
The ZIS has changed its state to "awake" and is processing incoming messages and delivering queued messages again.
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Status element with a SIF_Code
of 1 (immediate SIF_Ack). Change your Agent's ZIS state to "awake."
|
|
| 2 |
Return the SIF_Ack to the ZIS.
|
Message processing complete (success). |
A ZIS is requesting that your Agent cancel processing of one or more SIF_Request messages. Support
for handling of this message is currently optional for Push-Mode Agents. If your Agent does not support
SIF_CancelRequests, it returns a Generic Message Handling error upon receipt of the SIF_SystemControl
message, error code "Message not supported," per the
SIF_Message handling protocol.
| Step | Process | Flow Control |
| 1 |
Prepare a SIF_Ack message with
SIF_Header containing a new GUID in SIF_MsgId,
your Agent's Agent ID in SIF_SourceId and the current time in SIF_Timestamp; other SIF_Header
elements do not apply. Place the incoming SIF_Header/SIF_SourceId and SIF_Header/SIF_MsgId
in SIF_OriginalSourceId and SIF_OriginalMsgId,
respectively. Include a SIF_Status element with a SIF_Code
of 1 (immediate SIF_Ack).
|
|
| 2 |
If your Agent is currently preparing SIF_Response packets for any of the SIF_Request messages
specified in the SIF_RequestMsgId element(s), stop processing the request(s). If your Agent
has any of the specified SIF_Requests queued locally, remove them from the agent local queue.
|
|
| 3 |
Return the SIF_Ack to the ZIS.
|
Message processing complete (success). |
This section documents how Zone Integration Servers send individual messages, and the resulting post-conditions upon success or failure, along with any necessary steps to take. These correspond to each of the actions a Zone Integration Server can initiate.
A ZIS contacts a Push-Mode Agent to deliver SIF_Event, SIF_Request
and SIF_Response messages queued for the Agent. This delivery protocol starts
with a check on whether there are messages pending, as the protocol can loop as messages are delivered.
| Step | Process | Flow Control |
| 1 | Are there messages queued for the Agent? | If yes, go to Step 2. Otherwise messaging protocol complete (success). |
| 2 |
Is the state of the Agent "asleep?" If yes, the ZIS SHOULD
wait until the Agent sends a SIF_Wakeup message or re-registers in Push mode before attempting
message delivery. Otherwise the ZIS MUST
be prepared to handle transport errors/exceptions and/or the Agent responding with a SIF_Status/SIF_Code
of 8 (receiver is sleeping).
|
If no, go to Step 3. Otherwise messaging protocol complete (success). |
| 3 | Has the Agent previously invoked SMB? | If no, go to Step 6. |
| 4 |
Iterate through the Agent's queue from the message received first to the most
recently received message. Stop at the first SIF_Response or
SIF_Request in the queue, if one exists.
|
If one exists, it is the next message to be delivered. Go to Step 7. |
| 5 |
The only messages queued for the Agent are SIF_Events; try again later, or after a SIF_Response or
SIF_Request arrives, or after the Agent has ended SMB by sending a final SIF_Ack.
|
Messaging protocol complete (no message needs to be delivered). |
| 6 | The next message to be delivered is the message received first in the Agent's queue. | |
| 7 |
Is SIF_Header/SIF_Security present in the SIF_Message
with SIF_EncryptionLevel,
SIF_AuthenticationLevel, or both?
|
If no, the message delivery encryption/authentication levels are the minimum encryption/authentication levels set up for the Zone. Go to Step 9. |
| 8 | The ZIS MUST guarantee that the minimum encryption and/or authentication levels specified are respected when delivering this message. Use the higher of these and the Zone's minimum encryption and/or authentication levels during message delivery. | |
| 9 | If a connection is already open to the Push-Mode Agent from a previously delivered message, are the encryption and authentication levels greater than or equal to those needed for the delivery of this message? | If there is no connection open, go to Step 11. If there is and the encryption/authentication levels are adequate for delivery, go to Step 13. |
| 10 | Attempt to renegotiate the encryption/authentication levels for the connection, or close the connection and attempt to open a new connection with adequate encryption/authentication levels. | Go to Step 12. |
| 11 | If the registered transport layer is known to not provide adequate encryption/authentication levels (e.g. SIF HTTP), go to Step 12. Otherwise attempt to open a connection to the Agent with adequate encryption/authentication levels, using the appropriate transport layer. | |
| 12 |
Was a connection opened or renegotiated with adequate encryption/authentication levels?
If no, the message cannot be delivered; remove it from the Agent's queue. It is RECOMMENDED
that your ZIS log the error. Your ZIS MUST post a SIF_LogEntry
Add event with the appropriate error category and code, containing a copy of the SIF_Header
of the queued message. SIF_LogEntry/SIF_Desc MUST contain
the SIF_SourceId of the Agent that failed to receive the message.
|
Go to Step 1 to start delivery of the next queued message, if desired. Otherwise messaging protocol complete (error). |
| 13 | Send the message to the Agent over the connection. | |
| 14 |
Receive SIF_Ack in response.
Is SIF_Error present?
|
If yes, go to Step 24. |
| 15 |
Is SIF_Status/SIF_Code 1 (immediate SIF_Ack)?
|
If no, go to Step 17. |
| 16 | The Agent has successfully acknowledged receipt of the message; remove it from the Agent's queue. | Go to Step 1 to start delivery of the next queued message, if desired. Otherwise messaging protocol complete (success). |
| 17 |
Is SIF_Status/SIF_Code 2 (intermediate SIF_Ack)?
|
If no, go to Step 21. |
| 18 |
The Agent is invoking SMB. Is the delivered message a SIF_Event?
|
If yes, go to Step 20. |
| 19 |
The Agent has violated protocol; remove the message from the Agent's queue. It is RECOMMENDED
that your ZIS log the error. Your ZIS MUST post a SIF_LogEntry
Add event with the appropriate error category of 13 (SMB Error)
and code 2 (SMB can only be invoked for SIF_Event), containing a copy of the SIF_Header
of the queued message. SIF_LogEntry/SIF_Desc MUST contain
the SIF_SourceId of the Agent that committed the protocol error.
|
Go to Step 1 to start delivery of the next queued message, if desired. Otherwise messaging protocol complete (error). |
| 20 |
The Agent has invoked SMB on this SIF_Event. Persist that the Agent has invoked SMB along with
the SIF_MsgId of the event. The event stays in the agent's queue as blocked, and all other events
are frozen until the Agent eventually ends SMB by sending a final SIF_Ack
with this SIF_MsgId in SIF_OriginalMsgId, or by sending a SIF_Wakeup or
by re-registering.
|
Go to Step 1 to start delivery of the next queued message, if desired. Otherwise messaging protocol complete (success). |
| 21 |
Is SIF_Status/SIF_Code 8 (receiver is sleeping)?
|
If no, go to Step 23. |
| 22 | The Agent is asleep. Re-attempt delivery later. | Messaging protocol complete (success). |
| 23 |
Messaging protocol has failed due to a SIF_Status/SIF_Code of
7 (already have this SIF_MsgId). The ZIS cannot correct this, as the SIF_MsgId
originates from an Agent and can't be changed without other repercussions. Remove the message from
the Agent's queue. It is RECOMMENDED
that your ZIS log the error. Your ZIS MUST post a SIF_LogEntry
Add event with the appropriate error category and code, containing a copy of the SIF_Header
of the queued message. SIF_LogEntry/SIF_Desc MUST contain
the SIF_SourceId of the Agent that did not receive the message.
|
Go to Step 1 to start delivery of the next queued message, if desired. Otherwise messaging protocol complete (error). |
| 24 |
Messaging protocol has failed due to a SIF_Error
condition. See Error Codes |