Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5049

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

Magnus Westerlund Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

Comment (2007-06-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?

(Lars Eggert) No Objection

(Sam Hartman) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

Comment (2007-07-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think the ABNF might be better as 
   via-sip-sigcomp-id = "sigcomp-id" EQUAL quoted-string

(Chris Newman) (was Discuss) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

Comment (2007-07-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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).

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) (was Discuss) No Objection