Conference Event Package Data Format Extension for Centralized Conferencing (XCON)
Extracted elements (25)
Partial notifications were introduced because generating a full conference-state document for every small change is inefficient in bandwidth-constrained environments. The XML patch operations mechanism (RFC 5261) was chosen over the RFC 4575 <state>-based partial mechanism to allow finer-grained updates.
Backwards compatibility is achieved by requiring XCON-capable servers to also support the legacy 'application/conference-info+xml' MIME type, ensuring that legacy clients which only understand that format can still receive notifications.
Clients that support 'application/xcon-conference-info+xml' SHOULD also support 'application/conference-info+xml' to interoperate with legacy servers that only send the older format.
Conference servers that support 'application/xcon-conference-info+xml' MUST also support 'application/conference-info+xml' so that legacy clients can receive notifications in a format they understand.
If a subscriber encounters a processing error while processing an 'application/xcon-conference-info-diff+xml' document, it SHOULD renew its subscription; it can fall back by omitting the diff MIME type from the new SUBSCRIBE.
If the server changes from a non-diff content type to partial notifications, it MUST first deliver full state using 'application/xcon-conference-info+xml' before generating its first partial notification.
If the server changes the content type used in notifications within an existing subscription, the subscriber MUST discard all previously received information and process the new content as specified for that content type.
On receiving a subsequent 'application/xcon-conference-info+xml' notification, the subscriber MUST replace its local document copy entirely; on receiving an 'application/xcon-conference-info-diff+xml' notification, it MUST apply the indicated changes to its local copy.
Once a subscription is accepted and installed, the server MUST deliver full state in its first notification, setting Content-Type to 'application/xcon-conference-info+xml'.
Servers compliant with this specification MUST NOT use the partial notification mechanism based on <state> elements defined in RFC 4575. Instead, they MUST use the XML patch-based partial notification mechanism specified in Section 5.
The server MUST construct partial notifications so that added information is listed inside <add> elements, removed information inside <remove> elements, and changed information inside <replace> elements.
The server MUST NOT send a new NOTIFY with a partial notification until it has received a final response from the subscriber for the previous one, or the previous NOTIFY has timed out.
To deliver a partial notification, the server MUST set Content-Type to 'application/xcon-conference-info-diff+xml' and SHOULD only include information that has changed compared to the previous notification.
When a subscriber receives the first notification containing full state, it MUST store the received full document as its local copy.
When the server receives a SUBSCRIBE request (refresh or termination) within the associated subscription, it SHOULD send a NOTIFY containing the full document using 'application/xcon-conference-info+xml'.
A document in 'application/xcon-conference-info-diff+xml' format provides the subscriber with only the changes to conference state since the last notification, using XML patch operations (RFC 5261).
A document in 'application/xcon-conference-info+xml' format provides the subscriber with the complete state of a conference instance, following the XCON data model defined in RFC 6501.
The <conference-info-diff> element's mandatory 'entity' attribute holds the conference object identifier (XCON-URI) identifying the conference being described. Unknown extension elements from other namespaces MUST be ignored by the client.
The XCON notification mechanism reuses the SIP event package for conference state defined in RFC 4575, extended to carry XML documents in two new MIME formats: 'application/xcon-conference-info+xml' (full state) and 'application/xcon-conference-info-diff+xml' (partial updates).
This document registers the MIME type 'application/xcon-conference-info-diff+xml' for carrying partial XCON conference state updates (XML patch operations) in NOTIFY bodies.
This document registers the URN sub-namespace 'urn:ietf:params:xml:ns:xcon-conference-info-diff' for the partial notification XML namespace.
This document registers the XML schema 'urn:ietf:params:xml:schema:xcon-conference-info-diff' (the schema defined in Section 5.4) in the IETF XML registry per RFC 3688.
Encoding notifications in the new XCON formats does not introduce additional security implications beyond those of the underlying SIP event package. Implementers MUST follow the security considerations of RFC 4575 Section 8 regardless of the notification format used.
An xcon-conference-info-diff document is an XML document that MUST be well-formed and SHOULD be valid. The root element is <conference-info-diff> in namespace 'urn:ietf:params:xml:ns:xcon-conference-info' with a mandatory 'entity' attribute (XCON-URI string) and an unordered sequence of <add>, <replace>, and <remove> children.
The XML Schema for 'application/xcon-conference-info-diff+xml' (Section 5.4) extends RFC 5261 patch-ops types: <add>, <remove>, and <replace> elements each allow arbitrary additional attributes via xs:anyAttribute, and the root accepts any foreign-namespace elements for extensibility.