an appropriate mechanism for the problem set? Is SIP being selected because of some unique feature provided by the protocol (e.g., user mobility) or merely because "it can be done"? If you find yourself defining event packages for notifications related to, for example, network management or the temperature inside your car's engine, you may want to reconsider your selection of protocols. Those interested in extending the mechanism defined in this document are urged to follow the development of "Guidelines for Authors of SIP Extensions" [RFC4485] for further guidance regarding appropriate uses of SIP. Further, it is expected that this mechanism is not to be used in applications where the frequency of reportable events is excessively rapid (e.g., more than about once per second). A SIP network is generally going to be provisioned for a reasonable signaling volume; sending a notification every time a user's GPS position changes by one hundredth of a second could easily overload such a network.
For example: consider a theoretical event template-package called "list". The event "presence.winfo.list" would be the application of the "list" template to "presence.winfo", which would presumably be a list of winfo state associated with presence. On the other hand, the event "presence.list.winfo" would represent the application of winfo to "presence.list", which would be represent the winfo state of a list of presence information. Event template-packages must be defined so that they can be applied to any arbitrary package. In other words, event template-packages cannot be specifically tied to one or a few "parent" packages in such a way that they will not work with other packages.
Section 7. RFC3968]. An "Event" header field parameter, once registered in conjunction with an event package, MUST NOT be reused with any other event package. Non-event-package specifications MAY define "Event" header field parameters that apply across all event packages (with emphasis on "all", as opposed to "several"), such as the "id" parameter defined in this document. The restriction of a parameter to use with a single event package only applies to parameters that are defined in conjunction with an event package. RFC4288] for information on media type specification and registration. This mandatory section of an event package defines what type or types of event bodies are expected in SUBSCRIBE requests (or specify that no event bodies are expected). It should point to detailed definitions of syntax and semantics for all referenced body types.
Section 5.3. Such a section is required. This section may optionally describe the behavior used to process the subsequent response.
matching "To", "From", "Call-ID", and "Event" header fields, as well as "From" header field "tag" parameter and "Event" header field "id" parameter) but that do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE request can arrive after a matching NOTIFY request has been received; such responses might not correlate to the same dialog established by the NOTIFY request. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored. If installing of multiple subscriptions by way of a single forked SUBSCRIBE request is allowed, the subscriber establishes a new dialog towards each notifier by returning a 200-class response to each NOTIFY request. Each dialog is then handled as its own entity and is refreshed independently of the other dialogs. In the case that multiple subscriptions are allowed, the event package MUST specify whether merging of the notifications to form a single state is required, and how such merging is to be performed. Note that it is possible that some event packages may be defined in such a way that each dialog is tied to a mutually exclusive state that is unaffected by the other dialogs; this MUST be clearly stated if it is the case. RFC3903], by subscribing to state information, or through other state-gathering mechanisms. Event packages that involve retrieval of state information for a single resource from more than one source need to consider how notifiers aggregate information into a single, coherent state. Such packages MUST specify how notifiers aggregate information and how they provide authentication and authorization.
RFC4483] defines a mechanism that can be used by event packages to convey information in such a fashion.
Individual packages and their related documents for which such a mode of operation makes sense can further describe how and why to generate such potentially correct data. For example, such a mode of operation is mandated by [RFC2779] for user presence information. CERT1998a]. Also, the creation of state upon receipt of a SUBSCRIBE request can be used by attackers to consume resources on a victim's machine, rendering it unusable. To reduce the chances of such an attack, implementations of notifiers SHOULD require authentication. Authentication issues are discussed in [RFC3261]. RFC3261].
request bodies are used to define further information about the state of the call, they SHOULD be included in the integrity protection scheme. Man-in-the-middle attacks may also attempt to use NOTIFY requests to spoof arbitrary state information and/or terminate outstanding subscriptions. To prevent such attacks, implementations SHOULD provide integrity protection across the "Call-ID", "CSeq", and "Subscription-State" header fields and the bodies of NOTIFY requests. Integrity protection of message header fields and bodies is discussed in [RFC3261]. RFC3261]. Section 7.2, the subsections here are for current reference, carried over from the original specification (RFC 3265). IANA has updated all registry references that pointed to RFC 3265 to instead indicate this document and created the new "reason code" registry described in Section 7.2.
There are two different types of event-types: normal event packages and event template-packages; see Section 5.2. To avoid confusion, template-package names and package names share the same namespace; in other words, an event template-package is forbidden from sharing a name with a package. Policies for registration of SIP event packages and SIP event package templates are defined in Section 4.1 of [RFC5727]. Registrations with the IANA are required to include the token being registered and whether the token is a package or a template-package. Further, packages must include contact information for the party responsible for the registration and/or a published document that describes the event package. Event template-package token registrations are also required to include a pointer to the published RFC that defines the event template-package. Registered tokens to designate packages and template-packages are disallowed from containing the character ".", which is used to separate template-packages from packages.
Section 8.2.1.) Is this registration for a Template-Package: (indicate yes or no) Published specification(s): (Template-packages require a published RFC. Other packages may reference a specification when appropriate.) Person & email address to contact for further information: (self-explanatory) Section 4.1.3). Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], new reason codes require a Standards Action. Registrations with the IANA include the reason code being registered and a reference to a published document that describes the event package. Insertion of such values takes place as part of the RFC publication process or as the result of liaison activity between standards development organizations (SDOs), the result of which will be publication of an associated RFC. New reason codes must conform to the syntax of the ABNF "token" element defined in [RFC3261]. [RFC4660] defined a new reason code prior to the establishment of an IANA registry. We include its reason code ("badfilter") in the initial list of reason codes to ensure a complete registry. The IANA registry for reason codes has been initialized with the following values:
Reason Code Reference ----------- --------- deactivated [RFC6665] probation [RFC6665] rejected [RFC6665] timeout [RFC6665] giveup [RFC6665] noresource [RFC6665] invariant [RFC6665] badfilter [RFC4660] REFERENCES ---------- [RFC6665] A.B. Roach, "SIP-Specific Event Notification", RFC 6665, July 2012. [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "Functional Description of Event Notification Filtering", September 2006. http://www.iana.org/assignments/sip-parameters. Header Name: Allow-Events Compact Form: u Header Name: Subscription-State Compact Form: (none) Header Name: Event Compact Form: o http://www.iana.org/assignments/sip-parameters. Response Code Number: 202 Default Reason Phrase: Accepted Response Code Number: 489 Default Reason Phrase: Bad Event