SIPPING Working Group                                      J. van Elburg
Internet-Draft                            Ericsson Telecommunicatie B.V.
Expires: March 23, 2008                               September 20, 2007


   The Session Initiation Protocol (SIP) P-Served-User Private-Header
                               (P-Header)
               draft-vanelburg-sipping-served-user-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 23, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies the SIP P-Served-User P-header.  This header
   field addresses an issue that was found in the 3rd-Generation
   Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an
   S-CSCF (Serving Call Session Control Function) and an AS (Application
   Server) on the ISC (IMS Subsystem Service Control) interface to
   convey the identity of the served user and the session case that
   applies to this particular communication session and application
   invocation.



van Elburg               Expires March 23, 2008                 [Page 1]


Internet-Draft         The P-Served-User P-Header         September 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2.  Diversion; continue on terminating leg, but finish
           subsequent terminating iFC first . . . . . . . . . . . . .  4
     3.3.  Diversion; create new originating leg and provide
           originating  iFC processing  . . . . . . . . . . . . . . .  6
     3.4.  Call out of the blue; on behalf of user B, but service
           profile of service identity C  . . . . . . . . . . . . . .  7
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  P-Served-User header field Definition  . . . . . . . . . . . .  8
   6.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Why te History Info header is not suitable to
                convey the served user information on the ISC
                interface . . . . . . . . . . . . . . . . . . . . . . 11
     A.1.  Semantics  . . . . . . . . . . . . . . . . . . . . . . . . 11
     A.2.  Additional Observations  . . . . . . . . . . . . . . . . . 12
     A.3.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12
   Appendix B.  Revision Information  . . . . . . . . . . . . . . . . 12
     B.1.  version 00 . . . . . . . . . . . . . . . . . . . . . . . . 12
     B.2.  version 01 . . . . . . . . . . . . . . . . . . . . . . . . 12
     B.3.  version 02 . . . . . . . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14


















van Elburg               Expires March 23, 2008                 [Page 2]


Internet-Draft         The P-Served-User P-Header         September 2007


1.  Introduction

   The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia
   Subsystem) uses SIP (RFC3261 [2]) as its main signalling protocol.
   (For more information on the IMS, a detailed description can be found
   in 3GPP TS 23.228 [8] and 3GPP TS 24.229 [10].) 3GPP has identified a
   set of requirements that can be met, according to the procedures in
   RFC 3427 [5], by defining a new SIP P-header.

   The remainder of this document is organized as follows.  Section 3
   outlines the problem using particular service scenarios and Section 4
   discusses the requirements derived from these scenarios.  Section 5
   defines the P-Served-User header field, which meets those
   requirements, and Section 6 discusses the applicability and scope of
   this new header field.  Section 7 registers the P-Served-User header
   field with the IANA and Section 8 discusses the security properties
   of the environment where this header field is intended to be used.


2.  Definitions

   The terms Identity, Network Asserted Identity and Trust Domain in
   this document are specified in RFC3324 [3].


3.  Scenarios

3.1.  General

   In the 3GPP IMS the S-CSCF (Serving CSCF) is a SIP proxy that serves
   as a registrar and handles originating and terminating session states
   for users allocated to it.  This means that any call that is
   originated by a specific user or any call that is terminated to that
   specific user will pass through an S-CSCF that is allocated to that
   user.

   At the moment that an S-CSCF is allocated for a specific user, a user
   profile is downloaded to the S-CSCF from the HSS (Home Subscriber
   Server) over the Cx interface.  This user profile tells the S-CSCF
   whether the user is allowed to originate or terminate calls or
   important for this particular document whether an AS needs to be
   linked in over the ISC interface.  The user profile information that
   determines whether particular initial request need to be sent to a
   particular AS is called initial Filter Criteria (iFC), see for
   example 3GPP TS 23.218 [7].

   To be able for an S-CSCF to perform its responsibilities it needs to
   determine on which users behalf it is performing its tasks and which



