SIMPLE WG O. Levin Internet-Draft Microsoft Corporation Expires: January 16, 2005 A. Houri IBM E. Aoki America Online, Inc. July 18, 2004 Inter-domain Requirements for SIMPLE draft-levin-simple-interdomain-reqs-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document identifies a SIP/SIMPLE profile for inter-domain communications and documents best current practices regarding security and "good citizenship" behavior that operators should use when interconnecting SIP/SIMPLE clouds. The purpose of this document Levin, et al. Expires January 16, 2005 [Page 1] Internet-Draft Inter-domain Profile for SIMPLE July 2004 is to serve as the reference for the SIP/SIMPLE community towards inter-domain interoperability and also to identify new requirements specific to the inter-domain interface. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology and Topology . . . . . . . . . . . . . . . . . . . 3 4. Connecting SIMPLE Communities . . . . . . . . . . . . . . . . 4 4.1 Configuration and Discovery . . . . . . . . . . . . . . . 4 4.2 Connection Management . . . . . . . . . . . . . . . . . . 5 4.3 Mutual TLS . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 SIP and SIMPLE Profile for Presence . . . . . . . . . . . 6 5.2 Presence Format . . . . . . . . . . . . . . . . . . . . . 6 5.3 Automatic Periodic Presence Operations . . . . . . . . . . 7 5.3.1 Ensuring User Validity . . . . . . . . . . . . . . . . 7 5.3.2 Ensuring Presence Validity . . . . . . . . . . . . . . 7 6. Instant Messaging (IM) . . . . . . . . . . . . . . . . . . . . 8 6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2 Page IM . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3 Session IM . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3.1 MSRP . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3.2 MESSAGE inside INVITE Session . . . . . . . . . . . . 9 7. SIP Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 10 8. Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Requirements for Standard Extensions . . . . . . . . . . . . . 11 9.1 Recording and Logging . . . . . . . . . . . . . . . . . . 11 9.2 Inter-community User Trust Level . . . . . . . . . . . . . 12 9.3 Add/Remove Contact . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 10.1 Spam Prevention . . . . . . . . . . . . . . . . . . . . . 13 10.2 Federated Contacts Accuracy . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 13.2 Informational References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 18 Levin, et al. Expires January 16, 2005 [Page 2] Internet-Draft Inter-domain Profile for SIMPLE July 2004 1. 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 RFC-2119 [1]. 2. Introduction With increased adoption of SIP and SIMPLE based presence and instant messaging systems, it becomes more important to specify a uniform profile these systems will use to exchange presence information and instant messages (IMs) and to document best current practices regarding security and "good citizenship" behavior that operators should use when interconnecting SIP/SIMPLE clouds. The purpose of this document is not to become a normative profile but rather to serve as the reference for the SIP/SIMPLE community towards inter-domain interoperability and also to identify new requirements specific to the inter-domain interface. The document is structured into the following main sections: o Terminology and Topology o Connecting SIMPLE Communities o Presence o Instant Messaging o SIP Miscellaneous o Agreements o Requirements for Standard Extensions 3. Terminology and Topology For the purposes of this document, we consider users as "belonging" to a given SIMPLE presence and messaging community. A SIMPLE community administers its own namespace of SIP addresses or has other administrative authority over a collection of users and/or SIMPLE endpoints. The users of an enterprise, or the customers of a given service provider are examples of such communities. A typical deployment topology illustrating how two SIMPLE communities might interconnect is shown in the figure below. Levin, et al. Expires January 16, 2005 [Page 3] Internet-Draft Inter-domain Profile for SIMPLE July 2004 /\ /\ /U-A /U-B /____\ ----------- /____\ ///// \\\\\ _____ +-------+ // \\ +-------+ _____ / / | | | | | | / / /R-A / | EP-A | | Public Internet | | EP-B | /R-B / /____/ | | | | | | /____/ +-------+ \\ // +-------+ _____ \\\\\ ///// _____ / / ----------- / / /P-A / /P-B / /____/ /____/ The edge proxies (EP-A and EP-B) for a given community are SIP proxies that have both ability and authority to route traffic from the public network to the SIP entities within that community. Each edge proxy is said to "service", "be responsible for", "act on behalf of", or be "in" a community, which is to say that the edge proxy listens for requests intended for a given community (identified by its domain), routes the SIP traffic "to" and "from" the community, and in some cases provides answers on behalf of the users and entities within that community. The other components shown in the picture are logical SIP and SIMPLE entities internal to each community that participate in different aspects of presence and IM. They include UAs/PUAs (U-A and U-B), Registrars (R-A and R-B), and Presence Servers (P-A and P-B). This document is concerned with the protocols and deployment considerations of the "inter-domain interface" between two separately administered SIP clouds. Put another way, the inter-domain interface is the path between EP-A and EP-B, where traffic traverses the Public Internet. This path may optionally include a chain of SIP proxies for application routing in-between. 4. Connecting SIMPLE Communities 4.1 Configuration and Discovery When a user in a given SIMPLE community wishes to communicate with users in a different community, a route must exist between the sender's edge proxy (EP-A) and that of the destination (EP-B). To establish this route, an edge proxy needs to learn the Fully Qualified Domain Name (FQDN) of its peer proxy by means out-of-band to SIP. Levin, et al. Expires January 16, 2005 [Page 4] Internet-Draft Inter-domain Profile for SIMPLE July 2004 One means of discovery is the use DNS SRV records according to the procedures in RFC-3263 [5]. However, some communities may wish to implement more restrictive policy concerning other communities to whom their users may communicate. Accordingly, it is RECOMMENDED that local edge proxies have the ability to be statically provisioned with the list of valid DNS domains to which they may connect. These are the DNS domains that the remote edge proxy has the authority and the ability to route to. 4.2 Connection Management Connections between messaging communities SHOULD use TCP for transport. These connections are bi-directional, semi-persistent, and are established on-demand by either edge proxy. For large communities many thousands or millions of dialogs may be occurring concurrently. Consequently, it would likely not be appropriate for a community to establish one connection per SIP dialog. Data for multiple SIP dialogs can and will likely flow across a given connection. Conversely, the requests and responses that make up a given dialog may flow over any active connection that exists between the two SIMPLE communities and is not guaranteed to flow over the same connection as preceding requests. If a connection fails or closed by either side due to a locally defined inactivity period, each side can initiate new TLS connection(s) at any time. Although SIMPLE communities may establish more than one connection to communicate with other, in consideration of scalability, implementers are RECOMMENDED to limit the number of such connections to a reasonably small number. In any event, the receiving community's edge proxy MAY refuse to accept more than a given number of connections from a given edge proxy or from all of the edge proxies that reside within a given community. 4.3 Mutual TLS In order to prevent spoofing and to provide better control against spam, SIMPLE communities SHOULD require the use of a mutually authenticated TLS connection between the edge proxies. A community MAY reject non-TLS traffic altogether. According to the TLS protocol RFC-2246 [2], for establishment of the mutually authenticated TLS connection, each server needs to present a valid certificate to the other server. Each server also needs to trust the certificate authority that issued the certificate presented by the other proxy or trust the certificate itself. Once a TLS Levin, et al. Expires January 16, 2005 [Page 5] Internet-Draft Inter-domain Profile for SIMPLE July 2004 connection is established between two edge proxies, it is trusted for the life of the connection. As indicated in the preceding section, between two edge proxies, one or more connections can be simultaneously maintained. If a group of TLS connections is maintained between the two edge proxies, the same certificate MUST be used for all connections servicing a given community. This allows the randomization of SIP dialogs among the TLS connections according to local policy and without requiring additional protocols between the communities. 5. Presence 5.1 SIP and SIMPLE Profile for Presence In order to get the presence information from a user in a different community, the standard SIP SUBSCRIBE/NOTIFY mechanism defined in RFC-3265 [7] is used. An edge proxy may receive SUBSCRIBE requests for presentities that do not exist within the community, for example, as a result of a mistyped contact name or the removal of a previously valid identity (e.g. enterprise user quits the company). Some presentities may also be restricted by local policy from communicating across communities. In these cases, the receiving community SHOULD reject the session by issuing one of the 4XX responses (e.g. "404 Not found" or "403 Forbidden") to SUBSCRIBE. If one of the 4XX responses is generated, it is strongly RECOMMENDED that the originating community does not automatically (i.e. without user intervention) retries the same SUBSCRIBE request again. A receiving edge proxy MAY alternately accept the SUBSCRIBE using a 2xx response and indicate in a subsequent NOTIFY that the presentity is not available (i.e. has "closed" status). A given community may wish to do this in order to prevent dictionary attacks to harvest valid presentity addresses. 5.2 Presence Format The basic presence format used between users in different communities is defined by Presence Information Data Format [11]. This standard format is signaled by including the "Accept" header with "application/pidf+xml" in the SUBSCRIBE as (at least) one of the possible presence formats the watcher understands. Any additional presence information MAY be exchanged over the inter-domain interface if encoded according to standard XML extension techniques. It is expected that the following additional standard Levin, et al. Expires January 16, 2005 [Page 6] Internet-Draft Inter-domain Profile for SIMPLE July 2004 user information is especially useful to be conveyed between SIMPLE communities: o "activity" element defined in Rich Presence Extensions [12]. o "icon" element defined in Contact Information [13]. o "display-name" element defined in Contact Information [13]. A PUA MUST be capable of receiving any XML extended schema, compliant with the standard, and gracefully ignore any extensions it doesn't understand. An example of a valid presence document is shown below: open on-the-phone sip:tom-pc@example.com Tom Jones 5.3 Automatic Periodic Presence Operations Some SIMPLE communities may reassert subscription requests or presence notifications without user intervention in order to provide a form of self-repair or to update stale data. 5.3.1 Ensuring User Validity An edge proxy MAY automatically periodically generate re-SUBSCRIBEs towards an external SIMPLE community (for example, in order to ensure contact accuracy). In the absence of any bilateral agreement between the administrative authorities for each community, subscriptions to the same URI MUST NOT occur more frequently than every two hours. 5.3.2 Ensuring Presence Validity An entity within a SIMPLE community MAY automatically periodically Levin, et al. Expires January 16, 2005 [Page 7] Internet-Draft Inter-domain Profile for SIMPLE July 2004 generate NOTIFYs towards an external SIMPLE community. In the absence of any bilateral agreement between the administrative authorities for each community, data refreshes within the same SUBSCRIBE dialog MUST NOT occur more frequently than every 10 minutes. This limitation doesn't apply to notifications about dynamic changes in users' state (for example, a user transitioning from an "open" to "closed" state). 6. Instant Messaging (IM) 6.1 General At the time of this writing, two major modes of IM are being used in networks: Page mode and Session mode. It is expected that the two modes will coexist in the future side-by-side in the same network: each mode optimized for and being used by different applications and potentially resulting in different user experiences. It is strongly RECOMMENDED that upon receiving a request to initiate a specific IM mode, if the requested UA either doesn't support the mode or is not willing to communicate by it, the UA responds with "488 Not Acceptable Here" with Warning header field value explaining why the offer was rejected and expressing the alternative IM mode by including its capabilities as specified in section 11.1 and 21.4.26 of RFC-3261 [4] and as shown for each mode specifically in the sections below. Since the Page mode is prevalent today, in case any IM mode is applicable to the originating application, it is RECOMMENDED that the application starts with the Page mode and, if rejected, retries with the session mode if it has been expressed in the capabilities of the remote application. Before establishing IM communications towards a remote UA, a UA MAY query its peer's IM capabilities using the SIP OPTIONS request specified in RFC-3261 [4]. 6.2 Page IM The Page mode IM is fully specified in RFC-3428 [8]. A UA that is willing to communicate using the page mode IM, responds to the OPTIONS request by including the Allow header with listing the MESSAGE as one of the methods it supports as shown in the example below: Levin, et al. Expires January 16, 2005 [Page 8] Internet-Draft Inter-domain Profile for SIMPLE July 2004 SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: ;tag=93810874 From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, MESSAGE Accept: application/sdp Supported: foo Content-Type: application/sdp Content-Length: 274 (SDP not shown) As described for presence, above, an edge proxy may receive MESSAGE requests for IM addresses that do not exist within the community or are restricted by local policy from communicating with other communities. In these cases, the receiving community SHOULD return a 4XX response (e.g. "404 Not found" or "403 Forbidden") to MESSAGE. If one of the 4XX responses is generated, it is strongly RECOMMENDED that the originating UA refrains from issuing additional MESSAGE requests within a reasonable timeframe. A receiving community MAY alternately return a 2xx response and fail to deliver the message. A given community may wish to do this in order to prevent dictionary attacks to harvest valid IM addresses. 6.3 Session IM 6.3.1 MSRP At the time of this writing, the Message Sessions Relay Protocol (MSRP) [10] is under definition. Once it is standardized, it will become a valid IM means over inter-domain links. 6.3.2 MESSAGE inside INVITE Session At the time of this writing, the only deployed session IM is the MESSAGE SIP method being sent inside INVITE SIP dialog. This is one of the possible behaviors described in Section 2 of RFC-3428 [8] and the ideas from the draft-ietf-simple-im-sdp-00 "Extensions for SIP Instant Message Sessions" by B. Campbell and J. Rosenberg from July 13th 2001. This mode has never been fully standardized. Concerns about streaming data inside the signaling path have been Levin, et al. Expires January 16, 2005 [Page 9] Internet-Draft Inter-domain Profile for SIMPLE July 2004 expressed in the past. Most objections were related to the SIP ability running over UDP. As this document recommends the use of TLS or TCP, "MESSAGE inside INVITE Session" mode can be used with proper data flow control for potentially significant traffic inside the SIP signaling path. The SIP session is established according to SIP RFC-3261 [4] and SDP "Offer-Answer Model" RFC-3264 [6] procedures. In order to establish the IM session, a client issues SIP INVITE with the SDP body containing (at least) the following m-line: m=message 5060 sip The "SIP URI" SHOULD be the value from the Contact header and MAY be omitted. The consequent MESSAGE methods RFC-3428 [8] are constructed and sent according to standard SIP rules for messages inside a SIP dialog as defined in section 12.2 of RFC-3261 [4]. The recipient's UA MUST ignore any headers and parameters in the MESSAGE that it doesn't understand. The recipient's UA MUST ignore any attributes and parameters in the SDP document that it doesn't understand. The recipient UA MUST reject all m-lines in the SDP document that it doesn't understand or doesn't support by using the standard SDP convention (i.e. by setting the "port" parameter in the m-line to "0"). The recipient's UA MUST ignore all INFO messages RFC-2976 [3] that it doesn't understand. A UA that is willing to communicate using the MESSAGE method inside SIP session, includes an SDP document with m=message 5060 sip when responding to OPTIONS and in "488 Not Acceptable Here" responses in the SDP format defined in section 9 of "Offer-Answer Model" RFC-3264 [6]. 7. SIP Miscellaneous SIP public proxies (i.e. those proxies through which a SIP message transits between edge proxies of SIMPLE communities) SHOULD preserve Levin, et al. Expires January 16, 2005 [Page 10] Internet-Draft Inter-domain Profile for SIMPLE July 2004 all SIP headers and parameters they don't understand. If the accumulated length of Record Route headers in incoming (from an inter-domain link) SIP request exceeds the local policy of the receiving community, the recipient SHOULD reject the session by responding with "513 Message Too Large" to the request. 8. Agreements Before connecting separately administrated SIMPLE communities, certain local procedures need to be implemented by each community in order to become a good global SIP/SIMPLE citizen. Each community also SHOULD take precautions in order to defend itself (both reactively and proactively) from potentially badly behaving other communities. This document describes a number of these best practices. However, many of these procedures are largely a matter of local policy and in many cases can not be enforced by communication protocols. Therefore, it is expected that many of the proposed solutions will be referred to and enforced by bilateral business agreements before enabling the inter-domain connection. Communities that attempt to communicate with another community in the absence of such an agreement MUST adhere to the provisions in this document, particularly those referenced in the security considerations section, below. 9. Requirements for Standard Extensions In describing the best practices and conventions for communicating between disparate SIMPLE communities, the authors have identified several additional areas worthy of potential standardization. These areas are listed here for discussion; as they become formalized, they will be described in future versions of this document. 9.1 Recording and Logging For each SIP session, during the establishment and renegotiation phase it MUST be possible by standard means to inform the participants that the session is going to be recorded or logged. The recording or logging party, during the session establishment or renegotiation, MUST have a standard means to inform the session participants about the operation to take place. Levin, et al. Expires January 16, 2005 [Page 11] Internet-Draft Inter-domain Profile for SIMPLE July 2004 9.2 Inter-community User Trust Level Each community is responsible for verifying the identities of its users. As verification can take different forms, we introduce the concept of "user trust". While related to authentication, user trust differs in that authentication provides assurance that a user with a given identity has provided proper credentials to authenticate himself into a system. User trust verifies that the user is authorized to use the identity. For example, in a system where participants can register using email addresses - these addresses may be used as one form of identity verification. The system may send an email message to the given identifier and wait for an email response to verify that the registrant is authorized to use the email account associated with that address. In another case, a service provider may employ an image test or obtain a credit card number to determine that a registrant is a person and not a software "bot". Accreditation systems may also play a role in establishing user trust. Because of the wide range of verification assertions (including, potentially the "null" assertion), and because it is possible that users in the same community are being verified by different means and are being consequently assigned a different trust level by their same community, it is REQUIRED that a "user trust level" be defined and standardized to convey this information to other trusted communities across the inter-domain link. The scope of "user trust level" terminology should cover presence exchange, call establishment, and page IM communications. Over the inter-domain link, it MUST be possible to convey per user the level of the "user trust" as considered by its own community. For communities that implement a single level trust policy across their users, the edge proxies MAY provide this indication. If the indication is not present, the federated users MAY be regarded as "non-trusted" by other communities. This technique will allow providing between good to decent user experience depending on the trust level of a watcher or of a communications' requestor. 9.3 Add/Remove Contact In the event a user is removed from its SIMPLE community, it MUST be possible (though not required) for the community to communicate this removal to the presentity's known watchers in external communities using standard means. Levin, et al. Expires January 16, 2005 [Page 12] Internet-Draft Inter-domain Profile for SIMPLE July 2004 Some communities require a watcher to obtain consent from a presentity before establishing a presence subscription, or to obtain consent from the recipient before a message can be sent. In order to support these kinds of communities, it MUST be possible for users to request these kinds of consent without actually establishing communication (i.e., without establishing a presence subscription or sending a message). This consent request will allow the recipient to validate the requesting user and consider adding him/her to the contact list and/ or accept communications and result in a better user experience for interacting with initially non-trusted users. 10. Security Considerations This document describes a number of requirements and best practices for interconnecting distinctly administered SIMPLE communities for the purpose of exchanging presence and instant messages. Because these inter-domain connections traverse the public Internet, it is especially important to be conscious of security in order to preserve user privacy and to take into account scalability and operational requirements for the network. In that vein, this entire document describes a number of practices that directly or indirectly relate to security, but in particular, section "Mutual TLS" describes specific tactics meant to defend against eavesdropping and man-in-the-middle attacks, and to provide for data integrity and other protections. Other sections describe conventions and techniques that can be used to mitigate the risk of DOS attacks and to prevent undue traffic over the network. It is important to note that this document primarily describes the interactions that take place over the inter-domain interface. Because these inter-domain connections exist between edge proxies and not directly between end-user UAs, issues surrounding the authentication of UAs internally or of securing intra-community traffic are considered out of scope. Nonetheless, each community is assumed to be responsible for its own internal security, and edge proxies are explicitly assumed to be authoritative and responsible for traffic originating within a community. 10.1 Spam Prevention Given the prevalence of spam in other communications media, it deserves special consideration. Spam is defined in this case as unsolicited presence requests and instant messaging traffic and sent from an inter-domain link to a recipient unwilling to process this traffic. Levin, et al. Expires January 16, 2005 [Page 13] Internet-Draft Inter-domain Profile for SIMPLE July 2004 The SIP and Spam [14] document discusses many techniques that can be used to reduce spam with their advantages and disadvantages. This document concentrates on technologies that are deployable today and the techniques applicable to the multi-domain topology with SIP edge proxies on the borders of each domain or community. Because edge proxies (and the intermediate proxies, if deployed) are interconnected using mutually authenticated TLS links, the fundamental trust model for parties in the network can be reliably maintained. Each community is assumed to be responsible for taking measures to prevent its own users from generating spam. Each community is also responsible for preventing unauthorized access that would allow a malicious third party to gain access to the network for the purpose of sending spam. These techniques are considered out of scope of this document. Each community SHOULD have mechanisms in place to disable its own users that are injecting spam into the inter-domain interface. Most efficiently, this can be achieved by toughening the white list local policies around federated users based on the user's perceived trust level. The specifics of these local policies are out of scope of this document. A receiving community's edge proxy SHOULD take into account factors such as the calling party's User Trust Level (section 9.2), the number of instant messages received from a given sender or community (either to a single recipient or aggregated across all users in a community), or using any of the other techniques listed in [14]. The receiving proxy MAY reject or close connections, provide degraded service, or employ other local policy to deal with these attacks. 10.2 Federated Contacts Accuracy An additional issue that occurs with inter-community presence is that presence subscriptions are typically long-lived and are identified only with a SIP "Address of Record" (AoR). If a principal leaves a community and is subsequently replaced by another principal having the same address as the departed principal, the new principal may receive messages for, or be exposing presence to, entities that are trying to communicate with the previous principal. Therefore, for inter-community communications, it is REQUIRED that the communities not reassign a removed user AoR to a new user for at least 90 days after the old user was removed from the community. In order to ensure the validity of a user's contact lists and ACLs, Levin, et al. Expires January 16, 2005 [Page 14] Internet-Draft Inter-domain Profile for SIMPLE July 2004 it is strongly RECOMMENDED that the network services periodically re-SUBSCRIBE to all external contacts in the lists at least every 45 days. The availability of the ability to convey Add/Remove contact information (section 9.3) may also provide assistance in this regard. 11. IANA Considerations None. 12. Acknowledgments 13. References 13.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [4] 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. [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. 13.2 Informational References [9] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. Levin, et al. Expires January 16, 2005 [Page 15] Internet-Draft Inter-domain Profile for SIMPLE July 2004 [10] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-06 (work in progress), May 2004. [11] Sugano, H. and S. Fujimoto, "Presence Information Data Format (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. [12] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, "RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in progress), March 2004. [13] Schulzrinne, H., "CIPID: Contact Information in Presence Information Data Format", draft-ietf-simple-cipid-03 (work in progress), July 2004. [14] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", draft-rosenberg-sipping-spam-00 (work in progress), July 2004. Authors' Addresses Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: oritl@microsoft.com Avshalom Houri IBM Science Park Building 18/D Rehovot, Israel EMail: avshalom@il.ibm.com Levin, et al. Expires January 16, 2005 [Page 16] Internet-Draft Inter-domain Profile for SIMPLE July 2004 Edwin Aoki America Online, Inc. 360 W. Caribbean Drive Sunnyvale, CA 94089 USA EMail: aoki@aol.net Levin, et al. Expires January 16, 2005 [Page 17] Internet-Draft Inter-domain Profile for SIMPLE July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Levin, et al. Expires January 16, 2005 [Page 18]