SIP Working Group C. Holmberg
Internet-Draft Ericsson
Expires: June 4, 2009 December 1, 2008
Response Code for Indication of Terminated Dialog
draft-ietf-sip-199-03.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 June 4, 2009.
Abstract
This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP forking proxy and a UAS can use to indicate
upstream towards the UAC that an early dialog has been terminated,
before a final response is sent towards the UAC.
Holmberg Expires June 4, 2009 [Page 1]
Internet-Draft 199 December 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 4
4.1. Examples of resource types . . . . . . . . . . . . . . . . 5
4.2. Examples of policy procedures . . . . . . . . . . . . . . 6
5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 7
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Backward compability . . . . . . . . . . . . . . . . . . . . . 8
8. 199 Early Dialog Terminated . . . . . . . . . . . . . . . . . 8
9. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9
10. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 9
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Example with a forking proxy which generates 199 . . . . . 9
11.2. Example with a forking proxy which receives 200 OK . . . . 10
11.3. Example with two forking proxies, of which one
generates 199 . . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13.1. IANA Registration of the 199 response code . . . . . . . . 12
13.2. IANA Registration of the 199 Option Tag . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
15. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Holmberg Expires June 4, 2009 [Page 2]
Internet-Draft 199 December 2008
1. Introduction
As defined in SIP (Session Initiation Protocol) specification
[RFC3261], an early SIP dialog is created when a non-100 provisional
response is sent to the dialog initiation request (e.g. INVITE).
The dialog is considered to be in early state until a final response
is sent.
When a proxy receives an initial request (outside an existing dialog,
and without a pre-defined route set), it can forward it towards
multiple remote destinations. When the proxy does that, it performs
forking.
When a forking proxy receives non-100 provisional responses, it
forwards the responses upstream towards the sender of the associated
request. When a forking proxy receives a 2xx final response, it
forwards the response upstream towards the sender of the associated
request. At that point the proxy normally sends a CANCEL request
downstream towards all remote destinations where it previously sent
the request associated with the 2xx final response, and from which it
has yet not received a final response, in order to terminate
associated outstanding early dialogs. It is possible to receive
multiple 2xx final responses. When SIP entities upstream receive the
first 2xx final response, and they do not to intend to accept
subsequent 2xx final responses, they will automatically terminate
other associated outstanding early dialogs. If additional 2xx final
responses are received, for INVITE initiated dialogs those SIP
entities will normally send a BYE request using the dialog identifier
retrieved from the subsequent 2xx final response.
NOTE: A UAC can use the Request-Disposition header [RFC3841] to
request that proxies do not send CANCEL requests downstream once they
have received the first final 2xx response.
When a forking proxy receives a non-2xx final response, it does not
always immediately forward the response upstream towards the sender
of the associated request. Instead, the forking proxy "stores" it
and waits for further final responses from remote destinations where
the forked request was forwarded. At some point the proxy uses a
specified mechanism to determine the "best" final response code, and
forwards that final response upstream towards the sender of the
associated request. When SIP entities upstream receive the non-2xx
final response they will release resources associated with the
session, and the UAC will terminate the session setup.
Since the forking proxy does not always immediately forward non-2xx
final responses, SIP entities upstream (including the UAC that
initiated the request) do not know that a specific early dialog has
Holmberg Expires June 4, 2009 [Page 3]
Internet-Draft 199 December 2008
been terminated, and the SIP entities keep possible resources
associated with the early dialog until they receive a final response
from the forking proxy.
This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a forking proxy and a UAS can use to indicate
upstream that an early dialog has been terminated. The 199 response
can also be sent by a UAS, prior to sending a non-2xx final response.
SIP entities that receive the 199 provisional response MAY release
resources associated with the specific early dialog. The SIP
entities MAY also use the 199 provisional response to make policy
related decissions related to early dialogs.
The 199 response code is an optimization, which allows the UAC to be
informed about terminated early dialogs. However, since the support
of the 199 response is optional, a UAC cannot assume that it will
always receive a 199 provisional response for all terminated early
dialogs.
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
[RFC2119].
3. Requirements
REQ 1: It must be possible to indicate to the UAC that an early
dialog has been terminated before a final response is sent.
4. User Agent Client behavior
When a UAC sends an initial request, and if it wants to receive 199
responses, it MUST insert the 199 option-tag in the Supported header,
which indicates that the client supports the 199 Early Dialog
Terminated response code. The UAC SHOULD NOT insert the 199 option-
tag in the Require header, unless the particular session usage
requires the UAS to support the response code. Also, the UAC SHOULD
NOT insert the 199 option-tag in the Proxy-Require header unless the
particular session usage requires every proxy on the path to support
the response code. Using Require or Proxy-Require with the 199
option-tag will in many cases result in unnecessary session
establishment failures.
Holmberg Expires June 4, 2009 [Page 4]
Internet-Draft 199 December 2008
When a UAC receives a 199 response it MAY release resources and
procedures associated with the early dialog on which the 199 response
is received. Examples of resources and procedures are e.g.
procedures for the establishment of media plane resources (bandwidth,
radio, codecs etc), media security procedures or procedures related
to NAT traversal. In addition, the UAC may use the 199 response for
policy decissions related to early dialogs, e.g. when choosing to
process media associated with a particular early dialog.
If multiple usages [RFC5057] are used within an early dialog, and it
is not clear which dialogusage the 199 response terminates, SIP
entities that keep dialog state shall not release resources
associated with the early dialog when they receive the 199 response.
If a client receives a 199 response on a dialog which has not
previously been created (this can happen if a 199 response reaches
the client before a 18x response) the client SHALL discard the 199
responses.
4.1. Examples of resource types
Examples which benefit from resource-release are:
1. Codec release - when resources for a specific codec has been
reserved only for the stream that is terminated. In that case the
resources associated with that codec can be released.
2. Pre-conditions - when the dialog is terminated, procedures and
resources associated to the pre-conditions for that dialog can be
released.
3. In-band security negotiation - when the dialog is terminated,
procedures and resources associated with the in-band security
negototiation for that dialog can be released.
4. ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is
terminated, procedures and resources associated with the ICE related
in-band procedures for that dialog can be released.
5. Limited access resources - in case of forking and multiple stream
it may not be possible to allow early media on all dialogs, so media
sessions associated with some dialogs may e.g. be set to "inactive".
When a dialog is terminated, media sessions associated with other
dialogs can be allowed.
6. Secure media selection - when SRTP is used to encrypt the media.
In some cases SIP entities are only able to render media associated
with a single early dialog. If a 199 response is recieved on a
Holmberg Expires June 4, 2009 [Page 5]
Internet-Draft 199 December 2008
dialog, and media associated with that media has been rendered, the
SIP entity can start rendering media associated with another early
dialog.
If the client is able to associate the 199 response with a specific
media stream, it MAY choose to discard media on that specific media
stream, it MAY release all resources associated with that media
stream and it MAY start to process media streams received on other
early diaogs. When the P-Early-Media header is used, a UA MAY
trigger different actions depending on whether the header has been
used for the terminated dialog. How the association between the
dialog and the associated media stream is done is outside the scope
of this document.
NOTE: When using SRTP [RFC3711], the secure media stream is bound to
the crypto context setup for the dialog, and can be identified using
the MKI (if used) of SRTP.
If the client only has a single early dialog (other early dialogs MAY
not have been established, or they MAY have been established and
later terminated) when a 199 response is received for that early
dialog, after the client has terminated the early dialog associated
with the 199 response it will act as before the first early dialog
was established.
4.2. Examples of policy procedures
1. UAC early media selection - when media associated with multiple
early dialogs is received, SIP endpoint normally chooses to process
media associated with a single early dialog (e.g. the recently
established early dialog). If a 199 response is received on such
early dialog, the SIP endpoint can start processing media associated
with another early dialog. For example, an early dialog may be used
for an anouncement message, and when the message is finished a 199
response will be sent on that dialog, in order for the SIP endpoint
to stop processing media associated with that early dialog. This
kind of policy is normal especially in PSTN gateways, where the
calling user cannot control which media is processed.
2. SBC early media selection - when an SBC is used to control which
media is processed and forwarded. In many cases, the SBC only
processes media associated with a single early dialog. Typical for
NAT traversal, the SBC often "latches" onto a media stream. If a 199
response is received, the SBC can choose to start processing media
associated with another dialog. If the SBC performs latching, it can
trigger a "re-latch" onto a new media stream when the 199 response is
received.
Holmberg Expires June 4, 2009 [Page 6]
Internet-Draft 199 December 2008
5. User Agent Server behavior
If the received initial request contains an 199 option tag, the UAS
SHOULD NOT send a 199 response for a dialog on which it intends to
send a final response, unless it e.g. has been configured to do so
due to lack of 199 support by forking proxies or other intermediate
SIP entities.
When a UAS generates a 199 response, the response MUST contain a To
header tag parameter, which identifies the early dialog that has been
terminated.
OPEN ISSUE: If the UAS sends a 199 response, which is not triggered
by another SIP response (if the UAS is a SIP endpoint), shall it
still insert a Reason header? If so, what response code shall be
inserted in the Reason header?
If the UAS intends to send 199 responses, and if it supports the
procedures defined in [RFC3840], it MAY during the registration
procedure use the sip.extensions feature tag [RFC3840] to indicate
support of the 199 response code.
6. Proxy behavior
When a proxy receives a 199 provisional response, the proxy MUST
process the response as any other non-100 provisional responses. The
proxy will forward the response upstream towards the sender of the
associated request. The proxy MAY release resources it has reserved
associated with the early dialog on which the response is received.
When a forking proxy receives a non-2xx final response which
terminates one or more (if forking has occured downstream a final
response received by the forking proxy MAY terminate multiple early
dialogs), and the proxy does not intend to forward the final response
immedialetly (due to the rules for a forking proxy), and the UAC has
indicated support of the 199 response code, the proxy MUST generate
and send a 199 response upstream for the early dialog on which the
non-2xx final response was received, unless the proxy has previously
recieved and forwarded a 199 response for the dialog. If the forking
proxy is able to identify additional early dialogs which are
terminated by the same non-2xx final response, it MUST also generate
and send a 199 provional response upstream for each of those early
dialogs, except for any dialog on which the proxy has previously
received and forwarded a 199 response.
When a forking proxy generates a 199 response, the response MUST
contain a To header tag parameter, which identifies the early dialog
Holmberg Expires June 4, 2009 [Page 7]
Internet-Draft 199 December 2008
that has been terminated. The forking prxy MUST also insert a Reason
header [RFC3326] which contains the response code of the response
that triggered the 199 response.
A proxy which supports generating of 199 response codes MUST keep
track of early dialogs, in order to determine whether to generate a
199 response when the proxy receives a non-2xx final response. In
addition, the proxy MUST keep track on which early dialogs it has
received and forwarded 199 responses, in order to not generate
additional 199 responses for those early dialogs.
If a forking proxy receives a reliablly sent 199 response for a
dialog, for which the proxy has previously generated and sent a 199
response, the proxy MUST forward the 199 response. In case of a
unreliably sent 199 response, the proxy MAY forward the 199 response,
or it MAY discard it.
7. Backward compability
Since all SIP entities involved in a session setup do not necessarily
support the specific meaning of the 199 Early Dialog Terminated
provisional response, the sender of the response MUST be prepared to
receive SIP requests and responses associated with the dialog for
which the 199 response was sent (a proxy can receive SIP messages
from either direction). If such request is received by a UA, it MUST
act in the same way as if it had received the request after sending
the final non-2xx response to the INVITE, as specified in [RFC3261].
A UAC that receives a 199 response for an early dialog MUST NOT send
any further requests on that dialog, except for requests which
acknowledge reliable responses. A proxy MUST forward requests
according to [RFC3261], even if the proxy has knowledge that the
early dialog has been terminated.
The 199 Early Dialog Terminated response code does not "replace" a
final response. A final response is always sent, after one or many
199 provisional responses have been sent.
8. 199 Early Dialog Terminated
The 199 Early Dialog Terminated response code allows a SIP entity to
indicate upstream that a specific dialog has been terminated, before
a final response is sent by the entity. The To header tag value is
used to identify the dialog.
Holmberg Expires June 4, 2009 [Page 8]
Internet-Draft 199 December 2008
9. Usage with SDP offer/answer
A 199 Early Dialog Terminated provisional response MUST NOT contain
an SDP offer/answer message body.
10. Usage with 100rel
When a 199 Early Dialog Terminated provisional response is sent by a
UAS, since the provisional response is only used for information
purpose, the UAS SHOULD send it unreliably even if the 100rel option
tag [RFC3262] is present in the Require header of the associated
request.
When a forking proxy generates a 199 response, the response MUST NOT
be sent reliably.
NOTE: The 199 response MUST NOT be sent reliably if it would be
required to insert a new SDP offer/answer message body in the
response, according to the rules in [RFC3264].
11. Examples
11.1. Example with a forking proxy which generates 199
The figure shows an example, where a proxy (P1) forks an INVITE
received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4,
which send 18x provisional responses in order to create early dialogs
between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by
sending a 4xx error response each. When P1 receives the 4xx
responses it immediately sends 199 responses, associated with the
dialogs where the 4xx responses were received, towards the UAC.
Holmberg Expires June 4, 2009 [Page 9]
Internet-Draft 199 December 2008
UAC P1 UAS_2 UAS_3 UAS_4
--- INVITE ------>
--- INVITE (leg 2) ->
--- INVITE (leg 3) ---------->
--- INVITE (leg 4) ------------------->
<-- 18x (leg 2) -----
<-- 18x (leg 2) --
<-- 18x (leg 3) --------------
<-- 18x (leg 3) --
<-- 18x (leg 4) -----------------------
<-- 18x (leg 4) --
<-- 4xx (leg 2) -----
--- ACK (leg 2) ---->
<-- 199 (leg 2) --
<-- 4xx (leg 3) --------------
--- ACK (leg 3) ------------->
<-- 199 (leg 3) --
<-- 200 (leg 4) -----------------------
<-- 200 (leg 4) --
--- ACK (leg 4) ->
--- ACK (leg 4) ---------------------->
Figure 1: Example call flow
11.2. Example with a forking proxy which receives 200 OK
The figure shows an example, where a proxy (P1) forks an INVITE
received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4,
which send 18x provisional responses in order to create early dialogs
between themselves and the UAC. UAS_4 accepts the session by sending
a 200 OK final response. When P1 receives the 200 OK responses it
immediately forwards it towards the UAC. P1 does not send 199
responses for the early dialogs from UAS_2 and UAS_3, since P1 has
yet not received any final responses on those early dialogs (even if
P1 sends CANCEL request to UAS_2 and UAS_3 P1 may still receive 200
OK final response from UAS_2 or UAS_3, which P1 would have to forward
towards the UAC.
Holmberg Expires June 4, 2009 [Page 10]
Internet-Draft 199 December 2008
UAC P1 UAS_2 UAS_3 UAS_4
--- INVITE ------>
--- INVITE (leg 2) ->
--- INVITE (leg 3) ---------->
--- INVITE (leg 4) ------------------->
<-- 18x (leg 2) -----
<-- 18x (leg 2) --
<-- 18x (leg 3) --------------
<-- 18x (leg 3) --
<-- 18x (leg 4) -----------------------
<-- 18x (leg 4) --
<-- 200 (leg 4) -----------------------
<-- 200 (leg 4) --
--- ACK (leg 4) ->
--- ACK (leg 4) ---------------------->
Figure 2: Example call flow
11.3. Example with two forking proxies, of which one generates 199
The figure shows an example, where a proxy (P1) forks an INVITE
received from UAC. One of the forked INVITEs reaches UAS_2. The
other forked INVITE reaches another proxy (P2), which forks the
INVITE to UAS_3 and UAS_4, which send 18x provisional responses in
order to create early dialogs between themselves and the UAC. UAS_3
and UAS_4 reject the INVITE by sending a 4xx error response each. P2
does not support the 199 response code, and forwards a single 4xx
response. When P1 receives the 4xx responses from P2, it manages to
associate the response with the early dialogs from both UAS_3 and
UAS_4, so it generates and sends two 199 response to indicate that
the early dialogs from UAS_3 and UAS_4 have been terminated.
Holmberg Expires June 4, 2009 [Page 11]
Internet-Draft 199 December 2008
UAC P1 P2 UAS_2 UAS_3 UAS_4
--- INVITE ------>
--- INVITE (leg 2) ----------------------->
--- INVITE --------->
--- INVITE (leg 3) ------------>
--- INVITE (leg 4) --------------------->
<-- 18x (leg 3) ----------------
<-- 18x (leg 3) -----
<-- 18x (leg 3) --
<-- 18x (leg 4) -------------------------
<-- 18x (leg 4) -----
<-- 18x (leg 4) --
<-- 4xx (leg 3) ----------------
--- ACK (leg 3) --------------->
<-- 4xx (leg 4) -------------------------
--- ACK (leg 4) ------------------------>
<-- 4xx (leg 3) ----
--- ACK (leg 3) --->
<-- 199 (leg 3) --
<-- 199 (leg 4) --
<-- 200 (leg 2) --------------------------
<-- 200 (leg 2) --
--- ACK (leg 2) ->
--- ACK (leg 2) ------------------------->
Figure 3: Example call flow
12. Security Considerations
OPEN ISSUE: We still need to discuss the security considerations for
199.
13. IANA Considerations
This section registers a new SIP response code and a new option tag,
according to the procedures of RFC 3261.
13.1. IANA Registration of the 199 response code
This section registers a new SIP response code, 199. The required
information for this registration, as specified in RFC 3261, is:
Holmberg Expires June 4, 2009 [Page 12]
Internet-Draft 199 December 2008
RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification]]
Response Code Number: 199
Default Reason Phrase: Early Dialog Terminated
13.2. IANA Registration of the 199 Option Tag
This section registers a new SIP option tag, 199. The required
information for this registration, as specified in RFC 3261, is:
Name: 199
Description: This option tag is for indicating support of the 199
Early Dialog Terminated provisional response code. When present
in a Supported header, it indicates that the UA supports the
response code. When present in a Require header in a request,
it indicates that the UAS MUST support the sending of the
response code.
14. Acknowledgements
Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet,
Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan,
Timothy Dwight and Dean Willis for their feedback and suggestions.
15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
Holmberg Expires June 4, 2009 [Page 13]
Internet-Draft 199 December 2008
RFC 3326, December 2002.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
RFC 3420, November 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires June 4, 2009 [Page 14]
Internet-Draft 199 December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Holmberg Expires June 4, 2009 [Page 15]