Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5049
Yes
(Magnus Westerlund)
No Objection
Lars Eggert
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 08 and is now closed.
Lars Eggert
No Objection
Magnus Westerlund Former IESG member
Yes
Yes
()
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
()
Cullen Jennings Former IESG member
No Objection
No Objection
(2007-07-15)
I think the ABNF might be better as via-sip-sigcomp-id = "sigcomp-id" EQUAL quoted-string
Dan Romascanu Former IESG member
No Objection
No Objection
()
David Ward Former IESG member
(was Discuss)
No Objection
No Objection
()
Jari Arkko Former IESG member
No Objection
No Objection
()
Jon Peterson Former IESG member
No Objection
No Objection
()
Lisa Dusseault Former IESG member
No Objection
No Objection
(2007-06-05)
I'm glad the authors thought carefully about the Identifier Comparison Rules (section 9.2), but I'm worried this could still be a can'o'worms. One problem could be with URNs that may also be IRIs. If the original URN has extended characters, they can get canonicalized or otherwise changed in transit, and then the comparison may not work even though the generating application always initially provides the same URN. Is it still possible to limit the kinds of identifiers? Perhaps recommend UUID URNs at a SHOULD level and note the difficulties in equality comparisons for other kinds of URNs?
Mark Townsley Former IESG member
No Objection
No Objection
()
Ron Bonica Former IESG member
No Objection
No Objection
()
Ross Callon Former IESG member
No Objection
No Objection
()
Russ Housley Former IESG member
No Objection
No Objection
()
Sam Hartman Former IESG member
No Objection
No Objection
()
Tim Polk Former IESG member
No Objection
No Objection
(2007-07-18)
The Security Considerations section indicates that keeping SigComp states does not pose additional security risks for two reasons. I believe the second reason, "b) this is on a voluntary basis and a SigComp endpoint can choose not to offer it" is irrelevant. I suggest deleting b).