van Elburg               Expires March 23, 2008                 [Page 3]


Internet-Draft         The P-Served-User P-Header         September 2007


   session case is applicable for the particular request.  (For session
   case see 3GPP TS 29.228 [11]) The session case distinguishes the
   originating and terminating call cases and whether the particular
   user is registered or not.

   When the S-CSCF determines that for an incoming initial request the
   originating call case applies, it determines the served user by
   looking at the P-Asserted-Identity header field ( RFC 3325 [4]) which
   carries the network asserted identity of the originating user.  When
   after processing the iFC for this initial request the S-CSCF decides
   to forward the request to an AS, the AS has to go through a similar
   process of determining the session case and the served user.  Since
   it should come to the same conclusion that this is an originating
   session case it has to look at the P-Asserted-Identy header field as
   well to determine the served user.

   When the S-CSCF determines that for an incoming initial request the
   terminating call case applies, it determines the served user by
   looking at the Request-URI ( RFC 3261 [2]) which carries the identity
   of the intended terminating user.  When after processing the iFC for
   this initial request the S-CSCF decides to forward the request to an
   AS, the AS has to go through a similar process of determining the
   session case and the served user.  Since it should come to the same
   conclusion that this is a terminating session case it has to look at
   the Request-URI as well to determine the served user.

   In the originating case it can be observed that while the P-Asserted-
   Identity header field just represents the originating user when it
   enters the S-CSCF, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In the terminating case a similar overloading happens to the Request-
   URI, while it first only represented the identity of the intended
   terminating user, it is overloaded with another meaning when it is
   sent to an AS over the ISC interface.  This other meaning is that it
   serves as a representation of the served user.

   In basic call scenarios this does not show up as a problem, but once
   more complicated service scenarios (notably forwarding services)
   needs to be realised it poses severe limitations.  Such scenarios are
   brought forward in the following sub sections.

3.2.  Diversion; continue on terminating leg, but finish subsequent
      terminating iFC first

   Imagine a service scenario where a user B has a terminating service
   that diverts the call to a different destination, but it is required



van Elburg               Expires March 23, 2008                 [Page 4]


Internet-Draft         The P-Served-User P-Header         September 2007


   that subsequent terminating services for the same user are still
   executed.  This means that this particular user has multiple iFC
   configured that are applicable for an incoming initial request.  When
   the S-CSCF receives an initial INVITE request it analyses the request
   and determines that the session case is for a terminating registered
   user, then it determines the served user to be user B by looking at
   the Request-URI.

   Now the S-CSCF starts the iFC processing, the first iFC that matches
   the INVITE request causes the INVITE to be forwarded over the ISC
   interface to an AS that hosts user B's diversion service, by adding
   the AS and S-CSCF's own hostnames to the Route header.  The S-CSCF
   adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname
   on the Route header, this allows the S-CSCF to correlate an INVITE
   coming from an AS over the ISC interface to the existing session that
   forwarded the INVITE to the AS in the first place.

   When the AS receives the initial INVITE request it analyses the
   request and determines that the session case is for a terminating
   registered user, then it determines the served user to be user B by
   looking at the Request-URI.  Based on some criteria the diversion
   service concludes that the request needs to be diverted to another
   user or application C. It does this by changing the Request-URI to C.
   Optionally it records the Request-URI history by using the History-
   Info header field (RFC4244 [6]).  Then the AS removes itself from the
   Route header and routes the INVITE request back to the S-CSCF by
   using the topmost Route header field.

   When the S-CSCF receives the INVITE over the ISC interface it can see
   that the Route header contains its own hostname and an ODI that
   correlates to an existing terminating session for user B. This can be
   used by the S-CSCF to analyze whether there are still unexecuted iFC.
   (Note that the current behaviour of the S-CSCF on receiving an INVITE
   with a changed Request-URI is to terminate the iFC processing and to
   route the request based on the new Request-URI value.)

   The process repeats itself, the INVITE is forwarded to the AS that is
   associated with this particular iFC.  When the AS receives the
   initial INVITE request it analyses the request and determines that
   the session case is for a terminating registered user, then it
   determines the served user to be user C by looking at the Request-
   URI.  This is clearly wrong as the user being served is still user B.

   This scenario clearly shows the problem that occurs when the Request-
   URI is overloaded with the meanings "intended target identity" and
   "served user" with the operation as described in chapter Section 3.1.
   And it shows that this use case can not be realised without
   introducing a mechanism that conveys information about the served



