A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
Note: This ballot was opened for revision 07 and is now closed.
(Steven Bellovin) Discuss
Discuss (2004-11-03 for -** No value found for 'p.get_dochistory.rev' **)
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 value found for 'p.get_dochistory.rev' **)
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  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 ; however, the use of other schemes (such as pres: ) 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
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
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 value found for 'p.get_dochistory.rev' **)
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.