draft-ietf-sipcore-info-events-05.txt   draft-ietf-sipcore-info-events-06.txt 
SIPCORE C. Holmberg SIPCORE C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: RFC 2976 E. Burger Obsoletes: RFC 2976 E. Burger
(if approved) NeuStar, Inc. (if approved) NeuStar, Inc.
Intended status: Standards Track H. Kaplan Intended status: Standards Track H. Kaplan
Expires: July 22, 2010 Acme Packet Expires: August 2, 2010 Acme Packet
January 18, 2010 January 29, 2010
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-05 draft-ietf-sipcore-info-events-06
Abstract Abstract
This document defines a method, INFO, for the Session Initiation This document defines a 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 July 22, 2010. This Internet-Draft will expire on August 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 3, line 50 skipping to change at page 3, line 50
7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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. Overall Description . . . . . . . . . . . . . . . . . . . 20
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . 22
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 . . 24 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 . . . . . . . . . . . . . . . . . . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 7, line 6 skipping to change at page 7, line 6
A UA MUST NOT send an INFO request outside an invite dialog usage and 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 MUST NOT send an INFO request for an Info Package inside an invite
dialog usage if the remote UA has not indicated willingness to dialog usage if the remote UA has not indicated willingness to
receive that Info-Package within that dialog. receive that Info-Package within that dialog.
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 which sends the initial
INVITE reqest MUST be prepared to receive INFO requests from multiple INVITE request MUST be prepared to receive INFO requests from
remote UAs during the early dialog phase. In addition, the UA MUST multiple remote UAs during the early dialog phase. In addition, the
be prepared to receive different Recv-Info header field values from UA MUST be prepared to receive different Recv-Info header field
different remote UAs. values from different remote UAs.
NOTE: If the UAS (receiver of the initial INVITE request) sends an NOTE: If the UAS (receiver of the initial INVITE request) sends an
INFO request just after it has sent the response which creates the INFO request just after it has sent the response which creates the
dialog, the UAS needs to be prepared that the INFO request can reach dialog, the UAS needs to be prepared that the INFO request can reach
the UAC before the dialog creating response, and might therefore be the UAC before the dialog creating response, and might therefore be
rejected by the UAC. In addition, an INFO request might be rejected rejected by the UAC. In addition, an INFO request might be rejected
due to a race condition, if a UA sends the INFO request at the same due to a race condition, if a UA sends the INFO request at the same
time as the remote UA sends a new set of Info Packages for which it time as the remote UA sends a new set of Info Packages for which it
is willing to receive INFO requests. is willing to receive INFO requests.
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), which contains a 469 (Bad INFO Package) response (see Section 11.6), which contains a
Recv-Info Header field with Info Packages for which the UA is willing Recv-Info header field with Info Packages for which the UA is willing
to receive INFO requests. The UA MUST NOT use the response to update to receive INFO requests. The UA MUST NOT use the response to update
the set of Info Packages, but simply to indicate the current set. In the set of Info Packages, but simply to indicate the current set. In
the terminology of Multiple Dialog Usages [RFC5057], this represents the terminology of Multiple Dialog Usages [RFC5057], this represents
a Transaction Only failure, and does not terminate the invite dialog a 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 with Content-Disposition 'Info-Package' (see the message body part with Content-Disposition 'Info-Package' (see
Section 3.3.1) has a MIME type that the UA supports but not in the Section 3.3.1) has a MIME type that the UA supports but not in the
context of that Info Package, it is RECOMMENDED that the UA send a context of that Info Package, it is RECOMMENDED that the UA send a
skipping to change at page 8, line 18 skipping to change at page 8, line 18
[RFC3261] to support INFO. [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 associated with an Info Package can also
information associated with the Info Package using Info-Package include information associated with the Info Package using Info-
header field parameters. Package 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 support multipart body parts in accordance with [RFC5621]. UAs MUST support multipart body parts in accordance with [RFC5621].
NOTE: An INFO request can also contain other body parts that are NOTE: An INFO request can also contain other body parts that are
skipping to change at page 11, line 17 skipping to change at page 11, line 17
4.2.3. Recv-Info header field rules 4.2.3. Recv-Info header field rules
The text below defines rules on when a UA is required to include a The text below defines rules on when a UA is required to include a
Recv-Info header field in SIP messages. Section 6.1 lists the SIP Recv-Info header field in SIP messages. Section 6.1 lists the SIP
methods, for which a UA can insert a Recv-Info header field in methods, for which a UA can insert a Recv-Info header field in
requests and responses. requests and responses.
- The sender of an initial INVITE request MUST include a Recv-Info - The sender of an initial INVITE request MUST include a Recv-Info
header field in the initial INVITE request, even if the sender is not header field in the initial INVITE request, even if the sender is not
willing to receive INFO requests asscoiated with any Info Package. willing to receive INFO requests associated with any Info Package.
- The receiver of a request which contains a Recv-Info header field - The receiver of a request which contains a Recv-Info header field
MUST include a Recv-Info header field in a reliable 18x/2xx response MUST include a Recv-Info header field in a reliable 18x/2xx response
to the request, even if the request contains an empty Recv-Info to the request, even if the request contains an empty Recv-Info
header field, and even if the header field value of the receiver has header field, and even if the header field value of the receiver has
not changed since the previous time it sent a Recv-Info header field. not changed since the previous time it sent a Recv-Info header field.
- A UA MUST NOT include a Recv-Info header field in a response if the - A UA MUST NOT include a Recv-Info header field in a response if the
associated request did not contain a Recv-Info header field. associated request did not contain a Recv-Info header field.
skipping to change at page 14, line 33 skipping to change at page 14, line 33
Info-Package R - - - Info-Package R - - -
Recv-Info R - - - Recv-Info R - - -
Recv-Info 2xx - - - Recv-Info 2xx - - -
Recv-Info 1xx - - - Recv-Info 1xx - - -
Recv-Info 469 - - - Recv-Info 469 - - -
Recv-Info r - - - Recv-Info r - - -
Table 2: INFO-related Header Fields Table 2: INFO-related Header Fields
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. is not applicable to UAs that only support legacy INFO usages.
* Not applicalbe to INFO requests and responses associated with * Not applicable to INFO requests and responses associated with
legacy INFO usages. legacy INFO usages.
** Mandatory in at least one reliable 18x/2xx response, if sent, ** Mandatory in at least one reliable 18x/2xx response, if sent,
to the INVITE request, if the associated INVITE request contained to the INVITE request, if the associated INVITE request contained
a Recv-Info header field. a Recv-Info header field.
*** Mandatory if the associated request contained a Recv-Info *** Mandatory if the associated request contained a Recv-Info
header field. header field.
6.2. Info-Package header field 6.2. Info-Package header field
skipping to change at page 17, line 43 skipping to change at page 17, line 43
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 a SIP-independent mechanism, such as Another alternative is to use a SIP-independent mechanism, such as
HTTP [RFC2616]. In this model, the UA knows about a rendezvous point HTTP [RFC2616]. In this model, the UA knows about a rendezvous point
to direct HTTP requests to for the transfer of information. Examples to direct HTTP requests to for the transfer of information. Examples
include encoding of a prompt to retrieve in the SIP Request URI in include encoding of a prompt to retrieve in the SIP Request URI in
[RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-
voicexml21-20070619] script. voicexml21-20070619] script.
8. Syntax 8. Syntax
8.1. General 8.1. General
skipping to change at page 19, line 47 skipping to change at page 19, line 47
See Appendix A for examples of existing legacy INFO usages. See Appendix A for examples of existing legacy INFO usages.
10. Info Package Requirements 10. Info Package Requirements
10.1. General 10.1. General
This section provides guidance on how to define an Info Package, and This section provides guidance on how to define an Info Package, and
what information needs to exist in an Info Package specification. what information needs to exist in an Info Package specification.
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 behavior 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 require 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 there is a need for transporting application information. when there is a need for transporting application information.
10.2. Overal Description 10.2. Overall Description
The Info Package specification MUST contain an overall 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.
skipping to change at page 22, line 30 skipping to change at page 22, line 30
As the SIP stack might not be aware of Info Package specific As the SIP stack might not be aware of Info Package specific
restrictions, it cannot be assumed that overlapping requests would be restrictions, it cannot be assumed that overlapping requests would be
rejected. As defined in Section 3.2.2, UAs will normally send a 200 rejected. As defined in Section 3.2.2, UAs will normally send a 200
(OK) response to an INFO request. The application logic associated (OK) response to an INFO request. The application logic associated
with the Info Package needs to handle situations where UAs do not with the Info Package needs to handle situations where UAs do not
follow restrictions associated with the Info Package. follow restrictions associated with the Info Package.
10.9. Rate of INFO Requests 10.9. Rate of INFO Requests
If there is a maximum or minumum rate at which UAs can send INFO If there is a maximum or minimum rate at which UAs can send INFO
requests associated with the Info Package within a dialog, the Info requests associated with the Info Package within a dialog, the Info
Package specification MUST document the rate values. Package specification MUST document the rate values.
If the rates can vary, the Info Package specification MAY define Info If the rates can vary, the Info Package specification MAY define Info
Package parameters that UAs can use to indicate or negotiate the Package parameters that UAs can use to indicate or negotiate the
rates. Alternatively the rate information can be part of the rates. Alternatively the rate information can be part of the
application data information associated with the Info Package. application data information associated with the Info Package.
10.10. Info Package Security Considerations 10.10. Info Package Security Considerations
skipping to change at page 23, line 21 skipping to change at page 23, line 21
10.11. Implementation Details 10.11. Implementation Details
It is strongly RECOMMENDED that the Info Package specification It is strongly RECOMMENDED that the Info Package specification
defines the procedure how implementors shall implement and use the defines the procedure how implementors shall implement and use the
Info Package, or refer to other locations where implementors can find Info Package, or refer to other locations where implementors can find
that information. that information.
NOTE: Sometimes Info Package designer might choose to not reveal the NOTE: Sometimes Info Package designer might choose to not reveal the
details of an Info Package. However, in order to allow multiple details of an Info Package. However, in order to allow multiple
implementations to support the Info Package, Info Package designers implementations to support the Info Package, Info Package designers
are stronly encouraged to provide the implementation details. are strongly encouraged to provide the implementation details.
10.12. Examples 10.12. Examples
It is RECOMMENDED that the Info Package specification provides It is RECOMMENDED that the Info Package specification provides
demonstrative message flow diagrams, paired with complete messages demonstrative message flow diagrams, paired with complete messages
and message descriptions. and message descriptions.
Note that example flows are by definition informative, and do not Note that example flows are by definition informative, and do not
replace normative text. replace normative text.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
states: states:
Method: INFO Method: INFO
Reference: [RFC2976] Reference: [RFC2976]
to: to:
Method: INFO Method: INFO
Reference: [RFCXXXX] Reference: [RFCXXXX]
11.2. Registration of the Info-Package Header Field 11.2. Registration of the Info-Package header field
Please add the following new SIP header field in the Header Fields Please add the following new SIP header field in the Header Fields
subregistry under the SIP Parameters registry. subregistry under the SIP Parameters registry.
Header Name: Info-Package Header Name: Info-Package
Compact Form: (none) Compact Form: (none)
Reference: [RFCXXXX] Reference: [RFCXXXX]
11.3. Registration of the Recv-Info Header Field 11.3. Registration of the Recv-Info header field
Please add the following new SIP header field in the Header Fields Please add the following new SIP header field in the Header Fields
subregistry under the SIP Parameters registry. subregistry under the SIP Parameters registry.
Header Name: Recv-Info Header Name: Recv-Info
Compact Form: (none) Compact Form: (none)
Reference: [RFCXXXX] Reference: [RFCXXXX]
11.4. Creation of the Info Packages Registry 11.4. Creation of the Info Packages Registry
Please create a subregistry in the SIP Parameters registry for Info Please create a subregistry in the SIP Parameters registry for Info
Packages. Packages.
The registration policy for the registry is Specification Required Note to the reviewer:
[RFC5226].
The reviewer does not consider the applicability of the Info Package The policy for review of Info Packages is "Specification Required",
for the usage for which it is defined. as defined in [RFC5226]. This policy was selected because Info
Packages re-use an existing mechanism for transport of arbitrary
session-associated data within SIP, and therefore new Info Packages
do not require the more extensive review required by specifications
that make fundamental protocol changes. However, the reviewer is
expected to verify that each Info Package registration is in fact
consistent with this definition. Changes to the SIP protocol and
state machine are outside of the allowable scope for an Info Package
and are governed by other procedures including
[I-D.peterson-rai-rfc3427bis] and its successors, if any.
The following data elements populate the Info Package Registry. The following data elements populate the Info Package Registry.
o Info Package Name: The Info Package Name is a case insensitive o Info Package Name: The Info Package Name is a case insensitive
token. In addition, IANA shall not register multiple Info Package token. In addition, IANA shall not register multiple Info Package
names that have identical case-insensitive values. names that have identical case-insensitive values.
o Reference: A reference to a specification which describes the Info o Reference: A reference to a specification which describes the Info
Package. Package.
The initial population of this table shall be: The initial population of this table shall be:
skipping to change at page 33, line 40 skipping to change at page 33, line 40
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]
Oshry, M., Rehor, K., Bodell, M., Burke, D., Auburn, R., Candell, E., Burnett, D., Carter, J., Auburn, R.,
Baggia, P., McGlashan, S., Candell, E., Burnett, D., McGlashan, S., Lee, A., Porter, B., Oshry, M., Rehor, K.,
Carter, J., Lee, A., and B. Porter, "Voice Extensible Bodell, M., Burke, D., and P. Baggia, "Voice Extensible
Markup Language (VoiceXML) 2.1", World Wide Web Consortium Markup 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 43 skipping to change at page 35, line 43
to prepare this 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-05
o Further changes based on WGLC comments
o Editorial changes
o IANA registry procedures clarified
Changes from draft-ietf-sipcore-info-events-04 Changes from draft-ietf-sipcore-info-events-04
o Further changes based on WGLC comments o Further changes based on WGLC comments
o OPTIONS processing removed o OPTIONS processing removed
o Clarification of Recv-Info header field in INFO 469 response added o Clarification of Recv-Info header field in INFO 469 response added
o IANA registry procedures clarified o IANA registry procedures clarified
Changes from draft-ietf-sipcore-info-events-03 Changes from draft-ietf-sipcore-info-events-03
o Further changes based on WGLC comments o Further changes based on WGLC comments
o New section 3.2.3 added 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 alignment 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 Clarification 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
o Recv-Info fallback rules added o Recv-Info fallback rules added
o Additional examples added o Additional examples added
Changes from draft-ietf-sipcore-info-events-01 Changes from draft-ietf-sipcore-info-events-01
o Further changes based on WGLC comments o Further changes based on WGLC comments
o Appending A moved into the main part of the document o Appending A moved into the main part of the document
o Section name changed from "Modifications to SIP Change Process" to o Section name changed from "Modifications to SIP Change Process" to
skipping to change at page 36, line 43 skipping to change at page 36, line 48
o Text about legacy INFO and subscription-based events moved from o Text about legacy INFO and subscription-based events moved from
the Introduction to the main part of the document the Introduction to the main part of the document
o Wording about receiving Info-Packages has been replaced with o Wording about receiving Info-Packages has been replaced with
wording about receiving INFO requests for Info-Packages wording about receiving INFO requests for Info-Packages
o The text about the usage of message body, and body parts, o The text about the usage of message body, and body parts,
associated with Info Packages, has been clarified associated with Info Packages, has been clarified
Changes from draft-ietf-sip-info-events-04 Changes from draft-ietf-sip-info-events-04
o Major re-write of the document, due to problems to implement WGLC o Major re-write of the document, due to problems to implement WGLC
comments into the existing text structure comments into the existing text structure
o Wording allignment o Wording alignment
o Clarification or roles o Clarification or roles
Changes from draft-ietf-sip-info-events-03 Changes from draft-ietf-sip-info-events-03
o Clarified Abstract language o Clarified Abstract language
o All SIP dialogs are now refered to as sessions o All SIP dialogs are now referred to as sessions
o Clarified the image example in the Introduction o Clarified the image example in the Introduction
o Clarified the relationship (none) between SIP Event Packages and o Clarified the relationship (none) between SIP Event Packages and
SIP Info Packages SIP Info Packages
o Really, really clarified the protocol is NOT a negotiation but an o Really, really clarified the protocol is NOT a negotiation but an
advertisement advertisement
o Split Section 3 into UAS and UAC behavior o Split Section 3 into UAS and UAC behavior
o Moved the example in section 3 into its own sub-section, and used o Moved the example in section 3 into its own sub-section, and used
full SIP header fields full SIP header fields
o Clarified forking behavior o Clarified forking behavior
o Clarified language around when to send a body o Clarified language around when to send a body
 End of changes. 27 change blocks. 
38 lines changed or deleted 51 lines changed or added

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