draft-ietf-sipcore-info-events-03.txt   draft-ietf-sipcore-info-events-04.txt 
SIPCORE E. Burger SIPCORE C. Holmberg
Internet-Draft NeuStar, Inc. Internet-Draft Ericsson
Obsoletes: RFC 2976 H. Kaplan Obsoletes: RFC 2976 E. Burger
(if approved) Acme Packet (if approved) NeuStar, Inc.
Expires: June 5, 2010 C. Holmberg Intended status: Standards Track H. Kaplan
Ericsson Expires: July 18, 2010 Acme Packet
December 2, 2009 January 14, 2010
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-03 draft-ietf-sipcore-info-events-04
Abstract Abstract
This document defines a new method, INFO, for the Session Initiation This document defines a new method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261], and an Info Package mechanism. The Protocol (SIP) [RFC3261], and an Info Package mechanism. The
document obsoletes [RFC2976]. For backward compatibility the document obsoletes [RFC2976]. For backward compatibility the
document also specifies a "legacy" mode of usage of the INFO method document also specifies a "legacy" mode of usage of the INFO method
that is compatible with the usage previously defined in [RFC2976], that is compatible with the usage previously defined in [RFC2976],
referred to as "legacy INFO Usage" in this document. referred to as "legacy INFO Usage" in this document.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 5, 2010. This Internet-Draft will expire on July 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6
3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7
3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8
3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8
3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8
3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8
3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8
4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11
4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11
4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12
4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12 4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12
6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 6.2. Info-Package header field . . . . . . . . . . . . . . . . 15
6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15
7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15
7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15
7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16
7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16
7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17
7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3. Co-existence with Info Package based INFO usage . . . . . 19 9.3. Co-existence with Info Package based INFO usage . . . . . 19
10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21
10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21
10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 22
10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22
10.10. Info Package Security Considerations . . . . . . . . . . 22 10.10. Info Package Security Considerations . . . . . . . . . . 23
10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23
10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23
11.2. Registration of the Info-Package Header Field . . . . . . 24 11.2. Registration of the Info-Package Header Field . . . . . . 24
11.3. Registration of the Recv-Info Header Field . . . . . . . 24 11.3. Registration of the Recv-Info Header Field . . . . . . . 24
11.4. Creation of the Info Packages Registry . . . . . . . . . 24 11.4. Creation of the Info Packages Registry . . . . . . . . . 24
11.5. Registration of the Info-Package Content-Disposition . . 25 11.5. Registration of the Info-Package Content-Disposition . . 25
11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Indication for which Info Packages UAs are willing to 12.1. Indication for which Info Packages UAs are willing to
receive INFO requests . . . . . . . . . . . . . . . . . . 25 receive INFO requests . . . . . . . . . . . . . . . . . . 25
12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25
12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26
12.2. INFO request associated with Info Package . . . . . . . . 27 12.2. INFO request associated with Info Package . . . . . . . . 27
12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27
12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 28
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 35
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document defines a new method, INFO, for the Session Initiation This document defines a new method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261]. Protocol (SIP) [RFC3261].
The purpose of the INFO message is to carry application level The purpose of the INFO message is to carry application level
information between endpoints, using the SIP dialog signaling path. information between endpoints, using the SIP dialog signaling path.
Note that the INFO method is not used to update characteristics of a Note that the INFO method is not used to update characteristics of a
SIP dialog or session, but to allow the applications which use the SIP dialog or session, but to allow the applications which use the
skipping to change at page 5, line 46 skipping to change at page 5, line 46
NOTE: A UA can use an empty Recv-Info header field (a header field NOTE: A UA can use an empty Recv-Info header field (a header field
without a value) to indicate that it is not willing to receive INFO without a value) to indicate that it is not willing to receive INFO
requests for any Info-Package, but to inform other UAs that it still requests for any Info-Package, but to inform other UAs that it still
supports the Info Package mechanism. supports the Info Package mechanism.
When a UA sends an INFO request, it uses the Info-Package header When a UA sends an INFO request, it uses the Info-Package header
field to indicate which Info Package is associated with the request. field to indicate which Info Package is associated with the request.
One particular INFO request can only be associated with a single Info One particular INFO request can only be associated with a single Info
Package. Package.
This document obsoletes [RFC2976]. However, for backward
compatibility it specifies a "legacy" mode of usage of the INFO
method that is compatible with the usage previously defined in
[RFC2976], referred to as "legacy INFO Usage" in this document.
2. Applicability 2. Applicability
This document defines a new method, INFO, for the Session Initiation This document defines a new method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261], and an Info Package mechanism. The Protocol (SIP) [RFC3261], and an Info Package mechanism. The
document obsoletes [RFC2976]. For backward compatibility the document obsoletes [RFC2976]. For backward compatibility the
document also specifies a "legacy" mode of usage of the INFO method document also specifies a "legacy" mode of usage of the INFO method
that is compatible with the usage previously defined in [RFC2976], that is compatible with the usage previously defined in [RFC2976],
referred to as "legacy INFO Usage" in this document. referred to as "legacy INFO Usage" in this document.
3. The INFO Method 3. The INFO Method
skipping to change at page 6, line 30 skipping to change at page 6, line 23
A gives more details on the types of applications for which the use A gives more details on the types of applications for which the use
of INFO is appropriate. of INFO is appropriate.
This section describes how a UA handles INFO requests and responses, This section describes how a UA handles INFO requests and responses,
as well as the message bodies included in INFO messages. as well as the message bodies included in INFO messages.
3.2. INFO Request 3.2. INFO Request
3.2.1. INFO Request Sender 3.2.1. INFO Request Sender
An INFO request can be associated with an Info Package (see X), or An INFO request can be associated with an Info Package (see
associated with a legacy INFO usage (see Y). Section 4), or associated with a legacy INFO usage (see Section 9).
The construction of the INFO request is the same as any other request The construction of the INFO request is the same as any other non-
within an existing invite dialog usage. A UA can send INFO requests target refresh request within an existing invite dialog usage as
both within early and confirmed dialogs. described in Section 12.2 of [RFC3261].
When a UA sends an INFO request associated with an Info Package, it When a UA sends an INFO request associated with an Info Package, it
MUST include an Info-Package header field that indicates which Info MUST include an Info-Package header field that indicates which Info
Package is associated with the request. A specific INFO request can Package is associated with the request. A specific INFO request can
be used only for a single Info Package. be used only for a single Info Package.
When a UA sends an INFO request associated with an legacy INFO usage When a UA sends an INFO request associated with an legacy INFO usage
there is no Info Package associated with the request, and the UA MUST there is no Info Package associated with the request, and the UA MUST
NOT include an Info-Package header field in the request. NOT include an Info-Package header field in the request.
The INFO request MUST NOT contain a Recv-Info header field. A UA can The INFO request MUST NOT contain a Recv-Info header field. A UA can
only indicate a set of Info Packages for which it is willing to only indicate a set of Info Packages for which it is willing to
receive INFO requests by using the SIP methods (and their responses) receive INFO requests by using the SIP methods (and their responses)
listed in Section 4. listed in Section 4.
A UA MUST NOT use the INFO method outside an invite dialog usage. A UA MUST NOT send an INFO request outside an invite dialog usage and
MUST NOT send an INFO request for an Info Package inside an invite
UAs indicate, per-dialog basis, for which Info Packages they are dialog usage if the remote UA has not indicated willingness to
willing to receive INFO requests. The set of Info Packages cannot receive that Info-Package within that dialog.
automatically be used within other dialogs.
If a UA receives a 469 (Bad INFO Package) response to an INFO If a UA receives a 469 (Bad INFO Package) response to an INFO
request, based on [RFC5057] the response represents a Transaction request, based on [RFC5057] the response represents a Transaction
Only failure, and the UA MUST NOT terminate the invite dialog usage. Only failure, and the UA MUST NOT terminate the invite dialog usage.
Due to the possibility of forking, the UA whichs sends the initial Due to the possibility of forking, the UA whichs sends the initial
INVITE reqest MUST be prepared to receive INFO requests from multiple INVITE reqest MUST be prepared to receive INFO requests from multiple
remote UAs during the early dialog phase. In addition, the UA MUST remote UAs during the early dialog phase. In addition, the UA MUST
be prepared to receive different Recv-Info header field values from be prepared to receive different Recv-Info header field values from
different remote UAs. different remote UAs.
skipping to change at page 7, line 37 skipping to change at page 7, line 30
3.2.2. INFO Request Receiver 3.2.2. INFO Request Receiver
If a UA receives an INFO request associated with an Info Package that If a UA receives an INFO request associated with an Info Package that
the UA has not indicated willingness to receive, the UA MUST send a the UA has not indicated willingness to receive, the UA MUST send a
469 (Bad INFO Package) response (see Section 11.6). In the 469 (Bad INFO Package) response (see Section 11.6). In the
terminology of Multiple Dialog Usages [RFC5057], this represents a terminology of Multiple Dialog Usages [RFC5057], this represents a
Transaction Only failure, and does not terminate the invite dialog Transaction Only failure, and does not terminate the invite dialog
usage. usage.
If a UA receives an INFO request associated with an Info Package, and If a UA receives an INFO request associated with an Info Package and
the message body part associated with the Info Package contains a the message body part with Content-Disposition 'Info-Package' (see
message body MIME type that the UA support, but which usage is not Section 3.3.1) has a MIME type that the UA supports but not in the
defined for the specific Info Package, it is RECOMMENDED that the UA context of that Info Package, it is RECOMMENDED that the UA send a
sends a 415 (Unsupported Media Type) response. 415 (Unsupported Media Type) response.
The UA MAY send other error responses, such as Request Failure (4xx), The UA MAY send other error responses, such as Request Failure (4xx),
Server Failure (5xx) and Global Failure (6xx), in accordance with the Server Failure (5xx) and Global Failure (6xx), in accordance with the
error handling procedures in [RFC3261]. error handling procedures in [RFC3261].
Otherwise, if the INFO request is syntactically correct and well Otherwise, if the INFO request is syntactically correct and well
structured, the UA MUST send a 200 (OK) response. structured, the UA MUST send a 200 (OK) response.
NOTE: If the application needs to reject the information which it NOTE: If the application needs to reject the information which it
received in an INFO request, that needs to be done on the application received in an INFO request, that needs to be done on the application
level. Ie the application needs to trigger a new INFO request, which level. Ie the application needs to trigger a new INFO request, which
contains information that the previously received application data contains information that the previously received application data
was not accepted. Individual Info Package specifications need to was not accepted. Individual Info Package specifications need to
describe the details for such procedures. describe the details for such procedures.
3.2.3. SIP Proxies
Proxies need no additional behavior beyond that described in
[RFC3261] to support INFO.
3.3. INFO Message Body 3.3. INFO Message Body
3.3.1. INFO Request Message Body 3.3.1. INFO Request Message Body
The purpose of the INFO request is to carry application level The purpose of the INFO request is to carry application level
information between SIP UAs. The application information data is information between SIP UAs. The application information data is
carried in the payload of the message body of the INFO request. carried in the payload of the message body of the INFO request.
NOTE: An INFO request assocated with an Info Package can also include NOTE: An INFO request assocated with an Info Package can also include
information associated with the Info Package using Info-Package information associated with the Info Package using Info-Package
header field parameters. header field parameters.
If an INFO request associated with an Info Package contains a message If an INFO request associated with an Info Package contains a message
body part, the body part is identified by a Content-Disposition body part, the body part is identified by a Content-Disposition
header field 'Info-Package' value. The body part can contain a header field 'Info-Package' value. The body part can contain a
single MIME type, or it can be a multipart [RFC5621] which contains single MIME type, or it can be a multipart [RFC5621] which contains
other body parts associated with the Info Package. other body parts associated with the Info Package.
UAs MUST conform to [RFC5621] to support multipart body parts. UAs MUST support multipart body parts in accordance with [RFC5621].
NOTE: Some SIP functions that are orthogonal to INFO can insert body NOTE: An INFO request can also contain other body parts that are
parts unrelated to the Info Package. meaningful within the context of an invite dialog usage but are not
specifically associated with the INFO method and the application
concerned.
When a UA supports a specific Info-Package, the UA also support all When a UA supports a specific Info-Package, the UA also support all
message body MIME types associated with that Info-Package. However, message body MIME types associated with that Info-Package. However,
in accordance with [RFC3261] the UA still indicates the supported in accordance with [RFC3261] the UA still indicates the supported
MIME types using the Accept header. MIME types using the Accept header.
3.3.2. INFO Response Message Body 3.3.2. INFO Response Message Body
A UA MUST NOT include a message body associated with an Info Package A UA MUST NOT include a message body associated with an Info Package
in an INFO response. Message bodies associated with Info Packages in an INFO response. Message bodies associated with Info Packages
skipping to change at page 9, line 33 skipping to change at page 9, line 36
This section describes how a UA handles Info Packages, how a UA uses This section describes how a UA handles Info Packages, how a UA uses
the Recv-Info header field, and how the UA acts in re-INVITE rollback the Recv-Info header field, and how the UA acts in re-INVITE rollback
situations. situations.
4.2.2. UA Procedures 4.2.2. UA Procedures
A UA which supports the Info Package mechanism MUST indicate, using A UA which supports the Info Package mechanism MUST indicate, using
the Revc-Info header field, the set of Info Packages for which it is the Revc-Info header field, the set of Info Packages for which it is
willing to receive INFO requests. A UA can list multiple Info willing to receive INFO requests. A UA can list multiple Info
Packages in a single Recv-Info header field, and the UA can use Packages in a single Recv-Info header field, and the UA can use
multiple Recv-Info header fields. A UA can an empty Recv-Info header multiple Recv-Info header fields. A UA can use an empty Recv-Info
field, ie a header field without any header field values. header field, ie a header field without any header field values.
A UA provides its set of Info Packages for which it is willing to A UA provides its set of Info Packages for which it is willing to
receive INFO requests during the dialog establishment. A UA can receive INFO requests during the dialog establishment. A UA can
update the set of Info Packages during the invite dialog usage. update the set of Info Packages during the invite dialog usage.
If a UA is not willing to receive INFO requests for any Info If a UA is not willing to receive INFO requests for any Info
Packages, during dialog establishment or later during the invite Packages, during dialog establishment or later during the invite
dialog usage, the UA MUST indicate this by including an empty Recv- dialog usage, the UA MUST indicate this by including an empty Recv-
Info header field. This informs other UAs that the UA still supports Info header field. This informs other UAs that the UA still supports
the Info Package mechanism. the Info Package mechanism.
skipping to change at page 10, line 30 skipping to change at page 10, line 33
NOTE: When a UA sends a message which contains a Recv-Info header NOTE: When a UA sends a message which contains a Recv-Info header
field with a new set of Info Packages for which the UA is willing to field with a new set of Info Packages for which the UA is willing to
receive INFO requests the remote UA might, before it receives the receive INFO requests the remote UA might, before it receives the
message, send an INFO request based on the old set of Info Packages. message, send an INFO request based on the old set of Info Packages.
In this case the receiver of the INFO requests rejects, and sends a In this case the receiver of the INFO requests rejects, and sends a
469 (Bad INFO Package) response to, the INFO request. 469 (Bad INFO Package) response to, the INFO request.
If a UA indicates multiple Info Packages, which provide similar If a UA indicates multiple Info Packages, which provide similar
functionality, it is not possible to indicate a priority order of the functionality, it is not possible to indicate a priority order of the
Info Packages, or that that the UA wishes to only receive INFO Info Packages, or to indicate that the UA wishes to only receive INFO
request for one of the Info Packages. It is up to the application requests for one of the Info Packages. It is up to the application
logic associated with the Info Packages, and specific Info Package logic associated with the Info Packages, and specific Info Package
specifications, to describe application behavior in such cases. specifications, to describe application behavior in such cases.
For backward compatibility purpose, even if a UA indicates support of For backward compatibility purpose, even if a UA indicates support of
the Info Package mechanism, it is still allowed to enable legacy INFO the Info Package mechanism, it is still allowed to enable legacy INFO
usages Appendix A. In addition, if a UA indicates support of the usages Appendix A. In addition, if a UA indicates support of the
INFO method using the Allow header field [RFC3261], it does not INFO method using the Allow header field [RFC3261], it does not
implicitly indicate support of the Info Package mechanism. A UA MUST implicitly indicate support of the Info Package mechanism. A UA MUST
use the Recv-Info header field in order to indicate that it supports use the Recv-Info header field in order to indicate that it supports
the Info Package mechanism. Likewise, even if a UA uses the Recv- the Info Package mechanism. Likewise, even if a UA uses the Recv-
skipping to change at page 13, line 30 skipping to change at page 13, line 30
From c m From c m
Geolocation R o Geolocation R o
Geolocation-Error r o Geolocation-Error r o
Max-Breadth R - Max-Breadth R -
Max-Forwards R o Max-Forwards R o
MIME-Version o MIME-Version o
Min-Expires - Min-Expires -
Organization - Organization -
Priority R - Priority R -
Privacy o Privacy o
Proxy-Authenticate 401 m Proxy-Authenticate 401 o
Proxy-Authenticate 407 o Proxy-Authenticate 407 m
Proxy-Authorization R o Proxy-Authorization R o
Proxy-Require R o Proxy-Require R o
Reason R o Reason R o
Record-Route R o Record-Route R o
Record-Route 2xx,18x o Record-Route 2xx,18x o
Referred-By R o Referred-By R o
Request-Disposition R o Request-Disposition R o
Require o Require o
Resource-Priority o Resource-Priority o
Retry-After R - Retry-After R -
skipping to change at page 14, line 22 skipping to change at page 14, line 22
WWW-Authenticate 407 o WWW-Authenticate 407 o
Figure 1: Table 1: Summary of Header Fields Figure 1: Table 1: Summary of Header Fields
6. INFO Header Fields 6. INFO Header Fields
6.1. General 6.1. General
This table expands on tables 2 and 3 in [RFC3261]. This table expands on tables 2 and 3 in [RFC3261].
Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD
Info-Package R - - - - - - - m* - - - - - ------------------------------------------------------------------
Info-Package 469 - - - - - - - m* - - - - - Info-Package R - - - - - - - m* - -
Recv-Info R - - - m m o o - - o - - - Info-Package 469 - - - - - - - m* - -
Recv-Info 2xx - - - o** m - o***- - o***- - - Recv-Info R - - - m m o o - - o
Recv-Info 1xx - - - o** - - - - - - - - - Recv-Info 2xx - - - o** m - o***- - o***
Recv-Info r - - - o o - o - - o - - - Recv-Info 1xx - - - o** - - - - - -
Recv-Info r - - - o o - o - - o
Header field where SUB NOT RFR
--------------------------------
Info-Package R - - -
Info-Package 469 - - -
Recv-Info R - - -
Recv-Info 2xx - - -
Recv-Info 1xx - - -
Recv-Info r - - -
The support and usage of the Info-Package and Recv-Info header fields The support and usage of the Info-Package and Recv-Info header fields
is not applicalbe to UAs that only support legacy INFO usages. * Not is not applicalbe to UAs that only support legacy INFO usages. * Not
applicalbe to INFO requests and responses associated with legacy INFO applicalbe to INFO requests and responses associated with legacy INFO
usages. ** Mandatory in at least one reliable 18x/2xx response, if usages. ** Mandatory in at least one reliable 18x/2xx response, if
sent, to the INVITE request, if the associated INVITE request sent, to the INVITE request, if the associated INVITE request
contained a Recv-Info header field. *** Mandatory if the associated contained a Recv-Info header field. *** Mandatory if the associated
request contained a Recv-Info header field. request contained a Recv-Info header field.
Table 2: INFO-related Header Fields Table 2: INFO-related Header Fields
skipping to change at page 15, line 50 skipping to change at page 16, line 14
Some applications, like sending of DTMF tones, can generate a burst Some applications, like sending of DTMF tones, can generate a burst
of up to 20 messages per second. Other applications, like constant of up to 20 messages per second. Other applications, like constant
GPS location updates, could generate a high rate of INFO requests GPS location updates, could generate a high rate of INFO requests
during the lifetime of the invite dialog usage. during the lifetime of the invite dialog usage.
Furthermore, SIP messages tend to be relatively small, on the order Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
exchange of bulk data beyond these limits, especially if the headers exchange of bulk data beyond these limits, especially if the headers
plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for
such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media
plane data transport mechanisms. plane data transport mechanisms.
7.4. Alternative Mechanisms 7.4. Alternative Mechanisms
7.4.1. Alternative SIP signaling plane mechanisms 7.4.1. Alternative SIP signaling plane mechanisms
7.4.1.1. General 7.4.1.1. General
This subsection describes some alternative mechanisms for This subsection describes some alternative mechanisms for
transporting application information on the SIP signaling plane, transporting application information on the SIP signaling plane,
skipping to change at page 17, line 19 skipping to change at page 17, line 26
ser. ser.
7.4.2. Media Plane Mechanisms 7.4.2. Media Plane Mechanisms
7.4.2.1. General 7.4.2.1. General
In SIP, media plane channels associated with SIP dialogs are In SIP, media plane channels associated with SIP dialogs are
established using SIP signaling, but the data exchanged on the media established using SIP signaling, but the data exchanged on the media
plane channel does not traverse SIP signaling intermediates, so if plane channel does not traverse SIP signaling intermediates, so if
there will be a lot of information exchanged, and there is no need there will be a lot of information exchanged, and there is no need
for the SIP signaling intermediates routing to examine the for the SIP signaling intermediaries to examine the information, it
information, it is recommended to use a media plane mechanism, rather is recommended to use a media plane mechanism, rather than a SIP
than a SIP signaling based. signaling based.
A low latency requirement for the exchange of information is one A low latency requirement for the exchange of information is one
strong indicator for using a media channel. Exchanging information strong indicator for using a media channel. Exchanging information
through the SIP routing network can introduce hundreds of through the SIP routing network can introduce hundreds of
milliseconds of latency. milliseconds of latency.
7.4.2.2. MRCPv2 7.4.2.2. MRCPv2
One mechanism for media plane exchange of application data is MRCPv2 One mechanism for media plane exchange of application data is MRCPv2
[I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented
channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is
established. established.
7.4.2.3. MRSP 7.4.2.3. MRSP
MSRP [RFC4975] defines session-based instant messaging as well as MSRP [RFC4975] defines session-based instant messaging as well as
bulk file transfer and other such large-volume uses. bulk file transfer and other such large-volume uses.
7.4.3. Non-SIP related mechanisms 7.4.3. Non-SIP related mechanisms
Another alternative is to use a totally externally signaled channel, Another alternative is to use a a SIP-independent mechanism, such as
such as HTTP [RFC2616]. In this model, the UA knows about a HTTP [RFC2616]. In this model, the UA knows about a rendezvous point
rendezvous point to direct HTTP requests to for the transfer of to direct HTTP requests to for the transfer of information. Examples
information. Examples include encoding of a prompt to retrieve in include encoding of a prompt to retrieve in the SIP Request URI in
the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-
in a VoiceXML [W3C.REC-voicexml21-20070619] script. voicexml21-20070619] script.
8. Syntax 8. Syntax
8.1. General 8.1. General
This section describes the syntax extensions required for the INFO This section describes the syntax extensions required for the INFO
method. The previous sections describe the semantics. Note the method, and for the Info-Package and Recv-Info header fields. The
formal syntax definitions described in this document use the ABNF previous sections describe the semantics. Note the formal syntax
format used in [RFC3261] and contain references to elements defined definitions described in this document use the ABNF format used in
therein. [RFC3261] and contain references to elements defined therein.
8.2. ABNF 8.2. ABNF
INFOm = %x49.4E.46.4F ; INFO in caps INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON [Info-package-list] Recv-Info = "Recv-Info" HCOLON [Info-package-list]
Info-package-list = Info-package-type *( COMMA Info-package-type ) Info-package-list = Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( SEMI Info-package-param) Info-package-type = Info-package-name *( SEMI Info-package-param)
skipping to change at page 20, line 6 skipping to change at page 20, line 13
If, for an Info Package, there is a need to extend or modify the If, for an Info Package, there is a need to extend or modify the
behavior described in this document, that behaviour MUST be described behavior described in this document, that behaviour MUST be described
in the Info Package specification. It is bad practice for Info in the Info Package specification. It is bad practice for Info
Package specifications to repeat procedures defined in this document, Package specifications to repeat procedures defined in this document,
unless needed for clarification or emphasis purpose. unless needed for clarification or emphasis purpose.
Info Package specifications MUST NOT weaken any behavior designated Info Package specifications MUST NOT weaken any behavior designated
with "SHOULD" or "MUST" in this specification. However, Info with "SHOULD" or "MUST" in this specification. However, Info
Packages specifications MAY strengthen "SHOULD", "MAY", or Packages specifications MAY strengthen "SHOULD", "MAY", or
"RECOMMENDED" requirements to "MUST" strength if applications "RECOMMENDED" requirements to "MUST" strength if applications
associated with the Info Package requires it. associated with the Info Package require it.
Info Package specifications MUST address the issues defined in the Info Package specifications MUST address the issues defined in the
following subsections, or document why an issue is not applicable for following subsections, or document why an issue is not applicable for
the specific Info Package. the specific Info Package.
Section 7.4 describes alternative mechanisms, which should be Section 7.4 describes alternative mechanisms, which should be
considered as part of the process for solving a specific use-case, considered as part of the process for solving a specific use-case,
when for transporting application information. when there is a need for transporting application information.
10.2. Overal Description 10.2. Overal Description
The Info Package specification MUST contain an overlap description of The Info Package specification MUST contain an overall description of
the Info Package: what type of information are carried in INFO the Info Package: what type of information are carried in INFO
requests associated with the Info Package, and for what type of requests associated with the Info Package, and for what type of
applications and functionalities UAs can use the Info Package. applications and functionalities UAs can use the Info Package.
If the Info Package is defined for a specific application, the Info If the Info Package is defined for a specific application, the Info
Package specification MUST state which application UAs can use the Package specification MUST state which application UAs can use the
Info Package with. Info Package with.
10.3. Applicability 10.3. Applicability
skipping to change at page 20, line 45 skipping to change at page 21, line 8
transported on a media path), or that it is not seen feasible to transported on a media path), or that it is not seen feasible to
establish separate dialogs (subscription) in order to transport the establish separate dialogs (subscription) in order to transport the
information. information.
Annex A provides more information, and describes alternative Annex A provides more information, and describes alternative
mechanisms which one should consider for solving a specific use-case. mechanisms which one should consider for solving a specific use-case.
10.4. Info Package Name 10.4. Info Package Name
The Info Package specification MUST define an Info Package name, The Info Package specification MUST define an Info Package name,
which UAs use as a header field value (e.g. "infoX") to be identify which UAs use as a header field value (e.g. "infoX") to identify the
the Info Package in the Recv-Info and Info-Package header fields. Info Package in the Recv-Info and Info-Package header fields. The
The header field value MUST conform to the ABNF defined in header field value MUST conform to the ABNF defined in Section 8.2.
Section 8.2.
The Info Package mechanism does not support package versioning. The Info Package mechanism does not support package versioning.
Specific Info Package message body payloads can contain version Specific Info Package message body payloads can contain version
information, which is handled by the applications associated with the information, which is handled by the applications associated with the
Info Package. However, such feature is outside the scope of the Info Package. However, such feature is outside the scope of the
generic Info Package mechanism. generic Info Package mechanism.
NOTE: Even if an Info Package name contains version numbering (e.g. NOTE: Even if an Info Package name contains version numbering (e.g.
foo_v2), the Info Package mechanism does not distinguish a version foo_v2), the Info Package mechanism does not distinguish a version
number from the rest of the Info Package name. number from the rest of the Info Package name.
skipping to change at page 25, line 9 skipping to change at page 25, line 13
Package. Package.
The initial population of this table shall be: The initial population of this table shall be:
Name Reference Name Reference
11.5. Registration of the Info-Package Content-Disposition 11.5. Registration of the Info-Package Content-Disposition
Please add the following new header field value to the Content- Please add the following new header field value to the Content-
Disposition registry. Disposition registry.
Name: info-package Name: info-package
Description: the body contains information associated with an Info Package Description: the body contains information associated with an
Reference: RFCXXXX Info Package
Reference: RFCXXXX
11.6. SIP Response Code 469 Registration 11.6. SIP Response Code 469 Registration
Please register the following new response code in the Session Please register the following new response code in the Session
Initiation Protocol Parameters - Response Codes registry. Initiation Protocol Parameters - Response Codes registry.
Response Code: 469 Response Code: 469
Default Reason Phrase: Bad INFO Package Default Reason Phrase: Bad INFO Package
Reference: RFCXXXX Reference: RFCXXXX
12. Examples 12. Examples
skipping to change at page 26, line 51 skipping to change at page 27, line 21
CSeq: 314163 UPDATE CSeq: 314163 UPDATE
Recv-Info: Recv-Info:
Contact: <sip:alice@pc33.example.com> Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
... ...
The UAS sends a 200 (OK) response back to the UAC, where the UAS The UAS sends a 200 (OK) response back to the UAC, where the UAS
indicates that it is willing to receive INFO requests for Info indicates that it is willing to receive INFO requests for Info
Packages R. Packages R, T.
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=a6c85cf To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 INVITE CSeq: 314163 INVITE
Contact: <sip:alice@pc33.example.com> Contact: <sip:alice@pc33.example.com>
Recv-Info: R, T Recv-Info: R, T
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
skipping to change at page 33, line 33 skipping to change at page 34, line 33
Media Control", RFC 5168, March 2008. Media Control", RFC 5168, March 2008.
[I-D.peterson-rai-rfc3427bis] [I-D.peterson-rai-rfc3427bis]
Peterson, J., Jennings, C., and R. Sparks, "Change Process Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real- for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", time Applications and Infrastructure Area",
draft-peterson-rai-rfc3427bis-04 (work in progress), draft-peterson-rai-rfc3427bis-04 (work in progress),
October 2009. October 2009.
[W3C.REC-voicexml21-20070619] [W3C.REC-voicexml21-20070619]
Lee, A., Porter, B., Oshry, M., Burnett, D., Rehor, K., Lee, A., Porter, B., McGlashan, S., Oshry, M., Auburn, R.,
Auburn, R., Bodell, M., Burke, D., Baggia, P., Candell, Rehor, K., Bodell, M., Burke, D., Baggia, P., Candell, E.,
E., Carter, J., and S. McGlashan, "Voice Extensible Markup Burnett, D., and J. Carter, "Voice Extensible Markup
Language (VoiceXML) 2.1", World Wide Web Consortium Language (VoiceXML) 2.1", World Wide Web Consortium
Recommendation REC-voicexml21-20070619, June 2007, Recommendation REC-voicexml21-20070619, June 2007,
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>. <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[I-D.ietf-speechsc-mrcpv2] [I-D.ietf-speechsc-mrcpv2]
Shanmugham, S. and D. Burnett, "Media Resource Control Shanmugham, S. and D. Burnett, "Media Resource Control
Protocol Version 2 (MRCPv2)", Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-20 (work in progress), draft-ietf-speechsc-mrcpv2-20 (work in progress),
August 2009. August 2009.
skipping to change at page 35, line 24 skipping to change at page 36, line 24
Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael
Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain,
Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore
Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve
Langstaff, Sumit Garg and Xavier Marjoum. Langstaff, Sumit Garg and Xavier Marjoum.
John Elwell and Francois Audet helped with QSIG references. In John Elwell and Francois Audet helped with QSIG references. In
addition, Francois Audet provided text for the revised abstract. addition, Francois Audet provided text for the revised abstract.
Keith Drage provided comments and helped immensely with Figure 1. Keith Drage provided comments and helped immensely with Figure 1.
Brett Tate, John Elwell, Keith Drage and Robert Sparks provided Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert
valuable feedback during the WGLC process, in order to prepare this Sparks provided valuable feedback during the WGLC process, in order
document for publication. to prepare this document for publication.
Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided
valuable input in order to sort out the message body part usage for valuable input in order to sort out the message body part usage for
Info Packages. Info Packages.
Appendix C. Change Log Appendix C. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-info-events-03
o Further changes based on WGLC comments
o New section 3.2.3 added
Changes from draft-ietf-sipcore-info-events-02 Changes from draft-ietf-sipcore-info-events-02
o Further changes based on WGLC comments o Further changes based on WGLC comments
o Allignment with "specification" and "definition" terminology o Allignment with "specification" and "definition" terminology
o Location switch of sections 3 and 4 o Location switch of sections 3 and 4
o Corrections in header table o Corrections in header table
o IANA Info Package registration input changed o IANA Info Package registration input changed
o Clarifiaction regarding which SIP messages can contain the Recv- o Clarifiaction regarding which SIP messages can contain the Recv-
Info header field Info header field
o Recv-Info 'nil' value removed o Recv-Info 'nil' value removed
o Rules on usage of Recv-Info header clarified o Rules on usage of Recv-Info header clarified
skipping to change at page 37, line 45 skipping to change at page 39, line 4
o Added Registrar behavior. o Added Registrar behavior.
o Added OPTIONS processing. o Added OPTIONS processing.
o Clarified overlapping INFO method processing. o Clarified overlapping INFO method processing.
o Described multiple INFO bodies in a single INFO method. o Described multiple INFO bodies in a single INFO method.
o Took out Info-Package as a header field for responses to the INFO o Took out Info-Package as a header field for responses to the INFO
method. method.
o Expanded on risks of using INFO and filled-in more on the o Expanded on risks of using INFO and filled-in more on the
alternatives alternatives
o Moved definitions of INFO into the body of the text and cleaned up o Moved definitions of INFO into the body of the text and cleaned up
IANA Considerations section IANA Considerations section
o Added legacy usages descriptions o Added legacy usages descriptions
Authors' Addresses Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas, 02420
Finland
Phone:
Fax:
Email: christer.holmberg@ericsson.com
URI:
Eric W. Burger Eric W. Burger
NeuStar, Inc. NeuStar, Inc.
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA 20166-6579 Sterling, VA 20166-6579
USA USA
Email: eburger@standardstrack.com Email: eburger@standardstrack.com
URI: http://www.standardstrack.com URI: http://www.standardstrack.com
Hadriel Kaplan Hadriel Kaplan
Acme Packet Acme Packet
71 Third Ave. 71 Third Ave.
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: Phone:
Fax: Fax:
Email: hkaplan@acmepacket.com Email: hkaplan@acmepacket.com
URI: URI:
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas, 02420
Finland
Phone:
Fax:
Email: christer.holmberg@ericsson.com
URI:
 End of changes. 41 change blocks. 
99 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/