draft-ietf-sipcore-rfc4244bis-11.txt   draft-ietf-sipcore-rfc4244bis-12.txt 
Network Working Group M. Barnes Network Working Group M. Barnes
Internet-Draft Polycom Internet-Draft Polycom
Obsoletes: 4244 (if approved) F. Audet Obsoletes: 4244 (if approved) F. Audet
Intended status: Standards Track Skype Intended status: Standards Track Skype
Expires: July 5, 2013 S. Schubert Expires: April 4, 2014 S. Schubert
NTT NTT
J. van Elburg J. van Elburg
Detecon International Gmbh Detecon International Gmbh
C. Holmberg C. Holmberg
Ericsson Ericsson
Jan 2013 Oct 2013
An Extension to the Session Initiation Protocol (SIP) for Request An Extension to the Session Initiation Protocol (SIP) for Request
History Information History Information
draft-ietf-sipcore-rfc4244bis-11.txt draft-ietf-sipcore-rfc4244bis-12.txt
Abstract Abstract
This document defines a standard mechanism for capturing the history This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) information associated with a Session Initiation Protocol (SIP)
request. This capability enables many enhanced services by providing request. This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific the information as to how and why a SIP request arrives at a specific
application or user. This document defines an optional SIP header application or user. This document defines an optional SIP header
field, History-Info, for capturing the history information in field, History-Info, for capturing the history information in
requests. The document also defines SIP header field parameters for requests. The document also defines SIP header field parameters for
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 5, 2013. This Internet-Draft will expire on April 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. History-Info Header Field Protocol Structure . . . . . . . . . 7 5. History-Info Header Field Protocol Structure . . . . . . . . . 7
5.1. History-Info Header Field Example Scenario . . . . . . . . 10 5.1. History-Info Header Field Example Scenario . . . . . . . . 10
6. User Agent Handling of the History-Info Header Field . . . . . 13 6. User Agent Handling of the History-Info Header Field . . . . . 13
6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13 6.1. User Agent Client (UAC) Behavior . . . . . . . . . . . . . 13
6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13 6.2. User Agent Server (UAS) Behavior . . . . . . . . . . . . . 13
7. Proxy/Intermediary Handling of History-Info Header Fields . . 13 6.3. Back-2-Back User Agent (B2BUA) Behavior . . . . . . . . . 13
7. Proxy/Intermediary Handling of History-Info Header Fields . . 14
8. Redirect Server Handling of History-Info Header Fields . . . . 14 8. Redirect Server Handling of History-Info Header Fields . . . . 14
9. Handling of History-Info Header Fields in Requests and 9. Handling of History-Info Header Fields in Requests and
Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 15 9.1. Receiving a Request . . . . . . . . . . . . . . . . . . . 15
9.2. Sending a Request with History-Info . . . . . . . . . . . 15 9.2. Sending a Request with History-Info . . . . . . . . . . . 15
9.3. Receiving a Response with History-Info or Request 9.3. Receiving a Response with History-Info or Request
Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 16 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Sending History-Info in Responses . . . . . . . . . . . . 16 9.4. Sending History-Info in Responses . . . . . . . . . . . . 17
10. Processing the History-Info Header Field . . . . . . . . . . . 17 10. Processing the History-Info Header Field . . . . . . . . . . . 17
10.1. Privacy in the History-Info Header Field . . . . . . . . . 17 10.1. Privacy in the History-Info Header Field . . . . . . . . . 17
10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17 10.1.1. Indicating Privacy . . . . . . . . . . . . . . . . . 17
10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18 10.1.2. Applying Privacy . . . . . . . . . . . . . . . . . . 18
10.2. Reason in the History-Info Header Field . . . . . . . . . 19 10.2. Reason in the History-Info Header Field . . . . . . . . . 19
10.3. Indexing in the History-Info Header Field . . . . . . . . 20 10.3. Indexing in the History-Info Header Field . . . . . . . . 20
10.4. Mechanism for Target Determination in the History-Info 10.4. Mechanism for Target Determination in the History-Info
Header Field . . . . . . . . . . . . . . . . . . . . . . . 21 Header Field . . . . . . . . . . . . . . . . . . . . . . . 21
11. Application Considerations . . . . . . . . . . . . . . . . . . 23 11. Application Considerations . . . . . . . . . . . . . . . . . . 23
12. Application Specific Usage . . . . . . . . . . . . . . . . . . 25 12. Application Specific Usage . . . . . . . . . . . . . . . . . . 25
skipping to change at page 5, line 42 skipping to change at page 5, line 42
for elements involved with the request to obtain additional for elements involved with the request to obtain additional
information relating to how and why the request was routed to a information relating to how and why the request was routed to a
particular destination. The following are examples of such particular destination. The following are examples of such
applications: applications:
1. Web "referral" applications, whereby an application residing 1. Web "referral" applications, whereby an application residing
within a web server determines that a visitor to a website has within a web server determines that a visitor to a website has
arrived at the site via an "associate" site that will receive arrived at the site via an "associate" site that will receive
some "referral" commission for generating this traffic some "referral" commission for generating this traffic
2. Email forwarding whereby the forwarded-to user obtains a detailed 2. Email relaying whereby the recipient obtains a detailed "trace of
"trace of the path" of the message from sender to receiver and at the path" of the message from originator to receiver, including
what time the time of each relay.
3. Traditional telephony services such as voicemail, call-center 3. Traditional telephony services such as voicemail, call-center
"automatic call distribution", and "follow-me" style services "automatic call distribution", and "follow-me" style services
Several of the aforementioned applications currently define Several of the aforementioned applications currently define
application-specific mechanisms through which it is possible to application-specific mechanisms through which it is possible to
obtain the necessary history information. obtain the necessary history information.
In addition, request history information could be used to enhance In addition, request history information could be used to enhance
basic SIP functionality by providing the following: basic SIP functionality by providing the following:
skipping to change at page 9, line 9 skipping to change at page 9, line 9
extensions. As per [RFC3261], any implementation not extensions. As per [RFC3261], any implementation not
understanding an extension MUST ignore it. understanding an extension MUST ignore it.
The ABNF syntax [RFC5234] for the History-Info header field and The ABNF syntax [RFC5234] for the History-Info header field and
header field parameters is as follows: header field parameters is as follows:
History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)
hi-entry = hi-targeted-to-uri *(SEMI hi-param) hi-entry = hi-targeted-to-uri *(SEMI hi-param)
hi-targeted-to-uri = addr-spec / name-addr hi-targeted-to-uri = name-addr
hi-param = hi-index / hi-target-param / hi-extension hi-param = hi-index / hi-target-param / hi-extension
hi-index = "index" EQUAL index-val hi-index = "index" EQUAL index-val
index-val = number *("." number) index-val = number *("." number)
number = [ %31-39 *DIGIT ] DIGIT number = [ %31-39 *DIGIT ] DIGIT
hi-target-param = rc-param / mp-param / np-param hi-target-param = rc-param / mp-param / np-param
rc-param = "rc" EQUAL index-val rc-param = "rc" EQUAL index-val
mp-param = "mp" EQUAL index-val mp-param = "mp" EQUAL index-val
np-param = "np" EQUAL index-val np-param = "np" EQUAL index-val
hi-extension = generic-param hi-extension = generic-param
The ABNF definitions for "generic-param" and "name-addr" are from The ABNF definitions for "generic-param", "name-addr", "HCOLON",
[RFC3261]. "COMMA", "SEMI" and "EQUAL" are from [RFC3261].
This document also extends the "contact-params" for the Contact This document also extends the "contact-params" for the Contact
header field as defined in [RFC3261] with the "rc", "mp" and "np" header field as defined in [RFC3261] with the "rc", "mp" and "np"
header field parameters defined above. header field parameters defined above.
In addition to the parameters defined by the ABNF, an hi-entry may In addition to the parameters defined by the ABNF, an hi-entry may
also include a Reason header field and/or a Privacy header field, also include a Reason header field and/or a Privacy header field,
which are both included in the "headers" component of the hi- which are both included in the "headers" component of the hi-
targeted-to-uri as described below: targeted-to-uri as described below:
skipping to change at page 13, line 8 skipping to change at page 13, line 8
| History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1 | History-Info: <sip:bob@192.0.2.3>;index=1.1.1;rc=1.1
| | | | | | | | | |
| ACK | | | | | ACK | | | |
|--------------->| ACK | | | |--------------->| ACK | | |
| |--------------->| ACK | | | |--------------->| ACK | |
| | |--------------->| | | | |--------------->| |
Figure 1: Basic Call Figure 1: Basic Call
6. User Agent Handling of the History-Info Header Field 6. User Agent Handling of the History-Info Header Field
A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP This section describes the processing specific to UAs(UACs, UASs and
intermediary as an alternative to following the behavior of a user B2BUAs) for the History-Info header."
agent server (UAS) per Section 6.2 and a UAC per Section 6.1. In
behaving as an intermediary, a B2BUA carries forward hi-entries
received in requests at the UAS to requests being forwarded by the
UAC, as well as carrying forward hi-entries in responses received at
the UAC to the responses forwarded by the UAS, subject to privacy
considerations per Section 10.1.
6.1. User Agent Client (UAC) Behavior 6.1. User Agent Client (UAC) Behavior
The UAC MUST include the "histinfo" option tag in the Supported The UAC MUST include the "histinfo" option tag in the Supported
header field in any out-of-dialog requests or initial requests for a header field in any out-of-dialog requests or initial requests for a
dialog for which the UAC would like the History-Info header field in dialog for which the UAC would like the History-Info header field in
the response. When issuing a request, the UAC MUST follow the the response. When issuing a request, the UAC MUST follow the
procedures in Section 9.2. In the case of an initial request, except procedures in Section 9.2. In the case of an initial request, except
where the UAC is part of a B2BUA, there is no cache of hi- entries where the UAC is part of a B2BUA, there is no cache of hi- entries
with which to populate the History-Info header field and the hi-index with which to populate the History-Info header field and the hi-index
skipping to change at page 13, line 43 skipping to change at page 13, line 37
6.2. User Agent Server (UAS) Behavior 6.2. User Agent Server (UAS) Behavior
When receiving a request, a UAS MUST follow the procedures defined in When receiving a request, a UAS MUST follow the procedures defined in
Section 9.2. When sending a response other than a 3xx response, a Section 9.2. When sending a response other than a 3xx response, a
UAS MUST follows the procedures as defined in Section 9.4. When UAS MUST follows the procedures as defined in Section 9.4. When
sending a 3xx response, the UAS MUST follow the procedures defined sending a 3xx response, the UAS MUST follow the procedures defined
for a redirect server per Section 8. An application at the UAS can for a redirect server per Section 8. An application at the UAS can
make use of the cached hi-entries as described in Section 11. make use of the cached hi-entries as described in Section 11.
6.3. Back-2-Back User Agent (B2BUA) Behavior
A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP
intermediary, per Section 7, as an alternative to following the
behavior of a user agent server (UAS) per Section 6.2 and a UAC per
Section 6.1. In behaving as an intermediary, a B2BUA carries forward
hi-entries received in requests at the UAS to requests being
forwarded by the UAC, as well as carrying forward hi-entries in
responses received at the UAC to the responses forwarded by the UAS,
subject to privacy considerations per Section 10.1.
7. Proxy/Intermediary Handling of History-Info Header Fields 7. Proxy/Intermediary Handling of History-Info Header Fields
This section describes the procedures for proxies and other SIP This section describes the procedures for proxies and other SIP
intermediaries for the handling of the History-Info header fields for intermediaries for the handling of the History-Info header fields for
each of the following scenarios: each of the following scenarios:
Receiving a Request: An intermediary MUST follow the procedures in Receiving a Request: An intermediary MUST follow the procedures in
Section 9.1 for the handling of hi-entries in incoming SIP Section 9.1 for the handling of hi-entries in incoming SIP
requests. requests.
skipping to change at page 16, line 28 skipping to change at page 16, line 34
The SIP entity MUST add the hi-entry that was added to the request The SIP entity MUST add the hi-entry that was added to the request
that received the non-100 response or timed out to the cache, if that received the non-100 response or timed out to the cache, if
it was not already cached. The hi-entry MUST be added to the it was not already cached. The hi-entry MUST be added to the
cache in ascending order as indicated by the values in the hi- cache in ascending order as indicated by the values in the hi-
index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2
but before 1.2.2 or 1.3). but before 1.2.2 or 1.3).
Step 2: Add Reason header field Step 2: Add Reason header field
The SIP entity adds one or more Reason header fields to the hi- If the response is not a 100 or 2xx response, the SIP entity adds
targeted-to-uri in the (newly) cached hi-entry reflecting the SIP one or more Reason header fields to the hi-targeted-to-uri in the
response code in the non-100 response, per the procedures of (newly) cached hi-entry reflecting the SIP response code in the
Section 10.2. non-100 or non-2xx response, per the procedures of Section 10.2.
Step 3: Add additional hi-entries Step 3: Add additional hi-entries
The SIP entity MUST also add to the cache any hi-entries received The SIP entity MUST also add to the cache any hi-entries received
in the response that are not already in the cache. This situation in the response that are not already in the cache. This situation
can occur when the entity that generated the non-100 response can occur when the entity that generated the non-100 response
retargeted the request before generating the response. As per retargeted the request before generating the response. As per
Step 1, the hi-entries MUST be added to the cache in ascending Step 1, the hi-entries MUST be added to the cache in ascending
order as indicated by the values in the hi-index parameters of the order as indicated by the values in the hi-index parameters of the
hi-entries hi-entries
skipping to change at page 18, line 36 skipping to change at page 18, line 41
intermediary is not responsible, a Privacy Service at the boundary of intermediary is not responsible, a Privacy Service at the boundary of
the domain applies the appropriate privacy based on the value of the the domain applies the appropriate privacy based on the value of the
Privacy header field in the message header or in the "headers" Privacy header field in the message header or in the "headers"
component of the hi-targeted-to-uri in the individual hi-entries. component of the hi-targeted-to-uri in the individual hi-entries.
If there is a Privacy header field in the message header of a request If there is a Privacy header field in the message header of a request
or response, with a priv-value of "header" or "history", then all the or response, with a priv-value of "header" or "history", then all the
hi-targeted-to-uris in the hi-entries, associated with the domain for hi-targeted-to-uris in the hi-entries, associated with the domain for
which the SIP intermediary is responsible, are anonymized by the which the SIP intermediary is responsible, are anonymized by the
Privacy Service. The Privacy Service MUST change any hi-targeted-to- Privacy Service. The Privacy Service MUST change any hi-targeted-to-
uris in these hi-entries that have not been anonymized(evidenced by uris in these hi-entries that have not been anonymized (evidenced by
their domain not being "anonymous.invalid") to anonymous URIs their domain not being "anonymous.invalid") to anonymous URIs
containing a domain of anonymous.invalid (e.g., containing a domain of anonymous.invalid as recommended in section
anonymous@anonymous.invalid). If there is a Privacy header field in 4.1.1.3 of [RFC3323]. As defined in section 4.1.1.2 of [RFC3323] the
the "headers" component of the hi-targeted-to-uri in the hi-entries, recommendations of [RFC3261] for anonymyzing the URI Username SHOULD
then the Privacy header field value MUST be removed from the hi- be followed (i.e., "anonymous" in the user portion of the URI). If
entry. Once all the appropriate hi-entries have been anonymized, the there is a Privacy header field in the "headers" component of the hi-
Privacy Service MUST remove the priv-value of "history" from the targeted-to-uri in the hi-entries, then the Privacy header field
Privacy header field in the message header of the request or value MUST be removed from the hi- entry. Once all the appropriate
response. If there are no remaining priv-values in the Privacy hi-entries have been anonymized, the Privacy Service MUST remove the
header field, the Privacy Service MUST remove the Privacy header priv-value of "history" from the Privacy header field in the message
field from the request or response per [RFC3323]. header of the request or response. If there are no remaining priv-
values in the Privacy header field, the Privacy Service MUST remove
the Privacy header field from the request or response per [RFC3323].
If there is not a Privacy header field in the message header of the If there is not a Privacy header field in the message header of the
request or response that is being forwarded, but there is a Privacy request or response that is being forwarded, but there is a Privacy
header field with a priv-value of "history" in the "headers" header field with a priv-value of "history" in the "headers"
component in any of the hi-targeted-uris in the hi-entries associated component in any of the hi-targeted-uris in the hi-entries associated
with the domain for which a SIP intermediary is responsible, then the with the domain for which a SIP intermediary is responsible, then the
Privacy Service MUST update those hi-targeted-to-uris as described Privacy Service MUST update those hi-targeted-to-uris as described
above. Any other priv-values in the Privacy header field in the above. Any other priv-values in the Privacy header field in the
"headers" component of the hi-targeted-to-uris in the hi-entries MUST "headers" component of the hi-targeted-to-uris in the hi-entries MUST
be ignored. In any case, the Privacy Service MUST remove the Privacy be ignored. In any case, the Privacy Service MUST remove the Privacy
header field from the "headers" compenent of the hi-targeted-to-uris header field from the "headers" compenent of the hi-targeted-to-uris
in the hi-entries prior to forwarding. in the hi-entries prior to forwarding.
10.2. Reason in the History-Info Header Field 10.2. Reason in the History-Info Header Field
A Reason header field is added to the "headers" component in an hi- A Reason header field is added to the "headers" component in an hi-
targeted-to-uri when the hi-entry is added to the cache based upon targeted-to-uri when the hi-entry is added to the cache based upon
the receipt of a non-100 or non-2xx SIP response, as described in the receipt of a SIP response that is neither a 100 nor a 2xx
Section 9.3. If the Reason header field is being added due to response, as described in Section 9.3. If the Reason header field is
receipt of an explicit SIP response and the response contains any being added due to receipt of an explicit SIP response and the
Reason header fields (see [RFC3326]), then the SIP entity MUST response contains any Reason header fields (see [RFC3326]), then the
include the Reason header fields in the "headers" component of the SIP entity MUST include the Reason header fields in the "headers"
hi-targeted-to-uri in the last hi-entry added to the cache, unless
the hi-targeted-to-uri is a Tel-URI. If the SIP response does not
contain a Reason header field, the SIP entity MUST include a Reason
header field, containing the SIP Response Code, in the "headers"
component of the hi-targeted-to-uri in the last hi-entry added to the component of the hi-targeted-to-uri in the last hi-entry added to the
cache, unless the hi-targeted-to-uri is a Tel-URI. cache, unless the hi-targeted-to-uri is a Tel-URI. If the SIP
response does not contain a Reason header field, the SIP entity MUST
include a Reason header field, containing the SIP Response Code, in
the "headers" component of the hi-targeted-to-uri in the last hi-
entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI.
If a request has timed out (instead of being explicitly rejected), If a request has timed out (instead of being explicitly rejected),
the SIP entity MUST update the cache as if the request received a SIP the SIP entity MUST update the cache as if the request received a SIP
error response code of 408 "Request Timeout". error response code of 408 "Request Timeout".
A request can receive multiple non-100 non-2xx responses which carry A request can receive multiple responses, that are neither 100 nor
or imply (for responses without Reason headers, and for timeouts) 2xx responses, which carry or imply (for responses without Reason
multiple, possibly duplicated, reason-values to be applied to an hi- headers, and for timeouts) multiple, possibly duplicated, reason-
targeted-to-uri. In these situations, the SIP entity creating values to be applied to an hi- targeted-to-uri. In these situations,
History-Info header value would choose the appropriate Reason header the SIP entity creating History-Info header value would choose the
field value. appropriate Reason header field value.
A SIP entity MAY also include a Reason header field in the "headers" A SIP entity MAY also include a Reason header field in the "headers"
component of an hi-targeted-to-uri containing the URI of a request component of an hi-targeted-to-uri containing the URI of a request
that was retargeted as a result of internal retargeting. that was retargeted as a result of internal retargeting.
If additional Reason header field parameters are defined in the If additional Reason header field parameters are defined in the
future per [RFC3326], the use of these Reason header field parameters future per [RFC3326], the use of these Reason header field parameters
for the History-Info header field MUST follow the same rules as for the History-Info header field MUST follow the same rules as
described above. described above.
skipping to change at page 26, line 17 skipping to change at page 26, line 17
with Request History Information". with Request History Information".
13. Security Considerations 13. Security Considerations
The security requirements for this specification are specified in The security requirements for this specification are specified in
Appendix A.1. Appendix A.1.
This document defines a header field for SIP. The use of the This document defines a header field for SIP. The use of the
Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to Transport Layer Security (TLS) protocol [RFC5246] as a mechanism to
ensure the overall confidentiality of the History-Info header fields ensure the overall confidentiality of the History-Info header fields
(SEC-req-4) is strongly RECOMMENDED. This results in History-Info (SEC-req-4) is strongly RECOMMENDED. If TLS is NOT used, the
having at least the same level of security as other headers in SIP intermediary MUST ensure that the messages are only sent within an
that are inserted by intermediaries. With TLS, History-Info header environment that is secured by other means or that the messages don't
fields are no less, nor no more, secure than other SIP header fields, leave the intermediary's domain. This results in History-Info having
which generally have even more impact on the subsequent processing of at least the same level of security as other headers in SIP that are
SIP sessions than the History-Info header field. inserted by intermediaries. With TLS, History-Info header fields are
no less, nor no more, secure than other SIP header fields, which
generally have even more impact on the subsequent processing of SIP
sessions than the History-Info header field.
Note that while using the SIPS scheme (as per [RFC5630]) protects Note that while using the SIPS scheme (as per [RFC5630]) protects
History-Info from tampering by arbitrary parties outside the SIP History-Info from tampering by arbitrary parties outside the SIP
message path, all the intermediaries on the path are trusted message path, all the intermediaries on the path are trusted
implicitly. A malicious intermediary could arbitrarily delete, implicitly. A malicious intermediary could arbitrarily delete,
rewrite, or modify History-Info. This specification does not attempt rewrite, or modify History-Info. This specification does not attempt
to prevent or detect attacks by malicious intermediaries. to prevent or detect attacks by malicious intermediaries.
In terms of ensuring the privacy of hi-entries, the same security In terms of ensuring the privacy of hi-entries, the same security
considerations as those described in [RFC3323] apply. Namely if the considerations as those described in [RFC3323] apply. The privacy
entity requesting privacy wants to ensure privacy is applied to the service that's defined in [RFC3323] MUST also support the new privacy
hi-entries, a Privacy Service that supports both [RFC3323] and this header field priv-value of "history" and anonymize hi-entries in the
specification is REQUIRED in the entity's domain, so that the privacy case of a priv-value of "header" as described in Section 10.1.2.
can be applied, as described in Section 10.1.2, when a request or
response leaves the domain.
14. IANA Considerations 14. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
This document obsoletes [RFC4244] but uses the same SIP header field This document obsoletes [RFC4244] but uses the same SIP header field
name, Privacy header field and Option tag. The IANA registry needs name, Privacy header field and Option tag. The IANA registry needs
to update the references to [RFC4244] with [RFC XXXX], where XXXX is to update the references to [RFC4244] with [RFC XXXX], where XXXX is
the RFC number for this document. the RFC number for this document.
skipping to change at page 27, line 43 skipping to change at page 27, line 43
14.2. Registration of "history" for SIP Privacy Header Field 14.2. Registration of "history" for SIP Privacy Header Field
This document defines a priv-value for the SIP Privacy header field: This document defines a priv-value for the SIP Privacy header field:
history. The following updates have been made to history. The following updates have been made to
http://www.iana.org/assignments/sip-priv-values. The following has http://www.iana.org/assignments/sip-priv-values. The following has
been updated in the registration for the SIP Privacy header field: been updated in the registration for the SIP Privacy header field:
Name Description Registrant Reference Name Description Registrant Reference
---- ----------- ---------- --------- ---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC XXXX] history Privacy requested for Mary Barnes [RFC XXXX]
History-Info header mary.barnes@polycom.com History-Info header mary.ietf.barnes@gmail.com
fields(s) fields(s)
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
14.3. Registration of Header Field Parameters 14.3. Registration of Header Field Parameters
This specification defines the following new SIP header field This specification defines the following new SIP header field
parameters in the SIP Header Field parameter sub-registry in the SIP parameters in the SIP Header Field parameter sub-registry in the SIP
Parameter Registry, http:/www.iana.org/assignments/sip-parameters. Parameter Registry, http:/www.iana.org/assignments/sip-parameters.
Header Field Parameter Name Predefined Reference Header Field Parameter Name Predefined Reference
Values Values
_____________________________________________________________________ ____________________________________________________________________
History-Info mp No [RFC xxxx] History-Info mp No [RFC xxxx]
History-Info rc No [RFC xxxx] History-Info rc No [RFC xxxx]
History-Info np No [RFC xxxx] History-Info np No [RFC xxxx]
Contact mp No [RFC xxxx] Contact mp No [RFC xxxx]
Contact rc No [RFC xxxx] Contact rc No [RFC xxxx]
Contact np No [RFC xxxx] Contact np No [RFC xxxx]
Note to RFC Editor: Please replace RFC XXXX with the RFC number of Note to RFC Editor: Please replace RFC XXXX with the RFC number of
this specification. this specification.
15. Acknowledgements 15. Acknowledgements
Jonathan Rosenberg et al produced the document that provided Jonathan Rosenberg et al produced the document that provided
additional use cases precipitating the requirement for the new header additional use cases precipitating the requirement for the new header
parameters to capture the method by which a Request URI is parameters to capture the method by which a Request URI is
determined. The authors would like to acknowledge the constructive determined. The authors would like to acknowledge the constructive
skipping to change at page 33, line 10 skipping to change at page 33, line 10
[RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session [RFC4458] Jennings, C., Audet, F., and J. Elwell, "Session
Initiation Protocol (SIP) URIs for Applications such as Initiation Protocol (SIP) URIs for Applications such as
Voicemail and Interactive Voice Response (IVR)", RFC 4458, Voicemail and Interactive Voice Response (IVR)", RFC 4458,
April 2006. April 2006.
[I-D.ietf-sipcore-rfc4244bis-callflows] [I-D.ietf-sipcore-rfc4244bis-callflows]
Barnes, M., Audet, F., Schubert, S., Elburg, H., and C. Barnes, M., Audet, F., Schubert, S., Elburg, H., and C.
Holmberg, "Session Initiation Protocol (SIP) History-Info Holmberg, "Session Initiation Protocol (SIP) History-Info
Header Call Flow Examples", Header Call Flow Examples",
draft-ietf-sipcore-rfc4244bis-callflows-01 (work in draft-ietf-sipcore-rfc4244bis-callflows-06 (work in
progress), September 2012. progress), July 2013.
Appendix A. Request History Requirements Appendix A. Request History Requirements
The following list constitutes a set of requirements for a "Request The following list constitutes a set of requirements for a "Request
History" capability. History" capability.
1. CAPABILITY-req: The "Request History" capability provides a 1. CAPABILITY-req: The "Request History" capability provides a
capability to inform proxies and UAs involved in processing a capability to inform proxies and UAs involved in processing a
request about the history/progress of that request. Although request about the history/progress of that request. Although
this is inherently provided when the retarget is in response to a this is inherently provided when the retarget is in response to a
 End of changes. 23 change blocks. 
76 lines changed or deleted 85 lines changed or added

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