Internet DRAFT - draft-jesske-sipping-tispan-analysis
draft-jesske-sipping-tispan-analysis
Analysis of TISPAN req. to SIP June 2005
Sipping Working Group
Internet Draft Roland Jesske
Expires: December 28, 2005 Denis Alexeitsev
Deutsche Telekom
Miguel Garcia-Martin
Nokia
June 2005
Analysis of the Input Requirements for the Session Initiation
Protocol (SIP) in support for the European Telecommunications
Standards Institute (ETSI) Next Generation Networks (NGN) simulation
services
draft-jesske-sipping-tispan-analysis-00.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 November 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Jesske Expires - December 2005 [Page 1]
Analysis of TISPAN req. to SIP June 2005
This document analyzes the requirements generated by ETSI to support
NGN simulation services implemented with SIP. The document analyzes
standard solutions that can meet the requirements. Where a standard
solution is not available, the document proposes one or more
solutions. The aim is to provoke discussion within the Internet
community and get early feedback.
Table of Contents
1. Overview
2. Analysis of the TISPAN Simulation Services requirements
2.1 General Requirements[REQ-GEN-1]
2.2 Anonymous Communication Rejection (ACR)[ACR-REQ-1] and [ACR-
REQ-2]
2.3 Terminating Indication Presentation (TIP)/Terminating
Indication Restriction (TIR). [REQ-TIP-1] and [REQ-TIP-2]
2.4 Advice of Charge (AOC) [REQ-AoC-1] and [REQ-AoC-2]
2.5 Communication Completion on Busy Subscriber (CCBS) [REQ-CCBS-
1]- [REQ-CCBS4]
2.6 Communication Completion on no Reply (CCNR) [REQ-CCNR-1]-
[REQ-CCBNR4]
2.7 Malicious Communication IDentification (MCID) [REQ-MCID-1] and
[REQ-MCID-2]
2.8 Communication Waiting (CW) [REQ-7] [REQ-CW-1] and [REQ-CW-2]
2.9 Communication Diversion (CDIV) [REQ-CDIV-1] and [REQ-CDIV-4]
2.10 [REQ-CAT-1] and [REQ-CAT-2]
3. Security Considerations
4. IANA Considerations
1. Overview
This document is a companion document of the Internet Draft
"Input Requirements for the Session Initiation Protocol (SIP) in
support for the European Telecommunications Standards Institute
(ETSI) Next Generation Network (NGN) simulation services" [3]. We
analyze each requirement trying to find an available standard
solution that meets the requirement. When such solution is not known,
we analyze different alternatives that will meet the requirement. The
document's intention is to provoke discussion in the Internet
community in order to find suitable mechanisms that guarantee the
implementation of the requirements within the ETSI NGN timeframe.
2 Analysis of the TISPAN Simulation Services reqirements
The following section could be seen as collected thoughts what
possibilities are given to fulfill the above mentioned requirements.
Jesske Expires - December 2005 [Page 2]
Analysis of TISPAN req. to SIP June 2005
Some of these ideas are still under discussion in ETSI and thus, do
not even represent a firm proposal, but just a collection of
alternatives that require further exploration.
2.1 General Requirements[REQ-GEN-1]
This requirement, since it is generally applicable to all the
requirements, does not require a particular behavior. However,
solutions that meet other requirements should also meet the
constraint of seamlessly interwork with a similar service in the
PSTN.
2.2 Anonymus Communication Rejection (ACR)[ACR-REQ-1] and [ACR-REQ-2]
Requirement [ACR-REQ-1] requires informing the caller that her call
has been rejected due to anonymity. We thought that an application
server that implements the ACR service can either send an instant
message to the caller (if supported) or divert the call to an
announcement player that plays the appropriate audio message,
however, this will be hard to be processed by an automata or a PSTN
gateway. For example, in a PSTN originated call the PSTN should
indicated an appropriate Release Cause (cause 24) due to interaction
with the ACR service. Thus, any solution based on these two proposals
would make difficult to meet REQ-GEN-1. The Release Causes are
described within ETSI EN300 485 [13]
A more sophisticated solution proposes to add a Reason header with an
appropriate Release Cause 24 as described in ETSI EN300 485 [13] to a
603 Decline response. This will allow interworking with the PSTN. Yet
another alternative is to create a new response code, but we believe
it is not really necessary to go into that solution.
As the current Reason header extension header is limited to requests,
some extension is needed to state that the Reason header is valid for
either the 603 (Decline) response, or some other status code as
determined by this discussion.
Requirement [ACR-REQ-2] reads about allowing certain authorized
callers to bypass the ACR service of a given callee. For that we
envision that an application or SIP proxy server that has access to
the caller's user profile is able to add indicate in SIP that the
user is authorized to bypass a potential callee's ACR service. We
propose to add a new P-ACR header field that proxies or application
servers can insert. This header would be subject to the same security
concerns and trusted domain considerations as the P-Asserted-Identity
header field [8].
2.2.1 The P-ACR header field
Jesske Expires - December 2005 [Page 3]
Analysis of TISPAN req. to SIP June 2005
In support for the ACR service [REQ-ACR-2], there is a need to
indicate that in some circumstances the ACR service provided towards
the terminating UE should not apply.
One of these cases is when the originating user has requested privacy
of his asserted identity, but because the user belongs to an
authorized group (e.g., policeman), all SIP request should go through
to the called UA, no matter whether the called user has activated ACR
or not.
In another scenario, a PSTN originated call does not deliver the
asserted identity of the called party (e.g., if the call is
originated in an analogue switch). In this case the PSTN gateway is
not able to provide an asserted identity of the calling party. If the
call is routed to a user who has the ACR service activated, the call
shouldn't be rejected due to ACR.
To tackle this problem we suggest creating a new P-ACR header, which
can be populated by a trusted entity (e.g., an Application Server or
Media Gateway Control Function). The contents of the header will
indicate that willingness of bypassing a potential ACR service in the
called party side, and the motivation for it.
It is the same restrictions for the P-ACR as in RFC3325 for the P-
Asserted-ID described must apply.
Proposed syntax for this header:
P-ACR = "P-ACR" HCOLON p-acr-spec
*(COMMA p-acr-spec)
p-acr-spec = "bypass" *(SEMI due-to-param)
due-to-param = "due-to" EQUAL reason-token
reason-token = "interworking" / "is-authorized" / "network"/
token
Example: P-ACR = bypass;due-to=is-authorized
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-ACR adr - - - o - -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o - o - - -
MESSAGE PUBLISH
--- ---
Jesske Expires - December 2005 [Page 4]
Analysis of TISPAN req. to SIP June 2005
o o
The draft-ietf-sip-identity was not considered due to the fact that
this draft recommends practices and conventions for identifying end
users in SIP messages, and proposes a way to distribute
cryptographically-secure authenticated identities. This is only for
Requests specified. The P-ACR is especially used for indicating
bypass mechanisms for ACR and the indication how P-Asserted-Identity
was set.
2.3 Terminating Indication Presentation (TIP)/Terminating Indication
Restriction (TIR). [REQ-TIP-1] and [REQ-TIP-2]
The implementation of these requirements need some header to convey
the callee's URI, which might be different from the To header field
or Request-URI, due to, e.g., redirections, call transfer, usage of
PBX extensions, etc.
We believe that the P-Asserted-Identity [8] header field inserted in
responses meets these requirements.
An additional Identity header is needed that is send from the
connected SIP user like the From header from the originating user.
2.3.1 The P-Additional-Identity Header
The P-Additional-Identity header field is used among SIP entities
(typically intermediaries) to carry the identity of the user
sending a SIP response as it was not verified by authentication.
This additional header is needed for example a user calling a PBX
desk (e.g., +49 6151 83 0000 for Deutsche Telekom in Darmstadt) will
be forwarded to an Extension (e.g., +49 6151 83 5940 for Roland
Jesske). It is required that the caller gets the latter identity,
which is allocated to the callee.
PAdditionalID = "P-Additional-Identity" HCOLON PAdditionalID-value
*(COMMA PAdditionalID-value)
PAdditionalID-value = name-addr / addr-spec
A P-Additional-Identity header field value MUST consist of exactly
one name-addr or addr-spec. There may be one or two P-Additional-
Identity values. If there is one value, it MUST be a sip, sips, or
tel URI.
If there are two values, one value MUST be a sip or sips URI and the
other MUST be a tel URI. It is worth noting that proxies can (and
will) add and remove this header field.
This document adds the following entry to Table 2 of [1]:
Jesske Expires - December 2005 [Page 5]
Analysis of TISPAN req. to SIP June 2005
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
P-Additional-Identity r adr - o - o o -
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o - - -
MESSAGE PUBLISH
--- ---
o o
Note: Here is also an ongoing discussion if a new header is needed or
if a existing header could be used to identify the ôrealö connected
user. The Contact or Reply-to header were identified as not usable.
2.4 Advice of Charge (AOC) [REQ-AoC-1] and [REQ-AoC-2]
The Advice of Charge simulation service requires a caller to give an
indication to the network that he wants to receive advice of charge
information for a given communication (e.g., session, subscription,
instant message, etc.). A mechanism to invoke the service based on a
SIP-event base subscription and notification has been analyzed.
However, this solution will introduce a synchronization problem, due
to indicating the request for the service out-of-band. The basic
problem is how to identify the SIP request for which the advice
should be provided prior to sending the request, when such request
has not even been created.
We propose, though, that the SIP request for which the Advice of
Service information is requested is complemented with a new header
that invokes the service. Once the service is properly invoked, there
are a number of available mechanisms to deliver the information to
the user, including but not restricted to, audio visual
announcements, instant message, etc.
A detailed proposal for a new P-AoC header field is described in
draft-garcia-sipping-etsi-ngn-p-headers-00 [7].
2.5 Communication Completion on Busy Subscriber (CCBS) [REQ-CCBS-1]to
[REQ-CCBS4]
Discussion in ETSI TISPAN are leaning towards a segmented
implementation of the CCBS service, where there is an application
server which is serving the caller, and another application server
which serving the callee. The main role of application servers is to
Jesske Expires - December 2005 [Page 6]
Analysis of TISPAN req. to SIP June 2005
provide queue management. This is based on the modelling in the ISDN
stage 2 and operates in this manner to allow interworking with the
related ISDN service through a SIP/PSTN gateway.
We model the actual implementation of the CCBS service according to
the following:
- When the AS of the callee detects that the callee is busy and that
the callee supports the dialog event package [9], it forwards the
busy response to the AS of the caller with an indication that the
CCBS service is possible (i.e. queuing capabilities, and dialog event
are supported, REQ-CCBS-1 and REQ-CCBS-2).
- Upon receipt of this indication, the caller is offered to activate
the CCBS service (e.g. the AS of the caller plays an announcement
with DTMF collection, etc).
- If the caller accepts the service activation, the AS of the caller
subscribes to the CCBS service (e.g. subscribes to the CCBS queue of
the callee to the dialog status of this callee, REQ-CCBS-2).
- Upon receipt of the CCBS subscription request, the AS of the caller
confirms that CCBS monitoring has started,
- the AS of the callee then subscribes to the dialog event [9] of the
callee,
- Upon receipt of a notification that the callee is free, the AS of
the callee, notifies the AS of the caller.
- The AS of the caller sets-up the CCBS call using either a 3rd party
control mechanism of a Refer with an indication that this is a CCBS
call (REQ-CCBS-4).
In order to provide compatibility with terminals that implement the
dialog event package, subscriptions that may originate or terminate
in a terminal will be implemented according to the dialog event
package [9].
Subscriptions not involving terminals (i.e., such as the
subscriptions from one application server to another one) need to be
complemented with additional information (REQ-CCBS-3). It is proposed
to define a new "CCBS" event package for backwards compatibility
purposes. The main difference between the "CCBS" event package and
the ôdialogö event package lies in the way subscriptions and
notifications are handled, there is no need to change the contents of
the XML documents exchanged therein. Consequently, the CCBS event
package notifications should contain a dialog information document as
described in [9]. This allows to "tunnel" dialog information
documents contained in dialog package notifications originated by
endpoints into CCBS package notifications sent by application
servers. The additional information to the dialog event package for
providing queues management and concurs to build a subscription
target is as follows:
Jesske Expires - December 2005 [Page 7]
Analysis of TISPAN req. to SIP June 2005
queue: this information is needed for the application server to know
whether to insert this new subscription in the queue or not. We
suggest to add a new "queue" parameter to the "dialog" Event header
field value. Possible values are "true","false", "suspend" (to
suspend its place in queue), "resume" to resume its place in queue.
Hence, the CCBS Event: header will look like, for example
To start CCBS subscription:
Event: ccbs;queue=true;caller=sip:+390112285111@example.com
To suspend CCBS service (for instance, if caller becomes busy):
Event: ccbs;queue=suspend;caller= sip:+390112285111@example.com
To resume CCBS service:
Event: ccbs;queue=resume;caller= sip:+390112285111@example.com
A value of "ccbs" or "dialog" in the 486 Busy Here response will
indicate the URI where the subscription could be made. This URI
could, e.g., a GRUU. Additionally, the presence in a 486 Busy Here
response of an Allow-Events header field with the value "CCBS" would
help to determine the support for the service. However, RFC 3265 [11]
seems to indicate that the Allow-Evens header is only meaningful in
requests and 200 or 489 responses.
Implementation of REQ-CCBS-3 requires that the second time that the
caller sends the INVITE request to the callee, as a result of an
indication that the callee is not busy any longer, the INVITE request
is marked with an flag indicating that the INVITE is the result of
CCBS service. It is proposed that a Call-Info header field is
extended with a new value of the "purpose" parameter. Hence, at the
time of the CCBS call, the AS can insert the Call-Info: header into
the INVITE message directed to user B when triggering the 3rd party
call, or instruct the terminal to do so in the Refer-To: header
inserting the æCall-Info:Æ header as a URL header (after the æ?Æ
character).
Note: With regard to CCBS the discussion is ongoing what kind of
solution could be taken. If a new Event Package is needed or if the
extension of the existing dialog event package is good enough for
CCBS.
2.6 Communication Completion on no Reply (CCNR) [REQ-CCNR-1] to
[REQ-CCNR-4]
Jesske Expires - December 2005 [Page 8]
Analysis of TISPAN req. to SIP June 2005
The implementation of the CCNR service does not require any extra
implementation beyond the solutions proposed for implementing the
CCBS service.
2.7 Malicious Communication IDentification (MCID) [REQ-MCID-1] and [REQ-
MCID-2]
The implementation of the MCID service suggests to split the solution
into the mechanism whereby a callee can indicate to an application
server that he suspects a call is malicious [REQ-MCID-1], from the
mechanism whereby an application server acquires the caller's
identity if not present in the SIP request [REQ-MCID-2].
A possible solution for implementing REQ-MCID-1 consists of the user
subscribing to a new event package. The application server will act
as a notifier. Since the user does not need to receive any
information, other than a message indicating whether the service has
been successfully activated or not, we propose to do a fetch
operation (as per RFC 3265 [11]) with the new event package.
We propose, therefore, a new event "mcid" event package. The value is
accompanied by package parameters indicating the call to be
identified (e.g., by its from-tag, call-id, and to-tag (if
available)). The event package itself should contain a simple
indication of the acceptance or not of the service.
To implement REQ-MCID-2 we envision that all SIP requests addressed
to the user will be routed through the MCID application server. The
application server will analyze all SIP requests. Two possbilities
might take place: the SIP request contains trusted identity
information (e.g., a trusted P-Asserted-Identity [8] header field, or
an Identity [12] header field); or such identity is not present in
the request, in which case, it might be still available upon request.
This is the sometimes the case when a call is originated in the PSTN,
because sometimes the calling party number is only available upon
request.
To meet this requirement and be able to request the identity of the
originator, we propose a SIP event package for requesting identity
information. In most cases this will not be used, but in cases of
interworking with the PSTN, the PSTN gateway will receive a SUBSCRIBE
request for the new event package, will do the PSTN operations to
retrive the calling party number, and will provide the appropriate
notification to the subscriber (the application server).
2.8 Communication Waiting (CW) [REQ-CW-1] and [REQ-CW-2]
Jesske Expires - December 2005 [Page 9]
Analysis of TISPAN req. to SIP June 2005
A solution that meets REQ-CW-1 suggests to use send an instant
message indicating the ser the relevant parameters of the waiting
call.
To implement REQ-CW-2 we suggest to use a 182 Queue response until
the callee accepts the incoming session.
2.9 Communication Diversion (CDIV) [REQ-CDIV-1] to [REQ-CDIV-4]
For supporting CDIV service we envision the usage of draft-ietf-sip-
history-info-06 [6] and draft-elwell-sipping-redirection-reason-01
[2].We therefore request the adoption of draft-elwell-sipping-
redirection-reason as a working group charter item.
2.10 [REQ-CAT-1] and [REQ-CAT-2]
To support REQ-CAT-1 and REQ-CAT-2 we propose that, a PSTN Gateway
(UA) or SIP proxy that has knowledge of the user's category inserts a
P-Caller-Category header field categorizing the caller.
Sometimes the category of the caller is determined to be "operator".
In such case, the presence of the Accept-Language header field can be
combined to determine the language of the operator.
Use of this mechanism in any other context has serious security
shortcomings, namely that there is absolutely no guarantee that the
information has not been modified, or was even correct in the first
place.
The proposed syntax for this header:
P-Caller-Category = "P-Caller-Category " HCOLON p-cat-spec
*(COMMA p-cat-spec)
p-cat-spec = "operator" / "subscriber" / "data" /
"test" / "payphone" / "mobile" / token
Example: P-Caller-Category = "payphone"
An other possibility is to use the solution described within draft-
mahy-iptel-cpc-00 [14]. This solution was dicussed in the past within
IPTEL but not follwed on
Question is which would be the appropriate way to follow.
4. Security Considerations
Jesske Expires - December 2005 [Page 10]
Analysis of TISPAN req. to SIP June 2005
The requirements in this document are intended to result in a
mechanism with applicability for ETSI NGN and NOT for the general
Internet.
Use of this mechanism in any other context has serious security
shortcomings, namely that there is absolutely no guarantee that the
information has not been modified, or was even correct in the first
place.
5. IANA Considerations
This document discusses implementation possibilities and does not
pretend to be a firm proposal for the implementation of any of the
solutions. Therefore, this document does not provide any action to
IANA.
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] Elwell, J., "SIP Reason header extension for indicating
redirection reasons", draft-elwell-sipping-redirection-reason-
02.txt (work in progress), June 2005.
[3] Jesske, R., Alexeitsev, D., Garcia-Martin, M. "Input Requirements
for the Session Initiation Protocol (SIP) in support for the
European Telecommunications Standards Institute (ETSI) Next
Generation Network (NGN) simulation services", draft-jesske-
sipping-tispan-requirements-01.txt (work in progress), June 2005.
[4] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP
and SDP".
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[6] Barnes, M., "An Extension to the Session Initiation Protocol for
Request History Information", draft-ietf-sip-history-info-06.txt
(work in progress), January 2005.
[7] Garcia-Martin, M. "Private Header (P-Header) Extensions to the
Session Initiation Protocol(SIP) in support of the European
Telecommunications Standards Institute (ETSI) Next Generation
Networks (NGN)", draft-garcia-sipping-etsi-ngn-p-headers-00.txt
(work in progress), June 2005.
Jesske Expires - December 2005 [Page 11]
Analysis of TISPAN req. to SIP June 2005
[8] Jennings C., Peterson J., and Watson M. "Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
[9] Rosenberg, J., Schulzrinne, H., Mahy, R"An INVITE Initiated
Dialog Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-dialog-package-06.txt (work in progress), April
2005.
[10] Rosenberg, J. "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-
ietf-sip-gruu-03 (work in progress), February 2005.
[11] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[12] Peterson, J., Jennings, C. "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-05.txt (work in progress), March 2005.
[13] ETSI EN 300 485: "Integrated Services Digital Network (ISDN);
Definition and usage of cause and location in Digital Subscriber
Signalling System No. one (DSS1) and Signalling System No. 7 (SS7)
ISDN User Part (ISUP) [ITU-T Recommendation Q.850 (1998) with
addendum modified]".
[14] R. Mahy "The Calling Party's Category tel URI Parameter" draft-
mahy-iptel-cpc-00, June 2003
Contributors
Keith Drage
Lucent Technologies
SN5 6PP SWINDON
United Kingdom
Phone: +44 1793 897312
Email: drage@lucent.com
Sebastien Garcin
France Telecom
38-40, Rue du General Leclerc
92130 Issy Les Moulineaux
France
Acknowledgments
Jesske Expires - December 2005 [Page 12]
Analysis of TISPAN req. to SIP June 2005
The authors would like to thank the participants of the ETSI TISPAN
WG3 for the comments and initial review of this document.
Author's Addresses
Roland Jesske
Deutsche Telekom
Am Kavalleriesand 3
64307 Darmstadt
Germany
Phone: +496151835940
Email: r.jesske@t-com.net
Denis Alexeitsev
Deutsche Telekom
Am Kavalleriesand 3
64307 Darmstadt
Germany
Phone: +496151832130
Email: d.alexeitsev@t-com.net
Miguel A. Garcia-Martin
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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
Jesske Expires - December 2005 [Page 13]
Analysis of TISPAN req. to SIP June 2005
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jesske Expires - December 2005 [Page 14]
