Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5049
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-11-30
|
08 | (System) | Closed request for Last Call review by SECDIR with state 'Unknown' |
2015-10-14
|
08 | (System) | Notify list changed from rohc-chairs@ietf.org, cabo@tzi.org, zhigang.c.liu@nokia.com, richard.price@cogent-dsn.com, Gonzalo.Camarillo@ericsson.com to richard.price@cogent-dsn.com |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for Chris Newman |
2012-08-22
|
08 | (System) | post-migration administrative database adjustment to the No Objection position for David Ward |
2007-12-14
|
08 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2007-12-14
|
08 | Amy Vezza | [Note]: 'RFC 5049' added by Amy Vezza |
2007-12-12
|
08 | (System) | RFC published |
2007-10-11
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2007-10-11
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2007-10-03
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-10-03
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-10-03
|
08 | Amy Vezza | IESG has approved the document |
2007-10-03
|
08 | Amy Vezza | Closed "Approve" ballot |
2007-10-03
|
08 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2007-10-03
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2007-10-03
|
08 | (System) | IANA Action state changed to In Progress |
2007-10-02
|
08 | David Ward | [Ballot Position Update] Position for David Ward has been changed to No Objection from Discuss by David Ward |
2007-09-26
|
08 | Chris Newman | [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman |
2007-09-20
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-09-20
|
08 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-08.txt |
2007-07-20
|
08 | (System) | Removed from agenda for telechat - 2007-07-19 |
2007-07-19
|
08 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2007-07-19
|
08 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-07-19
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2007-07-19
|
08 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2007-07-19
|
08 | Chris Newman | [Ballot discuss] This document should discuss how it interacts with RFC 3749 compression. When SIP-TLS is used, if both this and RFC 3749 are implemented, … [Ballot discuss] This document should discuss how it interacts with RFC 3749 compression. When SIP-TLS is used, if both this and RFC 3749 are implemented, which should be used for interoperability? draft-ietf-lemonade-compress has text resulting from Cullen's discuss on this topic. |
2007-07-19
|
08 | Chris Newman | [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman |
2007-07-18
|
08 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-07-18
|
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2007-07-18
|
08 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2007-07-18
|
08 | David Ward | [Ballot discuss] 3320 section 8.7 (Decompression failures) "If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes … [Ballot discuss] 3320 section 8.7 (Decompression failures) "If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application. " and in this draft there is no mention of how SIP should handle decompression failures. 2007.07.18: NOTE: I have been in contact w/ the authors and they agree to add wording to clear this up. From: Carsten Bormann Subject: sigcomp-sip: David Ward's DISCUSS Date: Wed, 18 Jul 2007 09:12:57 +0200 To: rohc@ietf.org ...snip ... " ...the discussion of NACK in the draft only relates to SigComp state; it could mention that NACK (now being mandatory) is the general way to handle decompression failure. All of this is editorial, I think, but I also think it would be nice not to entirely rely on the reader making the connections. Any opinions? I could go ahead and draft some text. Gruesse, Carsten " Most likely his text will clear my discuss. |
2007-07-18
|
08 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2007-07-18
|
08 | Tim Polk | [Ballot comment] The Security Considerations section indicates that keeping SigComp states does not pose additional security risks for two reasons. I believe the second reason, … [Ballot comment] 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). |
2007-07-18
|
08 | Tim Polk | [Ballot comment] The Security Considerations section indicates that keeping SigComp states does not pose additional security risks for two reasons. I believe the second reason, … [Ballot comment] 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). |
2007-07-17
|
08 | David Ward | [Ballot discuss] 3320 section 8.7 (Decompression failures) "If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes … [Ballot discuss] 3320 section 8.7 (Decompression failures) "If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application. " and in this draft there is no mention of how SIP should handle decompression failures. |
2007-07-17
|
08 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-07-17
|
08 | David Ward | [Ballot discuss] 3320 section 8.7 (Decompression failures) "If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes … [Ballot discuss] 3320 section 8.7 (Decompression failures) "If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application. " and in this draft there is no mention of how SIP should handle decompression failures in this doc. |
2007-07-17
|
08 | David Ward | [Ballot Position Update] New position, Discuss, has been recorded by David Ward |
2007-07-16
|
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-07-15
|
08 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2007-07-15
|
08 | Cullen Jennings | [Ballot comment] I think the ABNF might be better as via-sip-sigcomp-id = "sigcomp-id" EQUAL quoted-string |
2007-07-13
|
08 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2007-07-09
|
08 | Magnus Westerlund | Placed on agenda for telechat - 2007-07-19 by Magnus Westerlund |
2007-07-09
|
08 | Magnus Westerlund | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Magnus Westerlund |
2007-07-05
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-07-05
|
07 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-07.txt |
2007-06-26
|
08 | Magnus Westerlund | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Magnus Westerlund |
2007-06-05
|
08 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2007-06-05
|
08 | Lisa Dusseault | [Ballot comment] 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 … [Ballot comment] 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? |
2007-06-01
|
08 | Magnus Westerlund | Removed from agenda for telechat - 2007-06-07 by Magnus Westerlund |
2007-05-29
|
08 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-05-24
|
08 | Yoshiko Fong | IANA Last Call Comment: Action #1: Upon approval of this document, the IANA will make the following assignments in the "Session Initiation Protocol (SIP) Parameters" … IANA Last Call Comment: Action #1: Upon approval of this document, the IANA will make the following assignments in the "Session Initiation Protocol (SIP) Parameters" registry located at http://www.iana.org/assignments/sip-parameters sub-registry "Header Field Parameters and Parameter Values - per [RFC3968]" Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- Via sigcomp-id No [RFC-rohc-sigcomp- sip-06] Action #2: Upon approval of this document, the IANA will make the following assignments in the "Session Initiation Protocol (SIP) Parameters" registry located at http://www.iana.org/assignments/sip-parameters sub-registry "SIP/SIPS URI Parameters - per [RFC3969]" Parameter Name Predefined Values Reference -------------- ----------------- --------- sigcomp-id No [RFC-rohc-sigcomp-sip-06] We understand the above to be the only IANA Actions for this document. |
2007-05-17
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder |
2007-05-17
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder |
2007-05-15
|
08 | Amy Vezza | Last call sent |
2007-05-15
|
08 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-05-15
|
08 | Magnus Westerlund | Placed on agenda for telechat - 2007-06-07 by Magnus Westerlund |
2007-05-15
|
08 | Magnus Westerlund | [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund |
2007-05-15
|
08 | Magnus Westerlund | Ballot has been issued by Magnus Westerlund |
2007-05-15
|
08 | Magnus Westerlund | Created "Approve" ballot |
2007-05-15
|
08 | Magnus Westerlund | State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund |
2007-05-15
|
08 | Magnus Westerlund | Last Call was requested by Magnus Westerlund |
2007-05-15
|
08 | (System) | Ballot writeup text was added |
2007-05-15
|
08 | (System) | Last call text was added |
2007-05-15
|
08 | (System) | Ballot approval text was added |
2007-05-14
|
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-05-14
|
06 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-06.txt |
2007-04-11
|
08 | Magnus Westerlund | State Change Notice email list have been change to rohc-chairs@tools.ietf.org, cabo@tzi.org, zhigang.c.liu@nokia.com, richard.price@cogent-dsn.com, Gonzalo.Camarillo@ericsson.com from rohc-chairs@tools.ietf.org |
2007-04-11
|
08 | Magnus Westerlund | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Magnus Westerlund |
2007-04-11
|
08 | Magnus Westerlund | Very minor language updated expected based on AD comments. |
2007-03-29
|
08 | Magnus Westerlund | State Changes to AD Evaluation::AD Followup from Publication Requested by Magnus Westerlund |
2007-03-07
|
08 | Dinara Suleymanova | PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … PROTO Write-up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I (Lars-Erik Jonsson) am the Document Sheperd for this document, and I have personally reviewed this version of the document, which I believe is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by both key WG members and by key non-WG members, and I am confident with the depth and breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns! (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns! (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong consensus behind this document within the ROHC WG. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? No! (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I have reviewed the document, and believe it satisfies all criterias. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative/informative. There is one pending normative reference to draft-ietf-sip-outbound-07. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA registrations requested are well specified and should be fine. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Technical Summary This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. Working Group Summary This document has been in the workings for several years, and it has been given the time needed to make it mature. The document has been carefully reviewed by both the WG and various other SIP and SigComp experts, and there is WG consensus that the document should now be published as an RFC. Document Quality There are several independent implementers of SigComp, and they have collectively developed the content of this specification, based on running code experience. Personnel Document Sheperd for this document is Lars-Erik Jonsson, and Magnus Westerlund is the Responsible Area Director. |
2007-03-07
|
08 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2007-03-05
|
05 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-05.txt |
2006-11-27
|
04 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-04.txt |
2006-10-12
|
03 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-03.txt |
2006-02-23
|
02 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-02.txt |
2004-02-16
|
01 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-01.txt |
2003-06-20
|
00 | (System) | New version available: draft-ietf-rohc-sigcomp-sip-00.txt |