A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
RFC 4662

Note: This ballot was opened for revision 07 and is now closed.

(Steven Bellovin) Discuss

Discuss (2004-11-03 for -)
7.1: there is no standardized mechanism to upload a necessary shared 
secret.  There needs to be a mandatory-to-implement scheme.t of the 
user before transferring such secrets.

(Allison Mankin) Yes

(Harald Alvestrand) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-08-31 for -)
No email
send info
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.

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2004-08-30)
No email
send info
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" />

(Russ Housley) (was Discuss) No Objection

Comment (2004-09-01)
No email
send info
  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.

(David Kessens) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

Comment (2004-09-02 for -)
No email
send info
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.

(Bert Wijnen) No Objection

(Alex Zinin) No Objection