van Elburg               Expires March 23, 2008                 [Page 5]


Internet-Draft         The P-Served-User P-Header         September 2007


   user from the S-CSCF to the AS.  Use of the History-Info element does
   not solve this problem as it does not tell the AS which user is being
   served, but just presents a history of diversions that might not be
   even caused by the systems serving this particular user.  A more
   detailed analysis on why the History-Info header field can't be used
   is provided in Appendix A.

3.3.  Diversion; create new originating leg and provide originating  iFC
      processing

   Imagine a service scenario where a user B has a terminating service
   that diverts the call to a different destination, it is required that
   forwarded call leg is handled as an originating call leg and that
   originating services for user B are executed.  This means that this
   particular user has one or more iFC configured that are applicable
   for an outgoing initial request.

   When the S-CSCF receives an initial INVITE request it analyses the
   request and determines that the session case is for a terminating
   registered user, then it determines the served user to be user B by
   looking at the Request-URI.

   Now the S-CSCF starts the iFC processing, the first iFC that matches
   the INVITE request causes the INVITE to be forwarded over the ISC
   interface to an AS that hosts user B's diversion service, by adding
   the AS and S-CSCF's own hostnames to the Route header.  The S-CSCF
   adds an Original Dialog Identifier (ODI) to the S-CSCF's own hostname
   on the Route header, this allows the S-CSCF to correlate an INVITE
   coming from an AS over the ISC interface to the existing session that
   forwarded the INVITE to the AS in the first place.

   When the AS receives the initial INVITE request it analyses the
   request and determines that the session case is for a terminating
   registered user, then it determines the served user to be user B by
   looking at the Request-URI.  Based on some criteria the diversion
   service concludes that the request needs to be diverted to another
   user or application C. It does this by changing the Request-URI to C.
   Optionally it records the Request-URI history by using the History-
   Info header field (RFC4244 [6]).  Then the AS removes itself from the
   Route header.  To make sure that the request is handled as a new
   originating call on behalf of user B, the AS adds the "orig"
   parameter to the topmost route header.  Then it routes the INVITE
   request back to the S-CSCF by using this topmost Route header field.

   When the S-CSCF receives the INVITE over the ISC interface it can see
   that the topmost Route header contains its own hostname and an "orig"
   parameter.  Because the topmost Route header contains the "orig"
   parameter the S-CSCF concludes that the INVITE should be handled as



van Elburg               Expires March 23, 2008                 [Page 6]


Internet-Draft         The P-Served-User P-Header         September 2007


   if a call is originated by the served user.  The served user is
   determined from the P-Asserted-Identity header to be user A. This is
   clearly wrong as the user being served is and should be user B.

   For the sake of discussion lets assume that the S-CSCF can determine
   that the served user is user B. Then the procedure would continue as
   follows: The S-CSCF starts the originating iFC processing, the first
   iFC that matches the INVITE request causes the INVITE to be forwarded
   over the ISC interface to an AS that hosts an originating service of
   user B, by adding the AS and S-CSCF's own hostnames to the Route
   header.  The S-CSCF adds an Original Dialog Identifier (ODI) to the
   S-CSCF's own hostname on the Route header.

   The INVITE is forwarded to the AS that is associated with this
   particular iFC.  When the AS receives the initial INVITE request it
   analyses the request and determines that the session case is for an
   originating registered user, then it determines the served user to be
   user A by looking at the P-Asserted-Identity.  This is clearly wrong
   as the user being served is and should be user B.

   This scenario clearly shows the problem that occurs when the
   P-Asserted-Identity is overloaded with the meanings "call originator"
   and "served user" with the operation as described in chapter
   Section 3.1.  And it shows that this use case can not be realised
   without introducing a mechanism that conveys information about the
   served user from the S-CSCF to the AS and from the AS to the S-CSCF.
   Use of the History-Info element does not solve this problem as it
   does not tell the AS which user is being served, but just presents a
   history of diversions that might not be even caused by the systems
   serving this particular user.  A more detailed analysis on why the
   History-Info header field can't be used is provided in Appendix A.

