MIME types are included in an accept header sent in a SUBSCRIBE message Notifications contain a multipart document, the first part of which always contains meta-information about the list. Remaining parts are used to convey the actual state of the resources listed in the meta-information. The "state" attribute of each instance of a resource in the meta-information is set according to the state of the virtual subscription. When sending infor- mation in a terminated resource instance, the RLS indicates a state of "ter- minated" and an appropriate reason value. When the first SUBSCRIBE message for a particular subscription is received by a RLS, the RLS will often not know state information for all of the resources specified by the resource list. For any resource for which state information is not known, the corresponding "uri" attribute will be set appropriately, and no(instance) elements will be present for the resource. Immediate notifications triggered as a result of subsequent SUBSCRIBE messages SHOULD include an RLMI document with full state indicated. The XML document present in the root of the multipart/related document contains a <resource> element for some or all of the resources in the list. Each <resource> element contains a URI that uniquely identifies the resource to which that section corresponds. When a NOTIFY arrives, it can contain full or partial state (as indicated by the "fullState" attribute of the top-level <list> element). If full state is indicated, then the recipient replaces all states associated with the list with the entities in the NOTIFY body. If full state is not indicated, the recipient of the NOTIFY updates information for each identified resource. Information for any resources that are not identified in the NOTIFY are not changed, even if they were indicated in previous NOTIFY messages. 5.5.4 Resource List Attributes In order to convey the state of multiple resources, the list extension uses the "multipart/related" mime type. The root document of the multipart/related body is a Reso