Purely editorial, but since the draft looks likely to be edited anyway, I believe it would 
be useful to clarify this statement in the Introduction:

   this specification defines an extension to
   RFC 3265 [2] that allows for requesting and conveying notifications
   for lists of resources.  A resource list is identified by a URI and
   it represents a list of zero or more URIs.  Each of these URIs is an
   identifier for an individual resource for which the subscriber wants
   to receive information.  In many cases, the URI will be a SIP URI
   [1]; however, the use of other schemes (such as pres: [9]) is also
   foreseen.


"the URI" in the final statement is ambiguous; a reader could conclude
that it meant the "resource list URI" or the "URI (which is) an identifier
for an individual resource.  Making it crystal clear would be good.

Section 5.4 says that 'This attribute contains one of the values "active", "pending", or "terminated"'.

This attribute definition in the schema could (should?) thus be defined as an enumeration to ensure that the allowable values are limited to those described in the text:

<xs:attribute name="state" type="xs:string" use="required" />

  Do you really use multipart/encrypted?  S/MIME does not use this
  MIME type.

  Section 6, number 11 references RFC 2633 for multipart/signed. I think
  this should reference RFC 1847 (security multiparts).

  Section 6, number 13 discusses "application/signed". I think that this
  should be "multipart/signed".

  Section 7.3 says that the initiator in an exchange will indicate support
  for encryption by saying "multipart/encrypted" or "multipart/signed."
  The exchange may not proceed if the policy for the listener indicates
  that encryption is required, but the initiator does not indicate support
  for encryption. Do you really use multipart/encrypted?  S/MIME does not
  use this MIME type.  Also, there are multiple ways to handle signing, so
  indicating "multipart/signed" precludes the use of the other approaches,
  especially "application/pkcs7-mime" used in S/MIME.

No further objection. I agree with Russ's comment about 'multipart/encrypted' - RFC3261 does not describe the use of that MIME type for SIP; it uses 'application/pkcs7-mime' for encrypted MIME bodies.