Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5049
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Lars Eggert No Objection
(Magnus Westerlund; former steering group member) Yes
(Chris Newman; former steering group member) (was Discuss) No Objection
(Cullen Jennings; former steering group member) No Objection
I think the ABNF might be better as via-sip-sigcomp-id = "sigcomp-id" EQUAL quoted-string
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) (was Discuss) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
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 steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
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).