Internet DRAFT - draft-aartsetuijn-nipst
draft-aartsetuijn-nipst
Network Working Group J. Aartse Tuijn
Internet-Draft University of Twente
Intended status: Standards Track D. Bijwaard
Expires: August 30, 2007 Alcatel-Lucent
February 26, 2007
A method for network initiated partial session transfers
draft-aartsetuijn-nipst-00
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 August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 1]
Internet-Draft Method for network initiated PST February 2007
Abstract
This document describes a SIP-based method for network initiated
partial session transfers that works together with terminal initiated
partial session transfers. It uses the Mobile Node Control Mode for
terminal initiated partial session transfers and it extends this
method to support network initiated partial session transfers.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of operation . . . . . . . . . . . . . . . . . . . . 6
3.1. Key concepts . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Component overview . . . . . . . . . . . . . . . . . . . . 6
3.3. Network initiated partial session transfer . . . . . . . . 7
3.4. Retrieval of a media-stream . . . . . . . . . . . . . . . 10
4. 'pst-control' option-tag . . . . . . . . . . . . . . . . . . . 12
5. The Pst-to header field . . . . . . . . . . . . . . . . . . . 13
6. Pst-call-id header . . . . . . . . . . . . . . . . . . . . . . 14
7. Behaviour of SSC . . . . . . . . . . . . . . . . . . . . . . . 15
8. Behaviour when receiving INVITE with 'pst-control' in
Require header . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Sender of proposal can be any node in the signalling
path . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Sudden disconnection of the MN . . . . . . . . . . . . . . 17
9.3. MN is informed about the existence of a LN . . . . . . . . 17
9.4. LN is informed about the IP-address of the CN . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10.1. Pst-to and Pst-call-id headers . . . . . . . . . . . . . . 18
10.2. Option Tag . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. Normative References . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 2]
Internet-Draft Method for network initiated PST February 2007
1. Requirements notation
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 [RFC2119].
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 3]
Internet-Draft Method for network initiated PST February 2007
2. Introduction
As work in progress [shacham06] described, SIP Session Mobility is
the seamless transfer of media of an ongoing communication session
from one device to another. A system for session mobility is
defined, aimed at allowing a Mobile Node (MN) to discover available
nodes and to include them in an active session. [shacham06] also
defines how the different parts of a session can be individually
transferred to these devices, meaning the different stream endpoints
in a multimedia-stream can each be transferred to another device,
here called partial session mobility. Two methods are proposed, the
Session Handoff mode and the Mobile Node Control Mode.
With both these methods the Mobile Node (The mobile terminal used by
the user) initiates the partial session transfer. This document
describes how a partial session transfer can be initiated from a
dedicated node located in the network such that Mobile Node initiated
partial session transfers are still possible based on de described
method in [aartsetuijn06] and the work in progress [shacham06].
Network initiated partial session transfers would typically be
triggered by external events like network-side discovery of nearby
multimedia devices like beamers.
When the dedicated node in the network initiates a partial session
transfers, the user may want to be involved in the decision;
therefore the partial session transfer is proposed to the user-
terminal to let the user decide about the actual execution of the
partial session transfer. The following information is assumed to be
necessary for the user decision:
o Which media-stream endpoint will be transferred
o The device to transfer the stream endpoint to
o The media-parameters to be used for the media-stream after the
transfer
As described in [aartsetuijn06] the most applicable solution to base
network initiated partial session mobility on is the Mobile Node
Control Mode.
Mechanisms for session transfer between a terminal's IP and circuit
voice interface are specified in the 3GPP voice call continuity (VCC)
standards [3GPP 23.279]. Contrary to this, the partial session
mobility procedure described here targets usage of multiple SIP-
enabled devices at each endpoint of a SIP session and the decision
for suggesting partial session transfer comes from a (network) node
that perceives which devices close to the SIP session endpoint can
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 4]
Internet-Draft Method for network initiated PST February 2007
enhance the multimedia session.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 5]
Internet-Draft Method for network initiated PST February 2007
3. Overview of operation
This section describes the operation of network initiated partial
session mobility; the Mobile Node initiated partial session transfers
are assumed to be handled with the Mobile Node Control Mode as
described in [shacham06].
3.1. Key concepts
The Mobile Node Control Mode uses the capabilities of SDP [RFC4566]
to transfer media-stream endpoints to different devices. Since the
media-stream endpoints are controlled solely on the control plane,
network initiated partial session mobility can be supported entirely
on the control plane, while the actual media-streams are set up
directly between the devices.
A network node supporting network initiated partial session mobility
should be part of all the session-specific SIP signalling of the
nodes that want to use the service. This means the node can alter/
change and setup sessions on behalve of the involved nodes. A new
session will be set up by the dedicated node in the network if it
involves a new device to handle one or more media-streams. The
sessions with other devices that help the Mobile Node (MN) handle
media-streams are called sub-sessions
A mobility session is defined as a session of a Mobile Node with is
peer in a session, and the sub-sessions between the Mobile Node and
the additional devices that are used in the session with the peer.
Another important concept being used is using a proposal to let the
user decide about the execution of a network initiated partial
session transfer. This means the dedicated node located in the
network must first propose a partial session transfer to the user or
user-terminal, after which it is only executed if the user agrees
with the proposed transfer.
3.2. Component overview
The network node to initiate partial session mobility is called the
sub-session controller (SSC); it acts as a SIP B2BUA. In IMS [3GPP
23.228] this would typically be implemented as an application server.
The SSC can offer its service to each individual node on each
individual session that has the SSC in its signalling path. In this
document the MN is the user-terminal that the SSC is offering its
service to. The MN does have an ongoing session with a corresponding
node (CN). To accomodate the user-terminal other devices can be used
as endpoint for the involved media-streams, these devices are called
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 6]
Internet-Draft Method for network initiated PST February 2007
local nodes (LNs). Examples of LNs are an audio node (AN) that can
play and record audio and a video node (VN) that can play and record
video. Ofcourse LNs can also act only as source or target for media-
streams.
In case the CN also wants to use partial session mobility itself, it
will play the role of MN in its own mobility session. This means a
session between two devices can be represented by two mobility
sessions, each of which contains the session between the two devices,
but with each of the devices in another role.
3.3. Network initiated partial session transfer
Before a partial session transfer can be initiated a session must
exist. The SSC is located in the signalling path of this session,
and it acts as a B2BUA. Figure 1 shows the message sequence diagram
of a typical network initiated partial session transfer. Below this
message sequence diagram is explained in more detail.
To propose the partial session transfer to the user the SSC sends an
INVITE message (1) to the MN. This message uses the option-tag 'pst-
control' in the Required header field to make sure the MN can
interpet the message correctly. If the MN does not accept the
proposal it responses with 603 (Decline), as shown in Figure 2 ,
message (2). In that case the SSC should not proceed with the
partial session transfer.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 7]
Internet-Draft Method for network initiated PST February 2007
AN MN SSC CN
| | (1) INVITE | |
| |<-----------------| |
| | (2) 200 OK | |
| |----------------->| |
| | (3) ACK | |
| |<-----------------| |
| | | |
| | | (4) INVITE |
| | |--------------->|
| | | (5) 200 OK |
| | |<---------------|
| | | |
| | (6) INVITE | |
| |<-----------------| |
| | (7) 200 OK | |
| |----------------->| |
| | (8) ACK | |
| |<-----------------| |
| | | |
| (9) INVITE no SDP | | |
|<---------------------------------------| |
| (10) 200 OK AN SDP | | |
|--------------------------------------->| |
| (11) ACK CN SDP | | |
|<---------------------------------------| |
| RTP Audio | | |
|........................................................>|
| | | (12) ACK |
| | |--------------->|
| RTP Audio | | |
|<........................................................|
| | | |
Figure 1: Network initiated partial session transfer
AN MN SSC CN
| | (1) INVITE | |
| |<-----------------| |
| | (2) 603 DECLINE | |
| |----------------->| |
| | | |
Figure 2: Decline of a network initiated partial session transfer
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 8]
Internet-Draft Method for network initiated PST February 2007
As described in Section 2 it is assumed the MN need to know which
media stream will be transferred, to which device it will be
transferred, and with which media-parameters. To show to what device
the media-stream will be transferred, a new header field is
introduced for INVITE messages, namely the Pst-to header field. This
header field contains the SIP-URI of the device the media-stream will
be transferred to.
To inform the MN about which media-stream will be transferred and
with what media-parameters, the INVITE message meant as proposal
contains a SDP-body. This SDP-body contains a session description
proposal that will be sent to the CN when re-invited. By analyzing
this session description and comparing it with the previous session
description being offered to the CN, it knows which media-stream is
being transferred, and what media-parameters will be used. Figure 4
contains an example of the SDP-proposal sent to the MN; the MN
compares it to the last SDP session description it sent to the CN,
shown in Figure 3. The MN can determine which media-stream will be
transferred by looking at the Connection parameter; the media-stream
that is being transferred uses another connection parameter.
c=IN IP4 192.0.2.1
m=audio 24224 RTP/AVP 0 3 4 5 16 6 17 14 8 15 18
m=video 24222 RTP/AVP 34 26 31 33
Figure 3: SDP session setup
c=IN IP4 192.0.2.1
m=audio 24224 RTP/AVP 0 3 4 5 16 6 17 14 8 15 18
c=IN IP4 192.0.2.2
m=video 25222 RTP/AVP 34 26 31 33
Figure 4: SDP proposal
A new header field is added to the SIP INVITE message to inform the
MN about the Call-id of the sub-session that will be set up with the
target device of the transfer. The header containing this Call-id is
called Pst-call-id.
SSC might know all capabilities in advance, so it can invite the LD
and CN more precisely. If it does not, it invites the LN without any
SDP.
The order in which the involved nodes are invited is important to the
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 9]
Internet-Draft Method for network initiated PST February 2007
compatibility with SIPUAs. To make sure as much SIPUAs are supported
as possible old media-streams first has to be stopped before new
media-streams are being set-up as also described in [aartsetuijn06].
However this does mean a disruption in the media-streams. Figure 1
also illustrates this order by first inviting the MN (1) making sure
the MN stops sending audio to the CN, then inviting the CN (4) making
sure the CN stops sending audio to the MN and starts sending audio to
the AN, and only after that inviting AN to let it send audio to CN.
This sequence also makes sure multiple sources are not sending the
media at the same time to the same endpoint.
3.4. Retrieval of a media-stream
Retrieval of a media-stream can be initiated from both the terminal
and network. In case the media-stream was transferred by the
terminal, it can also easily be retrieved by the terminal as
described in paragraph 5.3.2 of [shacham06]. If a media-stream was
transferred by the SSC, the SSC can transfer the media-stream back to
the MN by starting a network initiated partial session transfer.
When the SSC has transferred a media-stream, and the MN wants to
retrieve that media-stream, the MN knows about the transferred media-
stream because it was informed by the proposal (INVITE-message) sent
by the SSC. Because it has an up-to-date view on the current
situation it is able to determine if a retrieval is necessary, and
how it should be accomplished. Figure 5 shows the sequence diagram
of this, where the MN only has to re-invite the CN to retrieve the
audio-stream. Here the SSC does have the responsibility (As
described in section Section 7) to make sure the sub-session with the
AN is consistent with the session between the MN and CN.
AN MN SSC CN
| | (1) INVITE | |
| |---------------------------------->|
| | (2) 200 OK | |
| |<----------------------------------|
| | (3) ACK | |
| |---------------------------------->|
| | RTP Audio | |
| |<..................................|
| | | |
| (4) BYE | | |
|<---------------------------------------| |
| (5) OK | | |
|--------------------------------------->| |
| | | |
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 10]
Internet-Draft Method for network initiated PST February 2007
Figure 5: Retrieval by Mobile Node
The other way arround, where the MN has transferred a media-stream,
and the SSC intends to transfer that media-stream back to the MN, the
SSC must have an up-to-date view on the current situation. Because
the SSC acts as a B2BUA on every session that is related to the MN,
it is able to process all changes made in the session(s). This way
the SSC always has an up-to-date view of the current situation.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 11]
Internet-Draft Method for network initiated PST February 2007
4. 'pst-control' option-tag
A new SIP option-tag called 'pst-control' is defined for the Require
and Supported header fields.
A user agent including the 'pst-control' option-tag in a header field
indicates compliance with this specification.
This 'pst-control' option-tag may be included in the Require header
field of re-INVITE's sent by a B2BUA. Nodes controlled by end-users
should not use this option-tag in the Require header field.
A B2BUA that wants to propose a partial session transfer to a certain
node for a specific call must include the 'pst-control' option-tag in
the Require field of the re-INVITE message that represents the
proposal.
When the 'pst-control' option-tag is present in an INVITE request, it
also MUST contain a Pst-to header field and a Pst-call-id header
field.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 12]
Internet-Draft Method for network initiated PST February 2007
5. The Pst-to header field
The Pst-to header field can appear in INVITE requests where the 'pst-
control' option-tag has been set. This field contains the SIP-URI of
the device the media-stream will be transferred to. The following is
the ABNF (augmented Backus-Naur Form) for the Pst-to header field:
Pst-to = "Pst-to" HCOLON ( name-addr / addr-spec ) * (SEMI generic-
param)
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 13]
Internet-Draft Method for network initiated PST February 2007
6. Pst-call-id header
The Pst-call-id header field can appear in INVITE requests where the
'pst-control' option-tag has been set. This field contains the
call-id of the sub-session that will be set up with the device
identified by the Pst-to header field. The following is the ABNF
(augmented Backus-Naur Form) for the Pst-call-id header field:
Pst-call-id = "Pst-call-id" HCOLON callid
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 14]
Internet-Draft Method for network initiated PST February 2007
7. Behaviour of SSC
When the SSC wants to offer a partial session transfer to a user, it
sends an INVITE request to the MN containing the 'pst-control'
option-tag in the Required header, the Pst-to header field to
indicate the targer of the transfer, the Pst-call-id header field to
identify the sub-session being set up with the target device and the
SDP-body to indicate what stream is being transferred and what the
parameters of it are after the transfer.
In case the SSC recieves a 306 response (Decline), meaning the MN
does not want the proposed partial session transfer to be executed,
the SSC does not continue with the execution. When the MN does not
support pst-control it will respond with a 420 response (Bad
Extension), while the Unsupported header field contains the 'pst-
control' option-tag. The behaviour of the SSC in case the MN does
not support pst-control is implementation specific. The SSC could
for example use user preferences to determine if it should continue
or stop the execution of the partial session transfer.
Besides a network initiated partial session transfer, a partial
session transfer can also be initiated by the user-terminal. This
influences the way how the sub-sessions are handled and by which node
they are handled. In case the MN supports pst-control, the node that
made the last change to a sub-session is responsible for that
specific sub-session. This responsibility consists of making sure
the sub-session is consistent with the session between the MN and CN.
In case the MN does not supports pst-control, the SSC is always
responsible for the sub-sessions.
Because the SSC act as a B2BUA that is located in the signalling path
of all sessions between the device that acts as MN and it peers, it
receives all messages of the involved nodes and must interpet them
and make sure these messages are forwarded to other nodes
accordingly. As described above, if the SSC is responsible for a
certain sub-session it must make sure the sub-session remains
consistent with the session between the CN and MN. This includes
changes to a sub-session by the involved LN, where the SSC must make
sure the sub-session and session between the MN and CN remains
consistent. The exact behaviour necessary is considered
implementation specific.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 15]
Internet-Draft Method for network initiated PST February 2007
8. Behaviour when receiving INVITE with 'pst-control' in Require header
When a node receives an INVITE message with the option tag 'pst-
control' in the Required header according to SIP [RFC3261] it should
only process the message further if it supports the specified
extension. In case it does not supports this extension it response
with a 420 response (Bad Extension).
In case the receiving node does support the extension it can decline
(306 response) or accept (200 response) the proposed partial session.
Which one applies depends should depend on what the user wants. This
could for example mean user-interaction is necessary before the
proposal is accepted or decline.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 16]
Internet-Draft Method for network initiated PST February 2007
9. Security Considerations
All security considerations as described in [shacham06] also apply
for this proposal. Besides those considerations here some other are
described that are related to network initiated partial session
transfers.
9.1. Sender of proposal can be any node in the signalling path
The INVITE send to the MN to propose a partial session transfer can
virtually be send by any node in the signalling path of a certain
session.
9.2. Sudden disconnection of the MN
In case a media-stream has been transferred to a LN and the MN
suddenly disconnects, that specific media-stream does not stop
working; it only stops when the LN or CN disconnects, or the LN, CN
or SSC uses signalling to stop the media-stream. The proposed method
does not contain a mechanism to register sudden disconnects, so one
of the involved nodes can take appropriate actions.
9.3. MN is informed about the existence of a LN
In case of a network initiated partial session transfer, the MN is
informed about the existence of the involved LN at the moment it
receives the proposal for the partial session transfer (At (1) in
Figure 1. It is the task of the SSC to make sure a LN is only
exposed to nodes that are trusted. No mechanism has been defined for
this.
9.4. LN is informed about the IP-address of the CN
At the moment the MN accepts a transfer, the involved LN is informed
about the IP-address of the CN to inform the AN to send or receive
media from the CN (At (9) in Figure 1). The CN might not want other
nodes beside the MN to know about its IP-address.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 17]
Internet-Draft Method for network initiated PST February 2007
10. IANA Considerations
Section 27 of RFC 3261 [RFC3261] creates an IANA registry for method
names, header field names, warning codes, status codes, and option
tags. This specification defines two new SIP header fields and a SIP
option tag.
10.1. Pst-to and Pst-call-id headers
This document defines two new SIP header fields: Pst-to and
Pst-call-id. These header fields needs to be registered by the IANA
in the SIP Parameters registry under the Header Field subregistry
10.2. Option Tag
This section defines a new option tag per guidelines in Section 27.1
of RFC 3261 [RFC3261].
Name: pst-control
Description: This option tag is used to identify support for client
control of network initiated partial session transfers. When present
in a Supported header field, it indicates that an agent supports
controlling a network initiated partial session transfer.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 18]
Internet-Draft Method for network initiated PST February 2007
11. Acknowledgements
The work described in this Internet-Draft is based on results of IST
FP6 Integrated Project DAIDALOS. DAIDALOS receives research funding
from the European Community's Sixth Framework Programme. Apart from
this, the European Commission has no responsibility for the content
of this Internet-Draft. The information in this document is provided
as is and no guarantee or warranty is given that the information is
fit for any particular purpose. The user thereof uses the
information at its sole risk and liability.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 19]
Internet-Draft Method for network initiated PST February 2007
12. Normative References
[3GPP 23.228]
3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2),
Release 7", December 2005.
[3GPP 23.279]
3GPP, "TS 23.279: Combining Circuit Switched (CS) and IP
Multimedia Subsystems (IMS) services, Release 7",
December 2006.
[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.
[RFC4566] Handley, M., Jacobsen, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[aartsetuijn06]
Aartse Tuijn, J., "Partial session mobility in context
aware IP-based multimedia subsystems", december 2006.
[shacham06]
Shacham, R., Schulzrinne, H., Thakolsri, S., and W.
Kellerer, "Session Initiation Protocol (SIP) Session
Mobility", November 2006.
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 20]
Internet-Draft Method for network initiated PST February 2007
Authors' Addresses
Jasper Aartse Tuijn
University of Twente
Calslaan 1-309
Enschede 7522MH
The Netherlands
Email: j.aartsetuijn@student.utwente.nl
Dennis Bijwaard
Alcatel-Lucent
Capitool 5
Enschede 7521PL
The Netherlands
Email: bijwaard@alcatel-lucent.com
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 21]
Internet-Draft Method for network initiated PST February 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).
Aartse Tuijn & Bijwaard Expires August 30, 2007 [Page 22]