3.4.  Call out of the blue; on behalf of user B, but service profile of
      service identity C

   There are services that need to be able to initiate a call, whereby
   the call appears to be coming from a user B, but service profile on
   behalf of service identity C needs to be executed in the S-CSCF.

   When a call needs to appear as coming from user B, that means that
   the P-Asserted-Identity needs to contain B's identity.  This is
   because the Originating Identity Presentation (OIP) service as
   defined in 3GPP 24.173 [9] uses the P-Asserted-Identity to present
   the call originator.  Which makes sense because that is the main
   meaning expressed by the P-Asserted-Identity header field.

   It is clear that no INVITE request can be constructed currently that
   would achieve both requirements expressed in the first paragraph,



van Elburg               Expires March 23, 2008                 [Page 7]


Internet-Draft         The P-Served-User P-Header         September 2007


   because the P-Asserted-Identity is overloaded with two meanings on
   the ISC interface, when the S-CSCF will receive this request it will
   determine that the served user is user B, which was not what we
   wanted to achieve.


4.  Requirements

   This section lists the requirements derived from the previous
   scenarios:

   1.  To be able to offer real world application services it is
       required that the identity of the served user can be conveyed on
       the ISC interface (see 3GPP 23.218 [7]).
   2.  To be able to offer appropriate services to the served user it is
       required that in addition to the served user identity the session
       case is conveyed.


5.  P-Served-User header field Definition

   This document defines the SIP P-Served-User P-header.  This header
   field can be added to initial requests routed from an S-CSCF to an AS
   or from an AS to an S-CSCF.  The P-Served-User P-header contains the
   IMS Public User Identity of the user that is served by the S-CSCF and
   on whose behalf an application is invoked.  The sessioncase parameter
   may be used to convey whether the initial request is originated by or
   destined for the served user.  The registration state parameter may
   be used by the S-CSCF towards an AS to indicate whether the initial
   request is for a registered or an unregistered user.

   The augmented Backus-Naur Form (BNF) (RFC2234 [1]) syntax of the
   P-Served-User header field is the following:


   P-Served-User            = "P-Served-User" HCOLON PServedUser-value
                                              *(SEMI served-user-param)
   served-user-param        = sessioncase-param
                              / registration-state-param
                              / generic-param
   PServedUser-value        = name-addr / addr-spec
   sessioncase-param        = "sescase" EQUAL "orig" / "term"
   registration-state-param = "regstate" EQUAL "unreg" / "reg"

   EQUAL, HCOLON, SEMI, name-addr, addr-spec and generic-param are
   defined in RFC3261 [2].

   The following is an example of a P-Served-User header field:



van Elburg               Expires March 23, 2008                 [Page 8]


Internet-Draft         The P-Served-User P-Header         September 2007


   P-Served-User: <sip:captain@buzz.com>; sescase=orig; regstate=reg


6.  Applicability

   According to RFC 3427 [5], P-headers have a limited applicability.
   Specifications of P-headers such as this RFC need to clearly document
   the useful scope of the proposal, and explain its limitations and why
   it is not suitable for the general use of SIP on the Internet.

   The P-Served-User header field is intended to be used in 3GPP IMS
   networks.  This header field carries the identity of the served user
   from an S-CSCF to an IMS application server, which is referred to as
   AS.  Or from an AS to an S-CSCF.  The S-CSCF or the AS inserts the
   P-Served-User header field into a SIP request and the S-CSCF removes
   it before routing the request further.

   When SIP is used on the Internet, there are typically no proxies
   involving an application server over an ISC interface.  Consequently,
   the P-Served-User header field does not seem useful in a general
   Internet environment.


