The Session Initiation Protocol (SIP) Pending Additions Event Package
Note: This ballot was opened for revision 05 and is now closed.
(Jon Peterson) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
Comment (2008-03-04 for -** No value found for 'p.get_dochistory.rev' **)
What is the purpose of registering the two XML schemas? - urn:ietf:params:xml:schema:consent-status - urn:ietf:params:xml:schema:resource-lists-diff it doesn't seem to provide any utility.
(Sam Hartman) No Objection
(Russ Housley) (was Discuss) No Objection
From David Black's Gen-ART review. In Secction 5.1.2: > > A SUBSCRIBE for Pending Additions events MAY contain a body. This > body would serve the purpose of filtering the subscription. The > definition of such a body is outside the scope of this specification. > How is that supposed to be interoperable? A better approach would be to prohibit bodies now and allow a future specification to define them.
(Cullen Jennings) No Objection
(Tim Polk) (was No Record, Discuss) No Objection
I suspect the RFC Editor would catch all of these, but I noticed a few nits. I have suggested changes, but please review to be sure I interpreted things correctly! Section 3, last sentence: s/experimented/experienced/ Section 8, para 2 first sentence: s/even package/event package/ Section 8, para 4 first sentence: s/confidentially/confidentiality/
(Dan Romascanu) No Objection
(David Ward) No Objection
Magnus Westerlund No Objection
Comment (2008-03-03 for -** No value found for 'p.get_dochistory.rev' **)
Section 5.1.9 states for congestion avoidance event notifications should not be sent more often then every 5 seconds. How well figured out is this number? Is this another SIP overload resulting mechanism? Will a general SIP overload mechanism effect also these notification transactions? I only want to make sure that this isn't digging a deeper hole for the guys that trying to get out of the existing SIP overload one.