< draft-ietf-sip-history-info-05.txt   draft-ietf-sip-history-info-06.txt >
INTERNET-DRAFT M. Barnes INTERNET-DRAFT M. Barnes
Document: draft-ietf-sip-history-info-05.txt Editor Document: draft-ietf-sip-history-info-06.txt Editor
Category: Standards Track Nortel Networks Category: Standards Track Nortel Networks
Expires: June 6, 2005 Dec. 6, 2004 Expires: July 17th, 2005 Jan 17th, 2005
An Extension to the Session Initiation Protocol for Request History An Extension to the Session Initiation Protocol for Request History
Information Information
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 6th, 2005. This Internet-Draft will expire on July 17th, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This draft defines a standard mechanism for capturing the history This document defines a standard mechanism for capturing the history
information associated with a SIP request. This capability enables information associated with a SIP request. This capability enables
many enhanced services by providing the information as to how and why many enhanced services by providing the information as to how and why
a call arrives at a specific application or user. This draft defines a call arrives at a specific application or user. This document
a new optional SIP header, History-Info, for capturing the history defines a new optional SIP header, History-Info, for capturing the
information in requests. A new option tag, Histinfo, to be included history information in requests.
in the Supported header, is defined to allow UAs to indicate whether
the History-Info should be returned in responses to a request which
has captured the history information. A new priv-value, history, is
added to the Privacy header to allow for privacy handling of the
History-Info header.
Table of Contents Table of Contents
1.Background: Why define a Generic "Request History" capability?.3 1.Background: Why define a Generic "Request History" capability?.3
2. "Request History" Requirements.................................4 2. "Request History" Requirements.................................4
2.1 Security Requirements......................................6 2.1 Security Requirements......................................5
2.2 Privacy Requirements.......................................6 2.2 Privacy Requirements.......................................6
3. Request History Information Description........................7 3. Request History Information Description........................7
3.1 Optionality of History-Info................................8 3.1 Optionality of History-Info................................8
3.2 Securing History-Info......................................8 3.2 Securing History-Info......................................8
3.3 Ensuring the Privacy of History-Info.......................9 3.3 Ensuring the Privacy of History-Info.......................8
4 Request History Information Protocol Details....................9 4 Request History Information Protocol Details....................9
4.1 Protocol Structure of History-Info.........................9 4.1 Protocol Structure of History-Info.........................9
4.2 Protocol Examples.........................................11 4.2 Protocol Examples.........................................11
4.3 Protocol usage............................................11 4.3 Protocol usage............................................11
4.4 Security for History-Info.................................18 4.4 Security for History-Info.................................18
4.5 Example Applications using History-Info...................18 4.5 Example Applications using History-Info...................18
5. Application Considerations....................................23 5. Application Considerations....................................23
6. Security Considerations.......................................24 6. Security Considerations.......................................24
7. IANA Considerations...........................................24 7. IANA Considerations...........................................24
Normative References.............................................25 Normative References.............................................25
Informational References.........................................26 Informational References.........................................25
Appendix. Example Scenarios......................................27 Appendix. Example Scenarios......................................27
Appendix A. Sequentially forking (History-Info in Response)......28 Appendix A. Sequentially forking (History-Info in Response)......27
Appendix B. Voicemail...........................................33 Appendix B. Voicemail...........................................32
Appendix C. Automatic Call Distribution Example.................38 Appendix C. Automatic Call Distribution Example.................38
Appendix D. Session via Redirect and Proxy Servers...............39 Appendix D. Session via Redirect and Proxy Servers...............39
Overview Overview
Many services that SIP is anticipated to support require the ability Many services that SIP is anticipated to support require the ability
to determine why and how the call arrived at a specific application. to determine why and how the call arrived at a specific application.
Examples of such services include (but are not limited to) sessions Examples of such services include (but are not limited to) sessions
initiated to call centers via "click to talk" SIP URLs on a web page, initiated to call centers via "click to talk" SIP Uniform Resource
"call history/logging" style services within intelligent "call Locators (URLs) on a web page, "call history/logging" style services
management" software for SIP UAs and calls to voicemail servers. within intelligent "call management" software for SIP User Agents
While SIP implicitly provides the redirect/retarget capabilities that (UAs) and calls to voicemail servers. While SIP implicitly provides
enable calls to be routed to chosen applications, there is currently the redirect/retarget capabilities that enable calls to be routed to
no standard mechanism within SIP for communicating the history of chosen applications, there is currently no standard mechanism within
such a request. This "request history" information allows the SIP for communicating the history of such a request. This "request
receiving application to determine hints about how and why the call history" information allows the receiving application to determine
arrived at the application/user. This draft defines a new SIP header, hints about how and why the call arrived at the application/user.
History-Info, to provide a standard mechanism for capturing the
request history information to enable a wide variety of services for This document defines a new SIP header, History-Info, to provide a
networks and end users. The History-Info header provides a building standard mechanism for capturing the request history information to
block for development of new services. enable a wide variety of services for networks and end users. The
History-Info header provides a building block for development of new
services.
Section 1 provides additional background motivation for the Request Section 1 provides additional background motivation for the Request
History capability. Section 2 identifies the requirements for a History capability. Section 2 identifies the requirements for a
solution, with Section 3 providing an overall description of the solution, with Section 3 providing an overall description of the
solution. solution.
Section 4 provides the details of the additions to the SIP protocol. Section 4 provides the details of the additions to the SIP protocol.
Example uses of the new header are included in Section 4.5, with Example uses of the new header are included in Section 4.5, with
additional scenarios included in the Appendix. It is anticipated that additional scenarios included in the Appendix.
these may be evolved and progressed in a general Service examples
draft such as [SIPSVCEX] or individual informational drafts
describing these specific services, since the History-Info header is
just one of the building blocks for implementing these services.
Individual drafts would be particularly useful for documenting
services for which there are multiple solutions, as it is not the
intent, nor is it within the scope, of this draft to prescribe a
complete solution for any of these applications.
Section 5 summarizes the application considerations identified in the Section 5 summarizes the application considerations identified in the
previous sections. Section 6 summarizes the security solution. previous sections. Section 6 summarizes the security solution.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.Background: Why define a Generic "Request History" capability? 1.Background: Why define a Generic "Request History" capability?
SIP implicitly provides redirect/retarget capabilities that enable SIP implicitly provides redirect/retarget capabilities that enable
calls to be routed to specific applications as defined in [RFC3261]. calls to be routed to specific applications as defined in [RFC3261].
The term retarget will be used henceforth in this draft to refer to The term 'retarget' will be used henceforth in this document to refer
the process of a Proxy Server/UAC changing a URI in a request and to the process of a Proxy Server/User Agent Client (UAC) changing a
thus changing the target of the request. This term is chosen to Uniform Resource Identifier(URI) in a request and thus changing the
avoid associating this request history only with the specific SIP target of the request. This term is chosen to avoid associating this
Redirect Server capability that provides for a response to be sent request history only with the specific SIP Redirect Server capability
back to a UAC requesting that the UAC should retarget the original that provides for a response to be sent back to a UAC requesting that
request to an alternate URI. The rules for determining request the UAC should retarget the original request to an alternate URI.
targets as described in section 16.5 of [RFC3261] are consistent with The rules for determining request targets as described in section
the use of the retarget term in this draft. 16.5 of [RFC3261] are consistent with the use of the retarget term in
this document.
The motivation for the request history is that in the process of The motivation for the request history is that in the process of
retargeting old routing information can be forever lost. This lost retargeting old routing information can be forever lost. This lost
information may be important history that allows elements to which information may be important history that allows elements to which
the call is retargeted to process the call in a locally defined, the call is retargeted to process the call in a locally defined,
application specific manner. The proposal in this draft is to provide application specific manner. The proposal in this document is to
a mechanism for transporting the request history. It is not provide a mechanism for transporting the request history. It is not
proposing any application specific behavior for a Proxy or UA upon proposing any application specific behavior for a Proxy or UA upon
receipt of the information. Indeed, such behavior should be a local receipt of the information. Indeed, such behavior should be a local
decision for the recipient application. decision for the recipient application.
Current network applications provide the ability for elements Current network applications provide the ability for elements
involved with the call to exchange additional information relating to involved with the call to exchange additional information relating to
how and why the call was routed to a particular destination. The how and why the call was routed to a particular destination. The
following are examples of such applications: following are examples of such applications:
1. Web "referral" applications, whereby an application residing 1. Web "referral" applications, whereby an application residing
skipping to change at page 7, line 39 skipping to change at page 7, line 32
request is forwarded in a new header for SIP messages: History-Info request is forwarded in a new header for SIP messages: History-Info
(CONTENT-req). This allows for the capturing of the history of a (CONTENT-req). This allows for the capturing of the history of a
request that would be lost with the normal SIP processing involved in request that would be lost with the normal SIP processing involved in
the subsequent forwarding of the request. This solution proposes no the subsequent forwarding of the request. This solution proposes no
changes in the fundamental determination of request targets or in the changes in the fundamental determination of request targets or in the
request forwarding as defined in sections 16.5 and 16.6 of the SIP request forwarding as defined in sections 16.5 and 16.6 of the SIP
protocol specification [RFC3261]. protocol specification [RFC3261].
The History-Info header can appear in any request not associated with The History-Info header can appear in any request not associated with
an established dialog (e.g. INVITE, REGISTER, MESSAGE, REFER and an established dialog (e.g. INVITE, REGISTER, MESSAGE, REFER and
OPTIONS, etc.) (REQUEST-VALIDITY-req) and any valid response to these OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any
requests. (ISSUER-req) valid response to these requests. (ISSUER-req)
The History-Info header is added to a Request when a new request is The History-Info header is added to a Request when a new request is
created by a UAC or forwarded by a Proxy, or when the target of a created by a UAC or forwarded by a Proxy, or when the target of a
request is changed. The term 'retarget' is introduced to refer to request is changed. The term 'retarget' is introduced to refer to
this changing of the target of a request and the subsequent this changing of the target of a request and the subsequent
forwarding of that request. It should be noted that retargeting only forwarding of that request. It should be noted that retargeting only
occurs when the Request-URI indicates a domain for which the occurs when the Request-URI indicates a domain for which the
processing entity is responsible. In terms of the SIP protocol, the processing entity is responsible. In terms of the SIP protocol, the
processing associated with retargeting is described in sections 16.5, processing associated with retargeting is described in sections 16.5,
and 16.6 of [RFC3261]. As described in section 16.5 of [RFC3261], it and 16.6 of [RFC3261]. As described in section 16.5 of [RFC3261], it
skipping to change at page 8, line 19 skipping to change at page 8, line 11
that the History Information is captured as an optional, additional that the History Information is captured as an optional, additional
header field. Thus, the addition of the History-Info header does not header field. Thus, the addition of the History-Info header does not
impact fundamental SIP Request Forwarding. An entity (UA or proxy) impact fundamental SIP Request Forwarding. An entity (UA or proxy)
changing the target of a request in response to a redirect or REFER changing the target of a request in response to a redirect or REFER
SHOULD also propagate any History-Info header from the initial SHOULD also propagate any History-Info header from the initial
Request in the new request (GENERATION-req, FORWARDS-req). Request in the new request (GENERATION-req, FORWARDS-req).
3.1 Optionality of History-Info 3.1 Optionality of History-Info
The History-Info header is optional in that neither UAs nor Proxies The History-Info header is optional in that neither UAs nor Proxies
are required to support it. A new Supported header, Histinfo, is are required to support it. A new Supported header, "histinfo", is
included in the Request to indicate whether the History-Info header included in the Request to indicate whether the History-Info header
is returned in Responses (BACKWARDS-req). In addition to the Histinfo is returned in Responses (BACKWARDS-req). In addition to the
Supported header, local policy determines whether or not the header "histinfo" Supported header, local policy determines whether or not
is added to any request, or for a specific Request-URI, being the header is added to any request, or for a specific Request-URI,
retargeted. It is possible that this could restrict the applicability being retargeted. It is possible that this could restrict the
of services which make use of the Request History Information to be applicability of services which make use of the Request History
limited to retargeting within domain(s) controlled by the same local Information to be limited to retargeting within domain(s) controlled
policy, or between domain(s) which negotiate policies with other by the same local policy, or between domain(s) which negotiate
domains to ensure support of the given policy, or services for which policies with other domains to ensure support of the given policy, or
"complete" History Information isn't required to provide the service. services for which complete History Information isn't required to
(OPTIONALITY-req) All applications making use of the History-info provide the service. (OPTIONALITY-req) All applications making use
header MUST clearly define the impact of the information not being of the History-info header MUST clearly define the impact of the
available and specify the processing of such a request. information not being available and specify the processing of such a
request.
3.2 Securing History-Info 3.2 Securing History-Info
This draft defines a new header for SIP. The draft RECOMMENDs the use This document defines a new header for SIP. The document strongly
of TLS as a mandatory mechanism to ensure the overall confidentiality RECOMMENDs the use of the Transport Layer Security (TLS) protocol
of the History-Info headers (SEC-req-4). This results in History-Info [RFC2246] as a mandatory mechanism to ensure the overall
having at least the same level of security as other headers in SIP confidentiality of the History-Info headers (SEC-req-4). This results
which are inserted by intermediaries. If TLS is not available for the in History-Info having at least the same level of security as other
connection over which the request is being forwarded, then the headers in SIP which are inserted by intermediaries. If TLS is not
request MUST not include the History-Info header or the request MUST available for the connection over which the request is being
be redirected to the client, including the History-Info header, so forwarded, then the request MUST not include the History-Info header
that the request can be retargeted by the client. or the request MUST be redirected to the client, including the
History-Info header, so that the request can be retargeted by the
client.
With the level of security provided by TLS (SEC-req-3), the With the level of security provided by TLS (SEC-req-3), the
information in the History-Info header can thus be evaluated to information in the History-Info header can thus be evaluated to
determine if information has been removed by evaluating the indices determine if information has been removed by evaluating the indices
for gaps (SEC-req-1, SEC-req-2). It would be up to the application for gaps (SEC-req-1, SEC-req-2). It would be up to the application
to define whether it can make use of the information in the case of to define whether it can make use of the information in the case of
missing entries. missing entries.
3.3 Ensuring the Privacy of History-Info 3.3 Ensuring the Privacy of History-Info
Since the History-Info header can inadvertently reveal information Since the History-Info header can inadvertently reveal information
about the requestor as described in [RFC3323], the Privacy header about the requestor as described in [RFC3323], the Privacy header
SHOULD be used to determine whether an intermediary can include the SHOULD be used to determine whether an intermediary can include the
History-Info header in a Request that it receives and forwards (PRIV- History-Info header in a Request that it receives and forwards (PRIV-
req-2) or that it retargets (PRIV-req-1). Thus, the History-Info req-2) or that it retargets (PRIV-req-1). Thus, the History-Info
header SHOULD not be included in Requests where the requestor has header SHOULD not be included in Requests where the requestor has
indicated a priv-value of Session or Header level privacy. indicated a priv-value of Session or Header level privacy.
In addition, the History-Info header can reveal general routing In addition, the History-Info header can reveal general routing
information, which may be viewed by a specific intermediary or information, which may be viewed by a specific intermediary or
skipping to change at page 10, line 49 skipping to change at page 10, line 44
a hi-targeted-to-uri when it is first added in a History-info a hi-targeted-to-uri when it is first added in a History-info
header, but rather is added when the retargeting actually header, but rather is added when the retargeting actually
occurs. Note, that this does appear to complicate the security occurs. Note, that this does appear to complicate the security
problem, however, retargeting only occurs when the hi-targeted- problem, however, retargeting only occurs when the hi-targeted-
to-uri indicates a domain for which the processing entity is to-uri indicates a domain for which the processing entity is
responsible, thus it would be the same processing entity that responsible, thus it would be the same processing entity that
initially added the hi-targeted-to-URI to the header that would initially added the hi-targeted-to-URI to the header that would
be updating it with the Reason. be updating it with the Reason.
o Privacy: An optional parameter for History-info, reflected in o Privacy: An optional parameter for History-info, reflected in
the History-Info header by including the Privacy Header the History-Info header field values by including the Privacy
[RFC3323] with a priv-value of "history" escaped in the hi- Header [RFC3323] with a priv-value of "history" escaped in the
targeted-to-uri or by adding the Privacy header with a priv- hi-targeted-to-uri or by adding the Privacy header with a priv-
value of "history" to the Request. The use of the Privacy value of "history" to the Request. The use of the Privacy
Header with a priv-value of "history" indicates whether a Header with a priv-value of "history" indicates whether a
specific or all History-Info headers should not be forwarded. specific or all History-Info headers should not be forwarded.
o Extension (hi-extension): An optional parameter to allow for o Extension (hi-extension): An optional parameter to allow for
future optional extensions. As per the [RFC3261], any future optional extensions. As per the [RFC3261], any
implementation not understanding an extension should ignore it. implementation not understanding an extension should ignore it.
The following summarizes the syntax of the History-Info header, based The following summarizes the syntax of the History-Info header, based
upon the standard SIP syntax [RFC3261]: upon the standard SIP syntax [RFC3261]:
History-Info = "History-Info" HCOLON History-Info = "History-Info" HCOLON
hi-entry *(COMMA hi-entry) hi-entry *(COMMA hi-entry)
skipping to change at page 11, line 37 skipping to change at page 11, line 33
hi-extension = generic-param hi-extension = generic-param
4.2 Protocol Examples 4.2 Protocol Examples
The following provides some examples of the History-Info header. Note The following provides some examples of the History-Info header. Note
that the backslash and CRLF between the fields in the examples below that the backslash and CRLF between the fields in the examples below
are for readability purposes only. are for readability purposes only.
History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\ History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\
Cause%3D302%3Btext%3D%22Moved%20Temporarily%22>; cause%3D302>;index=1;foo=bar
index=1; foo=bar
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B \ History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B \
Cause%3D302%3Btext%3D%22Moved%20Temporarily%22>; index=1.1, cause%3D302>; index=1.1,
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\ <sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
Cause%3D486%3Btext%3D%22Busy%20Here%22>;index=1.2, cause%3D486>;index=1.2,
<sip:45432@vm.example.com>;index=1.3 <sip:45432@vm.example.com>;index=1.3
4.3 Protocol usage 4.3 Protocol usage
This section describes the processing specific to UAs and Proxies for This section describes the processing specific to UAs and Proxies for
the History-Info header, the Histinfo option tag and the priv-value the History-Info header, the "histinfo" option tag and the priv-value
of "history". As discussed in section 1, the fundamental objective is of "history". As discussed in section 1, the fundamental objective is
to capture the target Request-URIs as a request is forwarded. This to capture the target Request-URIs as a request is forwarded. This
allows for the capturing of the history of a request that would be allows for the capturing of the history of a request that would be
lost due to subsequent (re)targeting and forwarding. To accomplish lost due to subsequent (re)targeting and forwarding. To accomplish
this for the entire history of a request, either the UAC must capture this for the entire history of a request, either the UAC must capture
the Request-URI in a History-Info header in the initial request or a the Request-URI in a History-Info header in the initial request or a
proxy must add a History-Info header with both an hi-entry for the proxy must add a History-Info header with both an hi-entry for the
Request-URI in the initial request and an hi-entry for the target Request-URI in the initial request and an hi-entry for the target
Request-URI as the request is forwarded. The basic processing is for Request-URI as the request is forwarded. The basic processing is for
each entity forwarding a request to add an hi-entry for the target each entity forwarding a request to add an hi-entry for the target
Request-URI, updating the index and adding the Reason as appropriate Request-URI, updating the index and adding the Reason as appropriate
for any retargeted Request-URI. for any retargeted Request-URI.
4.3.1 UAC Behavior 4.3.1 User Agent Client (UAC) Behavior
The UAC SHOULD include the Histinfo option tag in the Supported The UAC SHOULD include the "histinfo" option tag in the Supported
header in any request not associated with an established dialog for header in any request not associated with an established dialog for
which the UAC would like the History-Info header in the Response. In which the UAC would like the History-Info header in the Response. In
addition, the UAC SHOULD initiate the capturing of the History addition, the UAC SHOULD initiate the capturing of the History
Information by adding a History-Info header, using the Request-URI of Information by adding a History-Info header, using the Request-URI of
the request as the hi-targeted-to-uri and initializing the index to the request as the hi-targeted-to-uri and initializing the index to
the RECOMMENDED value of 1 in the hi-entry. the RECOMMENDED value of 1 in the hi-entry.
In the case where the request is routed to a redirect server and the In the case where the request is routed to a redirect server and the
UAC receives a 3xx response with a Contact header, the UAC MAY UAC receives a 3xx response with a Contact header, the UAC MAY
maintain the previous hi-entry(s) in the request. In this case, the maintain the previous hi-entry(s) in the request. In this case, the
skipping to change at page 12, line 45 skipping to change at page 12, line 40
entry, thus following the same rules as those prescribed for a proxy entry, thus following the same rules as those prescribed for a proxy
in retargeting, described in section 4.3.3.1.3. An example of this in retargeting, described in section 4.3.3.1.3. An example of this
scenario can be found in Appendix D. scenario can be found in Appendix D.
A UAC that does not want the History-Info header added due to privacy A UAC that does not want the History-Info header added due to privacy
considerations SHOULD include a Privacy header with a priv-value(s) considerations SHOULD include a Privacy header with a priv-value(s)
of "session", "header" or "history" in the request. of "session", "header" or "history" in the request.
With the exception of the processing of a 3xx response described With the exception of the processing of a 3xx response described
above, the processing of the History-Info header received in the above, the processing of the History-Info header received in the
Response is application specific and outside the scope of this draft. Response is application specific and outside the scope of this
However, the validity of the information SHOULD be ensured prior to document. However, the validity of the information SHOULD be ensured
any application usage. For example, the entries MAY be evaluated to prior to any application usage. For example, the entries MAY be
determine gaps in indices, which could indicate that an entry has evaluated to determine gaps in indices, which could indicate that an
been maliciously removed or removed for privacy reasons. Either way, entry has been maliciously removed or removed for privacy reasons.
an application MAY want to be aware of potentially missing Either way, an application MAY want to be aware of potentially
information. missing information.
4.3.2 UAS Behavior 4.3.2 User Agent Server (UAS) Behavior
The processing of the History-Info header by a UAS in a Request The processing of the History-Info header by a UAS in a Request
depends upon local policy and specific applications at the UAS which depends upon local policy and specific applications at the UAS which
might make use of the information. Prior to any application usage of might make use of the information. Prior to any application usage of
the information, the validity SHOULD be ascertained. For example, the information, the validity SHOULD be ascertained. For example,
the entries MAY be evaluated to determine gaps in indices, which the entries MAY be evaluated to determine gaps in indices, which
could indicate that an entry has been maliciously removed or removed could indicate that an entry has been maliciously removed or removed
for privacy reasons. Either way, an application MAY want to be aware for privacy reasons. Either way, an application MAY want to be aware
of potentially missing information. of potentially missing information.
If the Histinfo option tag is received in a request, the UAS SHOULD If the "histinfo" option tag is received in a request, the UAS SHOULD
include any History-Info received in the request in the subsequent include any History-Info received in the request in the subsequent
response. response.
4.3.3 Proxy Behavior 4.3.3 Proxy Behavior
The inclusion of the History-Info header in a Request does not alter The inclusion of the History-Info header in a Request does not alter
the fundamental processing of proxies for determining request targets the fundamental processing of proxies for determining request targets
as defined in section 16.5 of [RFC3261]. Whether a proxy adds the as defined in section 16.5 of [RFC3261]. Whether a proxy adds the
History-Info header or a new hi-entry as it forwards a Request History-Info header or a new hi-entry as it forwards a Request
depends upon the following considerations: depends upon the following considerations:
1. Whether the Request contains the Histinfo option tag in the 1. Whether the Request contains the "histinfo" option tag in the
Supported header. Supported header.
2. Whether the proxy supports the History-Info header. 2. Whether the proxy supports the History-Info header.
3. Whether the Request contains a Privacy header with a priv- 3. Whether the Request contains a Privacy header with a priv-
value of "session", "header" or "history". value of "session", "header" or "history".
4. Whether any History-Info header added for a proxy/domain 4. Whether any History-Info header added for a proxy/domain
should go outside that domain. An example being the use of should go outside that domain. An example being the use of
the History-Info header within the specific domain in which the History-Info header within the specific domain in which
it is retargeted, however, policies (for privacy, user and it is retargeted, however, policies (for privacy, user and
network security, etc.) would prohibit the exposure of that network security, etc.) would prohibit the exposure of that
information outside that domain. To accommodate such a information outside that domain. To accommodate such a
scenario, a proxy MAY insert the Privacy header with a priv- scenario, a proxy MAY insert the Privacy header with a priv-
value of "history" when the request is being forwarded within value of "history" when the request is being forwarded within
the same domain. An example of such an application is the same domain. An example of such an application is
provided in Appendix C. provided in Appendix C.
5. Whether an hi-entry is added for a specific Request URI due 5. Whether an hi-entry is added for a specific Request URI due
to local privacy policy considerations. A proxy MAY add the to local privacy policy considerations. A proxy MAY add the
Privacy header with a priv-value of "history" associated with Privacy header with a priv-value of "history" associated with
the specific hi-targeted-to-uri. the specific hi-targeted-to-uri.
An example policy would be a proxy that only adds the History-Info An example policy would be a proxy that only adds the History-Info
header if the Histinfo option tag is in the Supported header. Other header if the "histinfo" option tag is in the Supported header.
proxies may have a policy that they always add the header, but never Other proxies may have a policy that they always add the header, but
forward it outside a particular domain, accomplishing this by adding never forward it outside a particular domain, accomplishing this by
a Privacy header with a priv-value of "history" to each hi-entry to adding a Privacy header with a priv-value of "history" to each hi-
allow the information to be collected for internal retargeting only. entry to allow the information to be collected for internal
retargeting only.
Each application making use of the History-Info header SHOULD address Each application making use of the History-Info header SHOULD address
the impacts of the local policies on the specific application (e.g. the impacts of the local policies on the specific application (e.g.
what specification of local policy is optimally required for a what specification of local policy is optimally required for a
specific application and any potential limitations imposed by local specific application and any potential limitations imposed by local
policy decisions). policy decisions).
Consistent with basic SIP processing of optional headers, proxies Consistent with basic SIP processing of optional headers, proxies
SHOULD maintain the History-Info header(s), received in messages SHOULD maintain the History-Info header(s), received in messages
being forwarded, independent of whether local policy supports being forwarded, independent of whether local policy supports
History-Info. History-Info.
The specific processing by proxies for adding the History-Info The specific processing by proxies for adding the History-Info
skipping to change at page 17, line 34 skipping to change at page 17, line 32
associated with each of those requests and including the header associated with each of those requests and including the header
entries in the order indicated by the indexing. Responses are entries in the order indicated by the indexing. Responses are
processed as described in section 16.7 of [RFC3261] with the processed as described in section 16.7 of [RFC3261] with the
aggregated History-Info entries processed similar to step 7 aggregated History-Info entries processed similar to step 7
"Aggregate Authentication Header Field Values". Section 4.5 "Aggregate Authentication Header Field Values". Section 4.5
provides an example of a parallel request scenario, highlighting provides an example of a parallel request scenario, highlighting
this indexing mechanism. this indexing mechanism.
4.3.3.2 Processing History-Info in Responses 4.3.3.2 Processing History-Info in Responses
A proxy that receives a Request with the Histinfo option tag in the A proxy that receives a Request with the "histinfo" option tag in the
Supported header, and depending upon a local policy supporting the Supported header, and depending upon a local policy supporting the
capture of History-Info, SHOULD return captured History-Info in capture of History-Info, SHOULD return captured History-Info in
subsequent, provisional and final responses to the Request, subject subsequent, provisional and final responses to the Request, subject
to the following considerations for privacy: to the following considerations for privacy:
o If the response is being forwarded to a Request URI associated o If the response is being forwarded to a Request URI associated
with a domain for which the proxy is not responsible and there with a domain for which the proxy is not responsible and there
was a Privacy header, in the request received by the proxy, with was a Privacy header, in the request received by the proxy, with
a priv-value of "session", "header" or "history", the proxy MUST a priv-value of "session", "header" or "history", the proxy MUST
remove the History-Info header (i.e. all hi-entries) prior to remove the History-Info header (i.e. all hi-entries) prior to
skipping to change at page 19, line 29 skipping to change at page 19, line 27
routing of the request, but still maintaining privacy for specific routing of the request, but still maintaining privacy for specific
URIs. URIs.
Additional detailed scenarios are available in the appendix. Additional detailed scenarios are available in the appendix.
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | | | | | | | | |
|--INVITE -->| | | | | | |--INVITE -->| | | | | |
| |-INVITE->| | | | | | |-INVITE->| | | | |
Supported: Histinfo Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1, History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1 <sip:Bob@P2.example.com>; index=1.1
| | | | | | | | | | | | | |
| | |-INVITE>| | | | | | |-INVITE>| | | |
History-Info: <sip:Bob@P1.example.com>;index=1, History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1, <sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1 <sip:User2@UA2.example.com>;index=1.1.1
| | | | | | | | | | | | | |
| | |-----INVITE ---->| | | | | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1, History-Info:<sip:Bob@P1.example.com>;index=1,
skipping to change at page 20, line 41 skipping to change at page 20, line 38
| | | | | | | | | | | | | |
|--ACK --------------------------------------------------->| |--ACK --------------------------------------------------->|
4.5.1 Example with Privacy header for entire request at Proxy2 4.5.1 Example with Privacy header for entire request at Proxy2
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5 UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | | | | | | | | |
|--INVITE -->| | | | | | |--INVITE -->| | | | | |
| |-INVITE->| | | | | | |-INVITE->| | | | |
Supported: Histinfo Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1, History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1 <sip:Bob@P2.example.com>;index=1.1
| | | | | | | | | | | | | |
| | |-INVITE>| | | | | | |-INVITE>| | | |
Privacy: history Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1, History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1, <sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1 <sip:User2@UA2.example.com>;index=1.1.1
| | | | | | | | | | | | | |
| | |-----INVITE ---->| | | | | |-----INVITE ---->| | |
skipping to change at page 22, line 4 skipping to change at page 21, line 49
<sip:User3@UA3.example.com?Reason=SIP;cause=486;\ <sip:User3@UA3.example.com?Reason=SIP;cause=486;\
text="Busy Here">;index=1.2, text="Busy Here">;index=1.2,
<sip:User5@UA5.example.com>;index=1.3 <sip:User5@UA5.example.com>;index=1.3
| | | | | | | | | | | | | |
| |<-----200 OK---------------------------------| | |<-----200 OK---------------------------------|
|<--200 OK---| | | | | | |<--200 OK---| | | | | |
| | | | | | | | | | | | | |
|--ACK --------------------------------------------------->| |--ACK --------------------------------------------------->|
4.5.2 Example with Privacy header for specific URI (UA4) at Proxy2 4.5.2 Example with Privacy header for specific URI (UA4) at Proxy2
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | | | | | | | | |
|--INVITE -->| | | | | | |--INVITE -->| | | | | |
| |-INVITE->| | | | | | |-INVITE->| | | | |
Supported: Histinfo Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1, History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1 <sip:Bob@P2.example.com>; index=1.1
| | | | | | | | | | | | | |
| | |-INVITE>| | | | | | |-INVITE>| | | |
History-Info:<sip:Bob@P1.example.com>;index=1, History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1, <sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1 <sip:User2@UA2.example.com>;index=1.1.1
| | | | | | | | | | | | | |
| | |-----INVITE ---->| | | | | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1, History-Info:<sip:Bob@P1.example.com>;index=1,
skipping to change at page 24, line 10 skipping to change at page 24, line 7
application (e.g. is the information something that appears on a application (e.g. is the information something that appears on a
display or is it processed by automata which could have negative display or is it processed by automata which could have negative
impacts on the subsequent processing of a request?). It is impacts on the subsequent processing of a request?). It is
suggested that the impact of an intermediary not supporting the suggested that the impact of an intermediary not supporting the
security recommendations should be evaluated by the application security recommendations should be evaluated by the application
to ensure that the impacts have been sufficiently addressed by to ensure that the impacts have been sufficiently addressed by
the application. the application.
6. Security Considerations 6. Security Considerations
This draft provides a proposal in sections 3.2 and 4.4 for addressing The threat model and related security and privacy requirements for
the Security requirements identified in section 2.1 by mandating the the History-Info header are described in section 2.1 and 2.2 of this
use of TLS between entities and specifying appropriate behavior if document. Sections 3.2, 3.3 and 4.4 provide normative
TLS is not available for a specific connection. With TLS, History- recommendations related to security and privacy fulfilling these
Info headers are no less, nor no more, secure than other SIP headers, requirements. The use of TLS is mandated between the entities (i.e.
which generally have even more impact on the subsequent processing of UAC to Proxy, Proxy to Proxy, and Proxy to UAS) which use the
SIP sessions than the History-Info header. History-Info header. The appropriate handling of a request in the
case that TLS is not available for a specific connection is described
A more robust security solution would need to consider the aspects of in section 5.
the problem that are different than the hop by hop security problem
solved by TLS, as each hop is not required to add the History-Info
header. History-Info also introduces a slightly different problem
than the basic SIP header or Identity [SIPATHID] problems, which is
focused on securing the information in the initial request end to
end. The History-Info header is being inserted by an entity as it
targets and forwards a Request, thus the requirements for the
security solution are similar to the Via and Record-Route headers.
For the History-Info header, the general requirement is to secure a
header that is inserted by an intermediary and then subsequently
referenced, by other intermediaries to build the next header entry,
or by an end application using the information to provide a service.
Thus, the general requirement for a more robust security solution for With TLS, History-Info headers are no less, nor no more, secure than
SIP takes the form of a middle to middle and middle to end security other SIP headers, which generally have even more impact on the
solution, with the requirements addressed in a separate document subsequent processing of SIP sessions than the History-Info header.
[SIPIISEC]. The use of [SIPATHID], with a redirection back to the UAC
in the case of the request being forwarded outside the domain for
which the intermediary has authorization or a secure SIP mechanism
for adding message bodies as discussed [SIPBDADD] are two possible
alternatives. A more robust security solution SHOULD be used for
History-Info implementations once the solution has been evaluated
against the requirements identified in [SIPIISEC].
7. IANA Considerations 7. IANA Considerations
(Note to RFC Editor: Please fill in all occurrences of XXXX in this (Note to RFC Editor: Please fill in all occurrences of XXXX in this
section with the RFC number of this specification). section with the RFC number of this specification).
7.1 Registration of new SIP History-Info header 7.1 Registration of new SIP History-Info header
This document defines a new SIP header field name: History-Info and a This document defines a new SIP header field name: History-Info and a
new option tag: Histinfo. new option tag: histinfo.
The following changes should be made to The following changes should be made to
http:///www.iana.org/assignments/sip-parameters http:///www.iana.org/assignments/sip-parameters
The following row should be added to the header field section: The following row should be added to the header field section:
Header Name Compact Form Reference Header Name Compact Form Reference
----------- ------------ --------- ----------- ------------ ---------
History-Info none [RFCXXXX] History-Info none [RFCXXXX]
The following should be added to the Options Tags section: The following should be added to the Options Tags section:
Name Description Reference Name Description Reference
---- ----------- --------- ---- ----------- ---------
Histinfo When used with the Supported header, [RFCXXXX] histinfo When used with the Supported header, [RFCXXXX]
this option tag indicates support this option tag indicates support
for the History Information to be for the History Information to be
captured for requests and returned in captured for requests and returned in
subsequent responses. This tag is not subsequent responses. This tag is not
used in a Proxy-Require or Require used in a Proxy-Require or Require
header field since support of header field since support of
History-Info is optional. History-Info is optional.
7.2 Registration of "history" for SIP Privacy header 7.2 Registration of "history" for SIP Privacy header
skipping to change at page 26, line 14 skipping to change at page 25, line 38
[RFC3323] J. Peterson, "A Privacy Mechanism for the Session [RFC3323] J. Peterson, "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November, 2002. Initiation Protocol (SIP)", RFC 3323, November, 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
Informational References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[SIPIISEC] M. Barnes, "A Mechanism to Secure SIP Headers Inserted by Informational References
Intermediaries", draft-barnes-sipping-inserted-info-02.txt, October,
2004.
[SIPSVCEX] A. Johnson, "SIP Service Examples", draft-ietf-sipping- [SIPSVCEX] A. Johnson, "SIP Service Examples", draft-ietf-sipping-
service-examples-07.txt, July, 2004. service-examples-07.txt, July, 2004.
[SIPATHID] J. Peterson, "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-
identity-03.txt, September, 2004.
[SIPBDADD] R. Mahy, "SIP Body Addition", draft-mahy-sipping-body-add-
00.txt, July, 2004.
[RFC3665] A. Johnson et al, "SIP Basic Call Flow Examples", RFC 3665, [RFC3665] A. Johnson et al, "SIP Basic Call Flow Examples", RFC 3665,
BCP 75, December, 2003. BCP 75, December, 2003.
Acknowledgements Acknowledgements
The editor would like to acknowledge the constructive feedback The editor would like to acknowledge the constructive feedback
provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell,
Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng,
Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger, Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger,
Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost and Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost and
Sebastien Garcin. Sebastien Garcin.
The editor would like to acknowledge the significant input from The editor would like to acknowledge the significant input from
Rohan Mahy on some of the normative aspects of the ABNF, particularly Rohan Mahy on some of the normative aspects of the ABNF, particularly
around the need for and format of the index and around the enhanced around the need for and format of the index and around the security
SIP security aspects enabled by this draft. aspects.
Contributors' Addresses Contributors' Addresses
Cullen, Mark and Jon contributed to the development of the initial Cullen, Mark and Jon contributed to the development of the initial
requirements. requirements.
Cullen and Mark provided substantial input in the form of email Cullen and Mark provided substantial input in the form of email
discussion in the development of the initial version of the discussion in the development of the initial version of the
individual solution document. individual solution document.
skipping to change at page 28, line 29 skipping to change at page 27, line 45
to UA1, the end user or an application at UA1 could make a decision to UA1, the end user or an application at UA1 could make a decision
on how best to attempt finding "Bob". Without this mechanism UA1 on how best to attempt finding "Bob". Without this mechanism UA1
might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a
third manual attempt at reaching "Bob". With this mechanism, either third manual attempt at reaching "Bob". With this mechanism, either
the end user or application could know that "Bob" is busy on his home the end user or application could know that "Bob" is busy on his home
phone and is physically not in the office. If there were an phone and is physically not in the office. If there were an
alternative address for "Bob" known to this end user or application, alternative address for "Bob" known to this end user or application,
that hasn't been attempted, then either the application or the end that hasn't been attempted, then either the application or the end
user could attempt that. The intent here is to highlight an example user could attempt that. The intent here is to highlight an example
of the flexibility of this mechanism that enables applications well of the flexibility of this mechanism that enables applications well
beyond SIP as it is certainly well beyond the scope of this draft to beyond SIP as it is certainly well beyond the scope of this document
prescribe detailed applications. to prescribe detailed applications.
UA1 Proxy1 UA2 UA3 UA4 UA1 Proxy1 UA2 UA3 UA4
| | | | | | | | | |
|-INVITE F1->| | | | |-INVITE F1->| | | |
| | | | | | | | | |
| |--INVITE F2------>| | | | |--INVITE F2------>| | |
|<--100 F3---| | | | |<--100 F3---| | | |
| |<-302 F4----------| | | | |<-302 F4----------| | |
| | | | | | | | | |
| |-------INVITE F5 --------->| | | |-------INVITE F5 --------->| |
skipping to change at page 39, line 15 skipping to change at page 38, line 37
As with the other examples, this is not prescriptive of how one would As with the other examples, this is not prescriptive of how one would
do this type of service but an example of a subset of processing that do this type of service but an example of a subset of processing that
might be associated with such a service. In addition, this example might be associated with such a service. In addition, this example
is not addressing any aspects of Agent availability, which might also is not addressing any aspects of Agent availability, which might also
be done via a SIP interface. be done via a SIP interface.
UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2 UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
| | | | | | | | | |
|--INVITE F1-->| | | | |--INVITE F1-->| | | |
Supported:Histinfo Supported:histinfo
| | | | | | | | | |
| |--INVITE F2-->| | | | |--INVITE F2-->| | |
Supported:Histinfo Supported:histinfo
History-Info: <sip:Gold@example.com>; index=1 History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1 History-Info: <sip:ACDGRP1@example.com>; index=1.1
| | | | | | | | | |
| |<-302 F3------| | | | |<-302 F3------| | |
Contact: <sip:ACDGRP2@ACD.com> Contact: <sip:ACDGRP2@ACD.com>
| | | | | | | | | |
| |--------INVITE F4---------->| | | |--------INVITE F4---------->| |
History-Info: <sip:Gold@example.com>; index=1 History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1 History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2 History-Info: <sip:ACDGRP2@example.com>; index=1.2
skipping to change at page 42, line 4 skipping to change at page 41, line 26
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.1 ;received=192.0.2.1
Max-Forwards: 69 Max-Forwards: 69
Record-Route: <sip:ss3.chicago.example.com;lr> Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com> To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\ History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1, text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2, <sip:bob@chicago.example.com>; index=2,
<sip:bob@client.chicago.example.com>; index=2.1 <sip:bob@client.chicago.example.com>; index=2.1
Contact: <sip:alice@client.atlanta.example.com;transport=tcp> Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0 Content-Length: 0
Detailed Call Flow continues per section 6.3 in [RFC 3665]. Detailed Call Flow continues per section 6.3 in [RFC 3665].
Appendix E. Changelog Appendix E. Changelog
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from the 05 to 06 version:
o General changes to tidy document:
o Change the term "this draft" to "this document".
o Spell out first use of acronyms (ex: UA, UAC, UAS, URI,
URL, TLS)
o Change Histinfo to "histinfo"
o Abstract: delete last 2 sentences in Abstract
o Overview:
o Insert paragraph break just before "This draft defined a new
SIP header..."
o 2nd to last paragraph of Overview, delete all but first
sentence." (the other stuff on where examples would be
further documented isn't really relevant to what this draft
does and had been there for purposes of WG discussion
during development of document).
o Background: Put "retarget" in single quotes when the term is
introduced in the second sentence (consistent with reference in
section 3.
o Section 3, 2nd para, add SUBSCRIBE and PUBLISH as appropriate
methods (consistent with section 4.1)
o Section 3.2: Changed "RECOMMENDs the use of TLS" to "strongly
RECOMMENDS the use of TLS".
o Section 4.1, Privacy bullet item, clarified the first reference
of "History-Info header" as "History-Info header field values".
o Section 4.2:
oFor clarity in the examples, removed the text phrases escaped
into the URI.
oChange capitalized "Cause" to LC "cause".
o Section 6 (Security): deleted the last two paragraphs (on AIB,
Body additions, Security of Inserted Info since those are not
relevant to the security solution required for History-Info),
and restated what security mechanisms are mandatory to
implement, including references to the sections of the document
dealing with those mechanisms.
o References: Updated references: Added TLS and removed body-add,
AIB, and sec-inserted.
Changes from the 04 to 05 version: Changes from the 04 to 05 version:
o Section 3, 3rd paragraph: Clarified that the Proxy does not o Section 3, 3rd paragraph: Clarified that the Proxy does not
create the requests, but rather forwards. (SP - individual email create the requests, but rather forwards. (SP - individual email
Nov. 18) Nov. 18)
o Section 4.3.1: o Section 4.3.1:
- 2nd paragraph: Added text for handling the reason, referring - 2nd paragraph: Added text for handling the reason, referring
to section 4.3.3.1.2 for details(JRE-individual email Nov. to section 4.3.3.1.2 for details(JRE-individual email Nov.
15) 15)
skipping to change at page 43, line 18 skipping to change at page 43, line 39
section. (EB) section. (EB)
o Changed square brackets on references to requirements to o Changed square brackets on references to requirements to
parenthesis so they wouldn't appear to be external parenthesis so they wouldn't appear to be external
references. (EB) references. (EB)
o Moved the updates to table 2 in section 4.1, so that it o Moved the updates to table 2 in section 4.1, so that it
appears right after the paragraph discussing in which appears right after the paragraph discussing in which
messages the header can appear. (RM) messages the header can appear. (RM)
o Section 3.2: o Section 3.2:
o Moved discussion of new security solution proposals per o Moved discussion of new security solution proposals per
updated identity draft and rohan's body addition to section updated identity draft and rohan's body addition to section
6 as they're not relevant to the solution in this draft 6 as they're not relevant to the solution in this document
(per (JRE-1)). (per (JRE-1)).
o Per IETF-60 discussion and Rohan's input, added a statement o Per IETF-60 discussion and Rohan's input, added a statement
that if TLS isn't available on the connection over which that if TLS isn't available on the connection over which
the History-info is being forwarded, either a redirection the History-info is being forwarded, either a redirection
(per identity draft) is required or the History-info is not (per identity document) is required or the History-info is
forwarded. not forwarded.
o Section 3.3: o Section 3.3:
o 2nd paragraph: adding clarification text "In the latter o 2nd paragraph: adding clarification text "In the latter
case,.." to the last sentence. (JRE-2) case,.." to the last sentence. (JRE-2)
o Last paragraph: Clarified in the last sentence that if there o Last paragraph: Clarified in the last sentence that if there
is no impact on the application due to privacy is no impact on the application due to privacy
considerations, why that is so MUST also be explained by considerations, why that is so MUST also be explained by
that application. (EB) that application. (EB)
o Section 4.1: o Section 4.1:
o Added SUBSCRIBE and PUBLISH to the list of messages in which o Added SUBSCRIBE and PUBLISH to the list of messages in which
History-Info header may appear. (JRE-3/10) History-Info header may appear. (JRE-3/10)
skipping to change at page 45, line 4 skipping to change at page 45, line 28
o Section 5: o Section 5:
o Changed the "should" to a "MUST" in the 1st application o Changed the "should" to a "MUST" in the 1st application
consideration in terms of the requirement to define default consideration in terms of the requirement to define default
behavior should the information not be available, due to behavior should the information not be available, due to
History-Info being an optional header. (EB) History-Info being an optional header. (EB)
o Updated the 5th consideration for security to reflect the o Updated the 5th consideration for security to reflect the
lack of information due to potential TLS inavailability for lack of information due to potential TLS inavailability for
a connection, thus the potential for no History-Info header a connection, thus the potential for no History-Info header
(per Rohan's comment). (per Rohan's comment).
oSection 6: oSection 6:
o Updated security considerations per TLS issue (Rohan) and to o Updated security considerations per TLS issue (Rohan) and to
reference the new security solution proposals. reference the new security solution proposals.
o Added discussion of new security solution proposals per o Added discussion of new security solution proposals per
updated identity draft and rohan's body addition. updated identity document and rohan's body addition.
oAppendix: oAppendix:
o Added overview clarifying that flows are informational and o Added overview clarifying that flows are informational and
not normative. not normative.
o Changed domains to appropriate example.com and example.net o Changed domains to appropriate example.com and example.net
ones. ones.
o A.1 Added message details o A.1 Added message details
o A.2 Removed as this is redundant since this example is what o A.2 Removed as this is redundant since this example is what
is now in section 4.2. is now in section 4.2.
Changes from the 02 to the 03 version: Changes from the 02 to the 03 version:
skipping to change at page 47, line 30 skipping to change at page 48, line 4
Added section 2.3.4 to address Redirect Server behavior. Added section 2.3.4 to address Redirect Server behavior.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; neither does it represent rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights. that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in Information on the IETF's procedures with respect to rights in
IETF Documents can be found in BCP 78 and 79. IETF Documents can be found in BCP 78 and 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required proprietary rights which may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr.org. IETF at ietf-ipr.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 59 change blocks. 
165 lines changed or deleted 178 lines changed or added

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