| TOC |
|
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 April 30, 2009.
NOTE: This is still an initial draft of this document
The document defines data for provisioning between two presence and IM domains and the methods that can be used to convey the data between the domains.
1.
Introduction
2.
Provisioning Parameters
2.1.
Connectivity
2.2.
Authorization & Privacy
2.3.
Presence Features
2.4.
Chat Features
2.5.
Clearing House Services
3.
XML Schema
4.
XML Schema Examples
5.
Conveying Protocols
6.
IANA Considerations
7.
Security Considerations
8.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The document uses the terminology as defined in [6] (Malas, D. and D. Meyer, “SPEERMINT Terminology,” November 2008.) unless otherwise stated.
Real Time Collaboration (RTC) services become as prevalent and essential for users on the Internet as email. While RTC services can be implemented directly by users in a point-to-point fashion, they are often provided for or on behalf of a Peer Network of users within an administrative domain. As the use of these services grows, users increasingly have the need to communicate with users not only within their own Peer Network but with those in other Peer Networks as well (similar to the old Public Switched Telephony Network (PSTN) that enabled global reachability). In practice, each Peer Network is controlled by some domain, and so there is a need to provide for easier establishment of connectivity between Peer Networks, and the management of the relationships between the Peer Networks. This document details a set of parameters that may need to be sent between Peer Network in order to enable better communication and user experience for presence and IM peering.
The same provisioning parameters can be used also between a client and server and not necessarily only between servers. When used between client and a server they can enable the client to discover the capabilities of the server and for the server to discover the capabilities of the client.
NOTE: This document does not define a protocol for conveying the provisioning data but defines the payload (XML) for the provisioning informaiton.
NOTE: There may be a need to do some negotiation between the Peer Networks. If there is such a need for some of the provisioning parameters, the negotiation mechanism will be added to future versions of this document.
| TOC |
| TOC |
In order to enable connectivity between two Peer Network it is often necessary to specify connectivity parameters that the other Peer Network needs to know in order to connect. The following is an initial list of such parameters.
| TOC |
Privacy and authorization considerations can affect the amount of traffic between Peer Networks considerably. If no optimizations are enabled for privacy or authorization then there is a need to create a subscription for each user that subscribes to another user and get notifications for each subscription. Several optimizations are being defined in order to enable optimized communication while adhering to the privacy and authorization requirements.
The following parameter define what optimization is supported.
| TOC |
| TOC |
Sending instant messages between Peer Networks can be done in several variants and have several associated features that may be supported or not. The following parameters are parameters that can be either supported or not and it is necessary for the other Peer domain to know if they are supported.
| TOC |
A Federation as defined in [6] (Malas, D. and D. Meyer, “SPEERMINT Terminology,” November 2008.) enables peering between multiple Peer Networks. A federation may be implemented by means of a central service providing a hub for the Peer Networks or, alternatively, Peer Networks may connect to each other in a peer-to-peer fashion. One of the most important services that this type of federation should provide is authorized interconnection that enables each Peering Network to securely identify other Peering Networks. Other services that might be provided include an N-way chat server, lawful interception, logging and more. This type of federation is also known as a "Clearing House".
As non-VoIP services are usually text-based and consume less bandwidth, they may benefit from having a central service that will do central services such as logging for them. For example, instead of requiring each Peer Network to log all messages that are being sent to the other Peer-Network, this service can be done by the Clearing House.
When a Peer Network will connect to a Clearing house it will provide and be provisioned with parameters as if when connecting to a normal Peer Network. The following parameters are additional parameters that are important when connecting to Clearing House:
| TOC |
The XML schema for provisioning for presence and IM defines the various attributes that will be sent from the provisioning Peer Network to the requesting Peer Network. The XML scheme will be added to the document later based on feedback regarding the required provisioning parameters.
| TOC |
TODO: provide XML examples
| TOC |
There are several options for querying and conveying the provisioning paremeters.
The SIP OPTIONS method is described in [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 11. It enables on UA to query the capabilities of another user agent. The intention here is that there will be a well known address and port from which the provisioning can be queried using the OPTION method. The may be a need to create a mutual TLS when connecting to the proxy that provides the OPTIONS reply as the Peer Network may want to send different replies according to the Peer Network that is asking.
It is also possible to use the SIP config framework [10] (Channabasappa, S., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” February 2010.) in order to provide configuration parameters between Peer Networks. However, It may be that in most cases the config framework may be much more then what is really needed and only subset of the functionality provided in the framework will be needed..
Retrieving the provisioning data can also be done using HTTP GET request to a well known URL (e.g. domain/pres-im-provisioning). Using HTTP may be simpler then using the SIP OPTIONS method but in cases where there is a need to send different provisioning information to different Peer Networks the will be a need to authenticate the requestor of the provisioning data via HTTP.
XEP 115 (Entity Capabilities - http://www.xmpp.org/extensions/xep-0115.html) defines a way to distribute capabilities of an entity in XMPP. The same mechanism can be adapted to discover capabilities between servers also.
| TOC |
This document has no actions for IANA.
| TOC |
When Peer Network A peers with Peer Network B, there are several security issues that the administrator of each Peer Network will need mechanisms to verify:
The same issues of security are even more important from the point of view of the users of the Peer Networks. Users will have the concern on how their privacy is being adhered to when their presence information is being sent to the other Peer Network. Users today are concerned about providing their email address to a third party when they register to a domain; Presence contains much more sensitive information and the concern of users here will be even deeper.
The privacy issue is even harder if we take into account that in order to enable scalable peering between big Peer Networks there are some optimizations that may require migration of the privacy definitions of users between Peer Network. We can imagine the fiasco if a user of one Peer Network will be able to see the privacy information and will learn he/she are listed in a block list of a close friend.
| TOC |
| [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 (TXT). |
| [2] | Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” RFC 3428, December 2002 (TXT). |
| [3] | Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” RFC 3863, August 2004 (TXT). |
| [4] | Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” RFC 4662, August 2006 (TXT). |
| [5] | Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT). |
| [6] | Malas, D. and D. Meyer, “SPEERMINT Terminology,” draft-ietf-speermint-terminology-17 (work in progress), November 2008 (TXT). |
| [7] | Niemi, A., Garcia, M., and G. Sandbakken, “Multi-party Chat Using the Message Session Relay Protocol (MSRP),” draft-ietf-simple-chat-06 (work in progress), April 2010 (TXT). |
| [8] | Garcia, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, “A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer,” draft-ietf-mmusic-file-transfer-mech-11 (work in progress), February 2009 (TXT). |
| [9] | Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” draft-ietf-simple-view-sharing-02 (work in progress), November 2008 (TXT). |
| [10] | Channabasappa, S., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” draft-ietf-sipping-config-framework-17 (work in progress), February 2010 (TXT). |
| TOC |
| Avshalom Houri | |
| IBM | |
| Science Park | |
| Rehovot, | |
| Israel | |
| Email: | avshalom@il.ibm.com |
| Gil Perzy | |
| IBM | |
| Science Park | |
| Rehovot, | |
| Israel | |
| Email: | gilper@il.ibm.com |
| Edwin Aoki | |
| AOL LLC | |
| 401 Ellis St. | |
| Mountain View, CA 94043 | |
| USA | |
| Email: | aoki@aol.net |
| Sriram Parameswar | |
| Microsoft Corporation | |
| One Microsoft Way | |
| Redmond, WA 98052 | |
| USA | |
| Email: | Sriram.Parameswar@microsoft.com |
| TOC |
Copyright © 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.
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.