doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc3891.txt b/doc/rfc/rfc3891.txt
new file mode 100644
index 0000000..03a5974
--- /dev/null
+++ b/doc/rfc/rfc3891.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                            R. Mahy
+Request for Comments: 3891                           Cisco Systems, Inc.
+Category: Standards Track                                       B. Biggs
+                                                                 R. Dean
+                                                          September 2004
+
+
+        The Session Initiation Protocol (SIP) "Replaces" Header
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines a new header for use with Session Initiation
+   Protocol (SIP) multi-party applications and call control.  The
+   Replaces header is used to logically replace an existing SIP dialog
+   with a new SIP dialog.  This primitive can be used to enable a
+   variety of features, for example: "Attended Transfer" and "Call
+   Pickup".  Note that the definition of these example features is non-
+   normative.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 1]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+Table of Contents
+
+   1.  Overview. . . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  User Agent Server Behavior: Receiving a Replaces Header . . .   4
+   4.  User Agent Client Behavior: Sending a Replaces Header . . . .   6
+   5.  Proxy Behavior. . . . . . . . . . . . . . . . . . . . . . . .   7
+   6.  Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+       6.1.  The Replaces Header . . . . . . . . . . . . . . . . . .   7
+       6.2.  New Option Tag for Require and Supported Headers. . . .   8
+   7.  Usage Examples. . . . . . . . . . . . . . . . . . . . . . . .   9
+       7.1.  Replacing an Early Dialog at the Originator . . . . . .   9
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+       9.1.  Registration of "Replaces" SIP Header . . . . . . . . .  13
+       9.2.  Registration of "replaces" SIP Option-tag . . . . . . .  13
+   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
+   11. References. . . . . . . . . . . . . . . . . . . . . . . . . .  13
+       11.1. Normative References. . . . . . . . . . . . . . . . . .  13
+       11.2. Informative References. . . . . . . . . . . . . . . . .  14
+   12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  15
+   13. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  16
+
+1.  Overview
+
+   This document describes a SIP [1] extension header field as part of
+   the SIP multiparty applications architecture framework [10].  The
+   Replaces header is used to logically replace an existing SIP dialog
+   with a new SIP dialog.  This is especially useful in peer-to-peer
+   call control environments.
+
+   One use of the "Replaces" header is to replace one participant with
+   another in a multimedia conversation.  While this functionality is
+   already available using 3rd party call control [11] style call
+   control, the 3pcc model requires a central point of control which may
+   not be desirable in many environments.  As such, a method of
+   performing these same call control primitives in a distributed,
+   peer-to-peer fashion is very desirable.
+
+   Use of a new INVITE with a new header for dialog matching was chosen
+   over making implicit associations in an incoming INVITE based on
+   call-id or other fields for the following reasons:
+
+   o  An INVITE already has the correct semantics for a new call
+
+   o  Using an explicit Replaces header in a new request makes the
+      intent of the request obvious.
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 2]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   o  A unique call-id may be given to the replacement call.  This
+      avoids dialog matching problems in any of the related User Agents.
+
+   o  There are no adverse effects if the header is unsupported.
+
+   The Replaces header enables services such as attended call transfer,
+   retrieve from park, and transition from locally mixed conferences to
+   two party calls in a distributed peer-to-peer way.  This list of
+   services is not exhaustive.  Although the Replaces header is
+   frequently used in combination with the REFER [8] method as used in a
+   Transfer [12], they may be used independently.
+
+   For example, Alice is talking to Bob from phone1.  She transfers Bob
+   to a Parking Place while she goes to the lab.  When she gets there
+   she retrieves the "parked" call from phone2 by sending an INVITE with
+   a Replaces header field to Bob with the dialog information Bob shared
+   with the Parking Place.  Alice got this information using some out of
+   band mechanism.  Perhaps she subscribed to this information from the
+   Parking Place (using the session dialog package [13]), or went to a
+   website and clicked on a URI.  A short call flow for this example
+   follows.  (Via and Max-Forwards headers are omitted for clarity.)
+
+        Alice          Alice                             Parking
+        phone1         phone2            Bob               Place
+        |               |                 |                   |
+        |<===============================>|                   |
+        |               |                 |                   |
+        |        Alice transfers Bob to Parking Place         |
+        |               |                 |                   |
+        |------------REFER/200----------->|    *1    *2       |
+        |<--NOTIFY/200 (trying)-----------|--INVITE/200/ACK-->|
+        |<--NOTIFY/200 (success)----------|<=================>|
+        |------------BYE/200------------->|                   |
+        |               |                 |                   |
+        |               |                 |                   |
+        |  Alice later retrieves call from another phone      |
+        |               |                 |                   |
+        |            *3 |-INV w/Replaces->|                   |
+        |               |<--200-----------|                   |
+        |               |---ACK---------->|----BYE/200------->|
+        |               |<===============>|                   |
+        |               |                 |                   |
+
+
+
+
+
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 3]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   Message *1: Bob-> Parking Place
+
+   INVITE sip:parkingplace@example.org SIP/2.0
+   To: <sip:parkingplace@example.org>
+   From: <sip:bob@example.org>;tag=7743
+   Call-ID: 425928@bobster.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:bob@bobster.example.org>
+   Referred-By: <sip:alice@phone1.example.org>
+
+   Message *2: Parking Place -> Bob
+
+   SIP/2.0 200 OK
+   To: <sip:parkingplace@example.org>;tag=6472
+   From: <sip:bob@example.org>;tag=7743
+   Call-ID: 425928@bobster.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:parkplace@monopoly.example.org>
+
+   Message *3: Alice@phone2 -> Bob
+
+   INVITE sip:bob@bobster.example.org
+   To: <sip:bob@example.org>
+   From: <sip:alice@phone2.example.org>;tag=8983
+   Call-ID: 09870@phone2.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:alice@phone2.example.org>
+   Require: replaces
+   Replaces: 425928@bobster.example.org;to-tag=7743;from-tag=6472
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [2].
+
+   This document refers frequently to the terms "confirmed dialog" and
+   "early dialog".  These are defined in Section 12 of SIP [1].
+
+3.  User Agent Server Behavior: Receiving a Replaces Header
+
+   The Replaces header contains information used to match an existing
+   SIP dialog (call-id, to-tag, and from-tag).  Upon receiving an INVITE
+   with a Replaces header, the User Agent (UA) attempts to match this
+   information with a confirmed or early dialog.  The User Agent Server
+   (UAS) matches the to-tag and from-tag parameters as if they were tags
+
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 4]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   present in an incoming request.  In other words, the to-tag parameter
+   is compared to the local tag, and the from-tag parameter is compared
+   to the remote tag.
+
+   If more than one Replaces header field is present in an INVITE, or if
+   a Replaces header field is present in a request other than INVITE,
+   the UAS MUST reject the request with a 400 Bad Request response.
+
+   The Replaces header has specific call control semantics.  If both a
+   Replaces header field and another header field with contradictory
+   semantics are present in a request, the request MUST be rejected with
+   a 400 "Bad Request" response.
+
+   If the Replaces header field matches more than one dialog, the UA
+   MUST act as if no match is found.
+
+   If no match is found, the UAS rejects the INVITE and returns a 481
+   Call/Transaction Does Not Exist response.  Likewise, if the Replaces
+   header field matches a dialog which was not created with an INVITE,
+   the UAS MUST reject the request with a 481 response.
+
+   If the Replaces header field matches a dialog which has already
+   terminated, the UA SHOULD decline the request with a 603 Declined
+   response.  (If the matched invitation was just terminated, the
+   replacement request should fail as well.  Declining the request with
+   a 600-class response prevents an irritating race-condition where the
+   UA rings or alerts for a replacement call which is not wanted.)
+
+   If the Replaces header field matches an active dialog, the UA MUST
+   verify that the initiator of the new INVITE is authorized to replace
+   the matched dialog.  If the initiator of the new INVITE has been
+   successfully authenticated as equivalent to the user who is being
+   replaced, then the replacement is authorized.  For example, if the
+   user being replaced and the initiator of the replacement dialog share
+   the same credentials for Digest authentication [6], or they sign the
+   replacement request with S/MIME [7] with the same private key and
+   present the (same) corresponding certificate used in the original
+   dialog, then the replacement is authorized.
+
+   Alternatively, the Referred-By mechanism [4] defines a mechanism that
+   the UAS can use to verify that a replacement request was sent on
+   behalf of the other participant in the matched dialog (in this case,
+   triggered by a REFER request).  If the replacement request contains a
+   Referred-By header that corresponds to the user being replaced, the
+   UA SHOULD treat the replacement as if the replacement was authorized
+   by the replaced party.  The Referred-By header SHOULD reference a
+   corresponding, valid Refererred-By Authenticated Identity Body [5].
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 5]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   The UA MAY apply other local policy to authorize the remainder of the
+   request.  In other words, the UAS may apply a different policy to the
+   replacement dialog than was applied to the replaced dialog.
+
+   In addition, the UA MAY use other authorization mechanisms defined
+   for this purpose in standards track extensions.  Extensions could
+   define other mechanisms for transitively asserting authorization of a
+   replacement.
+
+   If authorization is successful, the UA attempts to accept the new
+   INVITE, reassign the user interface and other resources of the
+   matched dialog to the new INVITE, and shut down the replaced dialog.
+   If the UA cannot accept the new INVITE (for example: it cannot
+   establish required QoS or keying, or it has incompatible media), the
+   UA MUST return an appropriate error response and MUST leave the
+   matched dialog unchanged.
+
+   If the Replaces header field matches a confirmed dialog, it checks
+   for the presence of the "early-only" flag in the Replaces header
+   field.  (This flag allows the UAC to prevent a potentially
+   undesirable race condition described in Section 7.1.) If the flag is
+   present, the UA rejects the request with a 486 Busy response.
+   Otherwise, it accepts the new INVITE by sending a 200-class response,
+   and shuts down the replaced dialog by sending a BYE.  If the Replaces
+   header field matches an early dialog that was initiated by the UA, it
+   accepts the new INVITE by sending a 200-class response, and shuts
+   down the replaced dialog by sending a CANCEL.
+
+   If the Replaces header field matches an early dialog that was not
+   initiated by this UA, it returns a 481 (Call/Transaction Does Not
+   Exist) response to the new INVITE, and leaves the matched dialog
+   unchanged.  Note that since Replaces matches only a single dialog,
+   the replacement dialog will not be retargeted according to the same
+   forking logic as the original request which created the early dialog.
+
+   (Currently, no use cases have been identified for replacing just a
+   single dialog in this circumstance.)
+
+4.  User Agent Client Behavior: Sending a Replaces Header
+
+   A User Agent that wishes to replace a single existing early or
+   confirmed dialog with a new dialog of its own, MAY send the target
+   User Agent an INVITE request containing a Replaces header field.  The
+   User Agent Client (UAC) places the Call-ID, to-tag, and from-tag
+   information for the target dialog in a single Replaces header field
+   and sends the new INVITE to the target.  If the user agent only
+   wishes to replace an early dialog (as in the Call Pickup example in
+   Section 7.1), the UAC MAY also include the "early-only" parameter in
+
+
+
+Mahy, et al.                Standards Track                     [Page 6]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   the Replaces header field.  A UAC MUST NOT send an INVITE with a
+   Replaces header field that attempts to replace an early dialog which
+   was not originated by the target of the INVITE with a Replaces header
+   field.
+
+   Note that use of this mechanism does not provide a way to match
+   multiple dialogs, nor does it provide a way to match an entire call,
+   an entire transaction, or to follow a chain of proxy forking logic.
+   For example, if Alice replaces Cathy in an early dialog with Bob, but
+   Bob does not answer, Alice's replacement request will not match other
+   dialogs to which Bob's UA redirects, nor other branches to which his
+   proxy forwards.  Although this specification takes reasonable
+   precautions to prevent unexpected behavior in the face of forking,
+   implementations SHOULD only address replacement requests (i.e., set
+   the Request-URI of the replacement request) to the SIP Contact URI of
+   the target.
+
+5.  Proxy behavior
+
+   Proxy Servers do not require any new behavior to support this
+   extension.  They simply pass the Replaces header field transparently
+   as described in the SIP specification.
+
+   Note that it is possible for a proxy (especially when forking based
+   on some application layer logic, such as caller screening or time-
+   of-day routing) to forward an INVITE request containing a Replaces
+   header field to a completely orthogonal set of Contacts other than
+   the original request it was intended to replace.  In this case, the
+   INVITE request with the Replaces header field will fail.
+
+6.  Syntax
+
+6.1.  The Replaces Header
+
+   The Replaces header field indicates that a single dialog identified
+   by the header field is to be shut down and logically replaced by the
+   incoming INVITE in which it is contained.  It is a request header
+   only, and defined only for INVITE requests.  The Replaces header
+   field MAY be encrypted as part of end-to-end encryption.  Only a
+   single Replaces header field value may be present in a SIP request.
+
+   This document adds the following entry to Table 2 of [1].  Additions
+   to this table are also provided for extension methods defined at the
+   time of publication of this document.  This is provided as a courtesy
+   to the reader and is not normative in any way.  MESSAGE, SUBSCRIBE
+   and NOTIFY, REFER, INFO, UPDATE, PRACK, and PUBLISH are defined
+   respectively in [15], [16], [8], [17], [18], [19], and [20].
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 7]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+      Header field    where   proxy   ACK  BYE  CAN  INV  OPT  REG  MSG
+      ------------    -----   -----   ---  ---  ---  ---  ---  ---  ---
+      Replaces          R              -    -    -    o    -    -    -
+
+
+                                      SUB  NOT  REF  INF  UPD  PRA  PUB
+                                      ---  ---  ---  ---  ---  ---  ---
+      Replaces          R              -    -    -    -    -    -    -
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in RFC 2234 [3].  The syntax below relies on
+   a number of productions from SIP [1].
+
+      Replaces        = "Replaces" HCOLON callid *(SEMI replaces-param)
+      replaces-param  = to-tag / from-tag / early-flag / generic-param
+      to-tag          = "to-tag" EQUAL token
+      from-tag        = "from-tag" EQUAL token
+      early-flag      = "early-only"
+
+   A Replaces header field MUST contain exactly one to-tag and exactly
+   one from-tag, as they are required for unique dialog matching.  For
+   compatibility with dialogs initiated by RFC 2543 [9] compliant UAs, a
+   tag of zero matches both tags of zero and null.  A Replaces header
+   field MAY contain the early-flag.
+
+   Examples:
+
+      Replaces: 98732@sip.example.com
+                ;from-tag=r33th4x0r
+                ;to-tag=ff87ff
+
+      Replaces: 12adf2f34456gs5;to-tag=12345;from-tag=54321;early-only
+
+      Replaces: 87134@171.161.34.23;to-tag=24796;from-tag=0
+
+6.2.  New Option Tag for Require and Supported Headers
+
+   This specification defines a new Require/Supported header option tag
+   "replaces".  UAs which support the Replaces header MUST include the
+   "replaces" option tag in a Supported header field.  UAs that want
+   explicit failure notification if Replaces is not supported MAY
+   include the "replaces" option in a Require header field.
+
+   Example:
+
+      Require: replaces, 100rel
+
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 8]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+7.  Usage Examples
+
+   The following non-normative examples are not intended to enumerate
+   all the possibilities for the usage of this extension, but rather to
+   provide examples or ideas only.  For more examples, please see SIP
+   Service Examples [14].  Via and Max-Forwards headers are omitted for
+   clarity and brevity.
+
+7.1.  Replacing an Early Dialog at the Originator
+
+   In this example, Bob just arrived in the lab and hasn't registered
+   there yet.  He hears his desk phone ring.  He quickly logs into a
+   software UA on a nearby computer.  Among other things, the software
+   UA has access to the dialog state of his desk phone.  When it notices
+   that his phone is ringing, it offers him the choice of taking the
+   call there.  The software UA sends an INVITE with Replaces to Alice.
+   When Alice's UA receives this new INVITE, it CANCELs her original
+   INVITE and connects Alice to Bob.
+
+                              Bob                      Bob
+       Alice                  desk                     lab
+        |                       |                        |
+    *1  |-----INVITE----------->|                        |
+    *2  |<----180---------------|  Bob hears desk phone  |
+        |                       |  ringing from lab but  |
+        |                       |  isn't REGISTERed yet  |
+        |                       |                        |
+        |                       |<--fetch dialog state --|
+        |                       |---response ----------->|
+   *3/4 |<-----INVITE with Replaces/200/ACK--------------|
+   *5/6 |------CANCEL/200------>|                        |
+   *7   |<-----487--------------|                        |
+        |------ACK------------->|                        |
+        |                       |                        |
+        |                       |                        |
+
+   Message *1: Alice -> Bob's desk phone
+
+   INVITE sip:bob@example.org SIP/2.0
+   To: <sip:bob@example.org>
+   From: <sip:alice@example.org>;tag=7743
+   Call-ID: 425928@phone.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:alice@phone.example.org>
+
+
+
+
+
+
+
+Mahy, et al.                Standards Track                     [Page 9]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   Message *2: Bob's desk phone -> Alice
+
+   SIP/2.0 180 Ringing
+   To: <sip:bob@example.org>;tag=6472
+   From: <sip:alice@example.org>;tag=7743
+   Call-ID: 425928@phone.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:bob@bobster.example.org>
+
+   Message *3: Bob in lab -> Alice
+
+   INVITE sip:alice@phone.example.org
+   To: <sip:alice@example.org>
+   From: <sip:bob@example.org>;tag=8983
+   Call-ID: 09870@labpc.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:bob@labpc.example.org>
+   Replaces: 425928@phone.example.org
+    ;to-tag=7743;from-tag=6472;early-only
+
+   Message *4: Alice -> Bob in lab
+
+   SIP/2.0 200 OK
+   To: <sip:alice@example.org>;tag=9232
+   From: <sip:bob@example.org>;tag=8983
+   Call-ID: 09870@labpc.example.org
+   CSeq: 1 INVITE
+   Contact: <sip:alice@phone.example.org>
+
+   Message *5: Alice -> Bob's desk
+
+   CANCEL sip:bob@example.org SIP/2.0
+   To: <sip:bob@example.org>
+   From: <sip:alice@example.org>;tag=7743
+   Call-ID: 425928@phone.example.org
+   CSeq: 1 CANCEL
+   Contact: <sip:alice@phone.example.org>
+
+   Message *6: Bob's desk -> Alice
+
+   SIP/2.0 200 OK
+   To: <sip:bob@example.org>
+   From: <sip:alice@example.org>;tag=7743
+   Call-ID: 425928@phone.example.org
+   CSeq: 1 CANCEL
+   Contact: <sip:bob@bobster.example.org>
+
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 10]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   Message *7: Bob's desk -> Alice
+
+   SIP/2.0 487 Request Terminated
+   To: <sip:bob@example.org>;tag=6472
+   From: <sip:alice@example.org>;tag=7743
+   Call-ID: 425928@phone.example.org
+   CSeq: 1 INVITE
+
+8.  Security Considerations
+
+   The extension specified in this document significantly changes the
+   relative security of SIP devices.  Currently in SIP, even if an
+   eavesdropper learns the Call-ID, To, and From headers of a dialog,
+   they cannot easily modify or destroy that dialog if Digest
+   authentication or end-to-end message integrity are used.
+
+   This extension can be used to disconnect participants or replace
+   participants in a multimedia conversation.  As such, invitations with
+   the Replaces header MUST only be accepted if the peer requesting
+   replacement has been properly authenticated using a standard SIP
+   mechanism (Digest or S/MIME), and authorized to request a replacement
+   of the target dialog.  All SIP implementations are already required
+   to support Digest Authentication.  In addition, implementations which
+   support the Replaces header SHOULD also implement the Referred-By
+   mechanism.
+
+   How a User Agent determines which requests are legitimately
+   authorized to make dialog replacements is non-trivial and depends on
+   a considerable amount of local policy configuration.  In general,
+   there are four cases when an authorization for a replacement is
+   reasonable or warranted.
+
+   1. Replacement made by a party considered equivalent to the replaced
+      party
+
+   2. Replacement made on behalf of the replaced party (perhaps
+      transitively)
+
+   3. Replacement made by a former participant
+
+   4. Replacement made by a specifically authorized party
+
+   Starting with #1 for example, if an executive and an assistant both
+   receive requests for a shared address-of-record, if so configured,
+   either should be able to replace dialogs of the other for the shared
+   identity.  Both could even share the same keying material (Digest or
+   S/MIME), or one could hold an authorization document signed by the
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 11]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   other expressing this relationship.  Likewise, in a call center
+   environment, each call center agent could possess credentials to
+   which supervisors also have access.
+
+   The most common use case of a replacement is on the request of the
+   replaced participant (who no longer wants to be involved).  This is
+   the case in many features, such as completing an Attended Transfer
+   and converting a 3-way call to a point-to-point call.  Such
+   replacements are typically triggered by a REFER [8] request from the
+   replaced participant.  The Referred-By [4] mechanism defines one way
+   to identify the apparent original requester and can point to a SIP
+   Authenticated Identity Body [5] (an S/MIME-based signed assertion) to
+   secure this information.
+
+   In the example in section 1, Alice sends an INVITE with Replaces to
+   Bob.  Alice was a former participant in the conversation and had a
+   previous dialog relationship with Bob.  Alice can use the same Digest
+   or S/MIME credentials she used to authenticate with Bob during the
+   original call to prove that she was a former participant.  Note that
+   this justification for replacing calls is more dangerous than the
+   others, and in most cases is another way to authorize that the
+   replacing participant is available.  Implementations SHOULD NOT rely
+   on this method as an authorization mechanism.
+
+   The last scenario is the easiest to secure but the least likely to be
+   useful in practice.  It is unlikely that an arbitrary host in the
+   Internet is aware of any special authorization relationship between
+   the replaced and the replacing parties.  However, this use case may
+   be useful in some environments.  Since this usage does not
+   effectively degrade the security of the solution, it is still
+   allowed.
+
+   Some mechanisms for obtaining the dialog information needed by the
+   Replaces header (Call-ID, to-tag, and from-tag) include URIs on a web
+   page, subscriptions to an appropriate event package, and
+   notifications after a REFER request.  Since manipulating this dialog
+   information could cause User Agents to replace the wrong dialog, use
+   of message integrity protection for this information is STRONGLY
+   RECOMMENDED.  Use of end-to-end security mechanisms to encrypt this
+   information is also RECOMMENDED.
+
+   This extension was designed to take advantage of future signature or
+   authorization schemes defined in standards track extensions.  In
+   general, call control features benefit considerably from such work.
+
+
+
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 12]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+9.  IANA Considerations
+
+9.1.  Registration of "Replaces" SIP header
+
+   Name of Header:          Replaces
+
+   Short form:              none
+
+   Normative description:   section 6.1 of this document
+
+9.2.  Registration of "replaces" SIP Option-tag
+
+   Name of option:          replaces
+
+   Description:             Support for the SIP Replaces header
+
+   SIP headers defined:     Replaces
+
+   Normative description:   This document
+
+10.  Acknowledgments
+
+   Thanks to Robert Sparks, Alan Johnston, Dan Petrie, Ben Campbell, and
+   many other members of the SIP WG for their continued support of the
+   cause of distributed call control in SIP.
+
+11.  References
+
+11.1.  Normative References
+
+   [1]  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.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [4]  Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
+        Mechanism", RFC 3892, September 2004.
+
+   [5]  Peterson, J., "The Session Initiation Protocol (SIP)
+        Authenticated Identity Body (AIB) Format", RFC 3893, September
+        2004.
+
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 13]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   [6]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+        Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
+        Basic and Digest Access Authentication", RFC 2617, June 1999.
+
+   [7]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+        (S/MIME) Version 3.1 Message Specification", RFC 3851, July
+        2004.
+
+11.2.  Informative References
+
+   [8]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
+        Method", RFC 3515, April 2003.
+
+   [9]  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
+        "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+   [10] Mahy, R., "A Call Control and Multi-party usage framework for
+        the Session Initiation Protocol (SIP)", Work in Progress, March
+        2003.
+
+   [11] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
+        "Best Current Practices for Third Party Call Control (3pcc) in
+        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
+        2004.
+
+   [12] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
+        Control - Transfer", Work in Progress, February 2003.
+
+   [13] Rosenberg, J. and H. Schulzrinne, "An INVITE Initiated Dialog
+        Event Package for the Session Initiation Protocol (SIP)", Work
+        in Progress, March 2003.
+
+   [14] Johnston, A. and S. Donovan, "Session Initiation Protocol
+        Service Examples", Work in Progress, March 2003.
+
+   [15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
+        D. Gurle, "Session Initiation Protocol (SIP) Extension for
+        Instant Messaging", RFC 3428, December 2002.
+
+   [16] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
+        Notification", RFC 3265, June 2002.
+
+   [17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
+
+   [18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+        Method", RFC 3311, October 2002.
+
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 14]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+   [19] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+        Responses in Session Initiation Protocol (SIP)", RFC 3262, June
+        2002.
+
+   [20] Campbell, B., "SIMPLE Presence Publication Mechanism", Work in
+        Progress, February 2003.
+
+12.  Authors' Addresses
+
+   Rohan Mahy
+   Cisco Systems, Inc.
+   5617 Scotts Valley Dr
+   Scotts Valley, CA  95066
+   USA
+
+   EMail: rohan@cisco.com
+
+
+   Billy Biggs
+
+   EMail: bbiggs@dumbterm.net
+
+
+   Rick Dean
+
+   EMail: rfc@fdd.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 15]
+
+RFC 3891               The SIP "Replaces" Header          September 2004
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   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/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 IETF's procedures with respect to rights in IETF 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Mahy, et al.                Standards Track                    [Page 16]
+