7.  IANA Considerations

   This document defines a new SIP header field: P-Served-User.  This
   header field needs to be registered by the IANA in the SIP Parameters
   registry under the Header Fields subregistry.


8.  Security Considerations

   The P-Served-User defined in this document is to be used in an
   environment where elements are trusted and where attackers are not
   supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physically protecting the
   network.  In any case, the environment where the P-Served-User header
   field will be used ensures the integrity and the confidentiality of
   the contents of this header field.

   There is a security risk if a P-Served-User header field is allowed
   to propagate out of the trust domain where it was generated.  In that
   case user-sensitive information would be revealed by such a breach.
   To prevent such a breach from happening: Proxies MUST NOT insert the
   header when forwarding requests to a next hop located outside the
   trust domain.  When forwarding the request to a trust node, proxies
   MUST NOT insert the header unless they have sufficient knowledge that



van Elburg               Expires March 23, 2008                 [Page 9]


Internet-Draft         The P-Served-User P-Header         September 2007


   the route set includes another proxy in the trust domain that
   understands the header, such as the own proxy.  There is no automatic
   mechanism to learn the support for this specification.  Proxies MUST
   remove the header when forwarding requests to untrusted nodes or when
   the proxy does not have knowledge of any other proxy in the route set
   that is able to understand the header.


9.  Acknowledgements

   Alf Heidermark, Hubert Przybysz and Erik Rolin for the discussion
   that led to the solution written down in this document.  Gonzalo
   Camarillo, Paul Kyzivat, Nils Haenstroem, Arunachalam Venkatraman,
   Mikael Forsberg, Miguel Garcia, Jozsef Varga and Keith Drage for
   providing improvements.


10.  References

10.1.  Normative References

   [1]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [3]   Watson, M., "Short Term Requirements for Network Asserted
         Identity", RFC 3324, November 2002.

   [4]   Jennings, C., Peterson, J., and M. Watson, "Private Extensions
         to the Session Initiation Protocol (SIP) for Asserted Identity
         within Trusted Networks", RFC 3325, November 2002.

   [5]   Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
         Rosen, "Change Process for the Session Initiation Protocol
         (SIP)", BCP 67, RFC 3427, December 2002.

10.2.  Informative References

   [6]   Barnes, M., "An Extension to the Session Initiation Protocol
         (SIP) for Request History Information", RFC 4244,
         November 2005.

   [7]   3GPP, "IP Multimedia (IM) session handling; IM call model;
         Stage 2", 3GPP TS 23.218 5.9.0, June 2006.




van Elburg               Expires March 23, 2008                [Page 10]


Internet-Draft         The P-Served-User P-Header         September 2007


   [8]   3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228
         5.15.0, June 2006.

   [9]   3GPP, "IMS Multimedia telephony service and supplementary
         services; Stage 3", 3GPP TS 24.173 7.1.0, June 2007.

   [10]  3GPP, "Internet Protocol (IP) multimedia call control protocol
         based on Session Initiation Protocol (SIP) and Session
         Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.19.0,
         June 2007.

   [11]  3GPP, "IP Multimedia (IM) Subsystem Cx and Dx Interfaces;
         Signalling flows and message contents", 3GPP TS 29.228 5.19.0,
         July 2007.


Appendix A.  Why te History Info header is not suitable to convey the
             served user information on the ISC interface

