< 上一个 | 内容 | 下一个 >

‌8.7 Subscription/Notification function set‌

8.7.1 Overview

This subclause describes the design and use of resources that support a generic, lightweight Subscription/Notification mechanism for use throughout the standard. This mechanism may be useful when a client wishes to quickly learn of changes to a resource on a server.

The following text further clarifies the roles of the Subscription and Notification resources.

8.7.2 List ordering

Notification resources typically are not exposed to other devices on the network, but devices that do choose to expose the resource(s) MUST obey the list ordering rules below.

Table 24 —Subscription/Notification list ordering

8.7.3 Application guidelines/behavior

8.7.3.1 Subscription resource

A Subscription resource is realized as a resource for an individual client, providing interfaces to all Subscriptions for the given client. A server indicates support of Subscriptions for a given resource with the subscribable attribute of that resource.

8.7.3.2 Notification resource

The Notification resource is used to receive Notifications that a resource to which a host is subscribed has changed. The location of the Notification resource is passed to the Subscription server in the body of the Subscription. As such, a given client (Notification resource server) may have one Notification resource for

multiple different Notifications or may have a different Notification resource for different Notifications. The resource representation returned in a Notification SHALL be identical to that which would be returned via a GET request to the resource, subject to the limit parameter discussed below, and per the rules stated earlier in this standard for representing resources.

While some Notification servers (Subscription clients) may support reusing a TLS connection as a client for Notifications, this mechanism is not reliable as a TLS session may have ended. Notification servers (Subscription clients) SHALL support TLS as a server if they wish to receive secure Notifications.

8.7.3.3 Conditional Subscription/report by exception

If allowed by the specific function set, some resources can have conditional Subscriptions to enable a report by exception capability. The following conditions are allowed and are specified in the Subscription:

 Lower threshold: Used to cause a Notification when the resource’s value is below the given value.

 Upper threshold: Used to cause a Notification when the resource’s value is above the given value.

Note, both an upper threshold and a lower threshold may be specified for a given Subscription. If both an upper threshold and a lower threshold are specified, the upper threshold SHALL be greater than the lower threshold, otherwise an error representation SHALL be returned.

If neither a lower threshold nor an upper threshold is specified, then a server SHALL send a Notification whenever the resource to which the client is subscribed changes. If a lower threshold and/or an upper threshold are specified, then a server SHALL send a Notification whenever the appropriate value crosses (in either direction) the appropriate threshold for the resource to which the client is subscribed. Servers that support Subscriptions to a given resource MAY support conditional Subscriptions to that resource.

For a given resource, to determine the attribute on which the conditions apply, the attributeIdentifier attribute is used.

8.7.3.4 Subscription rules

A Subscription renewal is a Subscription to the same resource from the same client, regardless of Subscription parameters.

a) Clients SHOULD send Subscription renewals every 24 hours, and no more often than every 1 hour, to sustain a Subscription.

b) Servers MAY remove Subscriptions at any time.

c) Servers SHOULD remove Subscriptions if a client has not renewed in 36 hours.

d) Subscriptions SHALL be maintained on servers through power loss.

e) Servers SHALL use the Subscription parameters from the latest Subscription renewal.

f) Clients SHOULD check the status of their Subscriptions after perceived loss of connectivity.

g) Following recovery from a perceived loss of connectivity, clients SHOULD poll their resources of interest (including those to which they are subscribed) in case those resources changed during the loss of connectivity.

h) If the URI of a resource changes, then Subscriptions to that resource SHALL be terminated.

i) For Subscriptions to non-list resources, a Notification SHALL be sent whenever the representation of the non-list resource changes. If a resource contains a link, changes to the attributes of the link

(e.g., the “all” attribute of a ListLink) are not considered changes to the representation of the resource and therefore do not trigger a Notification.

j) For Subscriptions to list resources, a Notification SHALL be sent whenever any subordinate resources are added to or removed from the list, or if the representation of those subordinate resources change. If a subordinate resource contains a link, changes to the attributes of the link (e.g., the “all” attribute of a ListLink) are not considered changes to the representation of the subordinate resource and therefore do not trigger a Notification. As a result, if a client is subscribed to both an event and a list containing that event, the client will receive two Notifications should that event change. See 4.7 for more information.

1) It should be noted that Notifications for list resources are an exception where certain list attributes are included (e.g., all and results) that would normally not be present when a list resource is provided in a POST.

k) To prevent overwhelming network resources, Notifications SHOULD be sent to a given client for a given resource no more than once every 30 seconds. Notifications for conditional Subscriptions SHOULD only be sent once within this time period for a given client for a given resource and any additional Notifications SHOULD NOT be queued. All devices need to be considerate of network resources. Note that, as a consequence of this rule, Notifications will not be sent for each change of a resource or threshold crossing.

l) Servers implementing the Subscription resource SHALL be capable of maintaining a minimum of one Subscription and servers implementing the Subscription resource SHOULD support at least one Subscription per device per subscribable resource.

m) If a server implementing the Subscription resource is unable to accept a Subscription, the server SHALL return an error resource representation indicating the specific error (e.g., element does not support conditional Subscription) with an HTTP response code of 400.

n) When a server removes or terminates a Subscription, it SHALL send the client a terminate Subscription (except after an error from an undesired Subscription, as mentioned in Rule o) below). The server SHALL send a Notification to the client’s “Post URI” for the affected Subscription. The Resource contained in the Notification SHALL be a Subscription, containing a Status element identifying the reason for terminating the Subscription. When a Subscription is terminated because the subscribed resource has moved, servers MAY include newResourceURI in the Subscription termination message, indicating the resource’s new location.

‌o) If a client receives a Notification for an undesired Subscription, the client SHALL return an HTTP 400 error. Upon receipt of such an error, the server SHALL remove the Subscription without Notification.

p) Servers SHOULD allow only the end device that corresponds to a given EndDevice resource to modify the Subscriptions within that resource.

q) The default recommended policy is that Subscription management SHOULD be performed using TLS.

8.7.4 LogEvents

Table 25 —Subscription/Notification LogEvents

< 上一个 | 内容 | 下一个 >