A.1.  Semantics

   The History-Info as specified in (RFC4244 [6]) holds a record of
   Request-URI's that are put on an initial request during its
   processing in the network and then particularly when the request is
   retargeted or forwarded.

   If it would be possible at all to use the History-Info header for the
   purpose of communicating the served user, then again the same
   overloading would occur as the one that we are trying to get rid of
   (Section 3.2).  Because in that case we overload the particular
   History-Info header field's hi-entry with the meaning "historic
   target identity" and "served user".

   Another reason that the History-Info header can not solve the
   requirements as expressed in this draft is that in originating
   session case scenarios the served user is currently determined from
   the P-Asserted-Identity as that one contains the asserted originating
   users identity.  The History-Info header being a record of Request-
   URI's can never be a solution for this case.

   Looking at the call out of the blue scenario (Section 3.4) it is
   impossible to construct a History-Info header for an INVITE request
   on behalf of user C appearing to come from user B and targeting user
   D that would express the served user C without violating the original
   semantics of the History-Info header according to (RFC4244 [6]).






van Elburg               Expires March 23, 2008                [Page 11]


Internet-Draft         The P-Served-User P-Header         September 2007


A.2.  Additional Observations

   The purpose of the History-Info header is a header that has an end to
   end application, for the purpose of informing an AS on the ISC
   interface this is overkill.

   At the moment that the AS receives an initial INVITE over the ISC
   interface, this INVITE may have passed a vast number of proxies that
   may either have added history information or not.  On top of that the
   request may have traversed several AS for the same served user in
   case several subsequent iFC are active all these AS may perform a
   forwarding.  This means that it is not possible to define an
   algorithm that points out which hi-entry of a History-Info header
   should represent the served user.  In other words a History-Info
   header field with n entries expressing a branch of depth n; any or
   none of these elements could be the served user identity.

   The History-Info header does not comply with the second requirement
   as expressed in Section 4, as it does not have a means to express the
   session case in a natural way.

A.3.  Conclusion

   All of the observations in the previous sub clauses in isolation are
   enough to disregard the History-Info header as an information element
   that is suitable for transporting the served user information over
   the ISC interface.

   Note that this does not prohibit the use of the P-Served-User header
   and the History-Info header in the same request, in fact that will be
   a quite likely scenario for network based diversion services like for
   example the Communication Diversion service as specified in (3GPP
   24.173 [9]).


Appendix B.  Revision Information

B.1.  version 00
   1.  2007-04-16, Initial version

B.2.  version 01
   1.  2007-04-17, Updated the parameter syntax to be less strict on
       ordering; comment from Paul Kyzivat.
   2.  2007-04-19, Added a note to section Section 3.2 regarding the
       processing of an INVITE with a changed Request-URI; comment from
       Arunachalam Venkatraman





van Elburg               Expires March 23, 2008                [Page 12]


Internet-Draft         The P-Served-User P-Header         September 2007


   3.  2007-04-24, Added SEMI to the list of tokens taken from RFC3261
       [2]; comment from Mikael Forsberg

B.3.  version 02
   1.  2007-08-06, Update last paragraph in security section; on
       suggestions provided by Miguel Garcia.
   2.  2007-09-19, Remove the last sentence in the 4th paragraph in
       section Section 3.2 that suggests that the presence of the
       P-Served-User header is used to decide whether iFC processing
       should continue or not; on suggestions provided by Miguel Garcia.
   3.  2007-09-19, Change the text in Section 3.3 to not imply that the
       ODI and the orig paramater can be used together.; on a comment
       from Jozsef Varga
   4.  2007-09-19, Remove the mention of charging in Section 3.4 as
       other mechanisms may be more appropriate for that.; on a comment
       from Keith Drage


Author's Address

   Hans Erik van Elburg
   Ericsson Telecommunicatie B.V.
   Ericssonstraat 2
   Rijen  5121 ML
   The Netherlands

   Email: HansErik (dot) van (dot) Elburg (at) ericsson (dot) com
























van Elburg               Expires March 23, 2008                [Page 13]


Internet-Draft         The P-Served-User P-Header         September 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





van Elburg               Expires March 23, 2008                [Page 14]