Internet DRAFT - draft-houri-speermint-presence-im-provision
draft-houri-speermint-presence-im-provision
SPEERMINT WG A. Houri
Internet-Draft G. Perzy
Intended status: Informational IBM
Expires: April 30, 2009 E. Aoki
AOL LLC
S. Parameswar
Microsoft Corporation
October 27, 2008
Presence & Instant Messaging Provisioning
draft-houri-speermint-presence-im-provision-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 April 30, 2009.
Abstract
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.
Houri, et al. Expires April 30, 2009 [Page 1]
Internet-Draft Presence & IM Provisioning October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Provisioning Parameters . . . . . . . . . . . . . . . . . . . 3
2.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Authorization & Privacy . . . . . . . . . . . . . . . . . 4
2.3. Presence Features . . . . . . . . . . . . . . . . . . . . 4
2.4. Chat Features . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Clearing House Services . . . . . . . . . . . . . . . . . 5
3. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. XML Schema Examples . . . . . . . . . . . . . . . . . . . . . 6
5. Conveying Protocols . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Houri, et al. Expires April 30, 2009 [Page 2]
Internet-Draft Presence & IM Provisioning October 2008
1. Introduction
The document uses the terminology as defined in [6] 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.
2. Provisioning Parameters
2.1. Connectivity
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.
Houri, et al. Expires April 30, 2009 [Page 3]
Internet-Draft Presence & IM Provisioning October 2008
o DNS names of the Peer Network - Defines the DNS names that can be
used in order to reach to the presence and IM proxies of the other
Peer Network.
o Usage of SRV records - Indication whether SRV records are used by
the other Peer Network.
o Usage of TLS - Indication whether the other Peer Network assumes
TLS only connectivity.
2.2. Authorization & Privacy
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.
o view-sharing support - Indicates whether the [9] is supported and
what mode of the view sharing levels is supported.
2.3. Presence Features
o PIDF extensions - List of PIDF [3] extensions that are supported
by the Peer Network.
o PIDF mapping - Mapping between standardized PIDF extensions and
special PIDF attributes that are used in the Peer Network.
o Support for list subscription - Indicates whether the Peer Network
will accept list subscriptions [4] from users at the other Peer
Network
2.4. Chat Features
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.
o Logging indication - Indicates whether the chat that is coming to
the Peer Network form other Peer Networks is being logged. This
indication will allow the Peer Network that receives this
indication to display an alert to their users once they are to be
engaged in a chat with a user from the logging Peer Network.
Houri, et al. Expires April 30, 2009 [Page 4]
Internet-Draft Presence & IM Provisioning October 2008
o IM mode - Indicates what type of IM messaging is supported:
o
* Page Mode IM - In this use case a user from one Peer Network
sends a page mode [2] IM to a user on another Peer Network.
* Session Based IM - In this use case a user from one Peer
Network creates a Message Session Relay Protocol (MSRP) [5]
session with a user from another Peer Network. Another
alternative for session based IM is indicated in section 2 [2].
o Is typing indicator - Indicates whether RFC 3934 (Indication of
Message Composition for Instant Messaging) is supported by the
Peer Network.
o Rich Text support - Indicates if rich text chat is supported by
the Peer Network. If rich text is supported then a list of the
HTML formats that are supported should be also provided.
o Emoticons support - Indicates if textual emoticons are supported
by the Peer Network. If emoticons are supported then there will
be a mapping of common emoticons text to their meaning.
o Image support - Indicates if sending animated images inside a chat
is enabled and what types of images are supported
o N-way chat - Indicates whether multi-participant textual chat
([7]) is enabled.
o File transfer - Indicated whether sending files from a user in one
Peer Network to a user in another Peer Network is enabled. See
[8] for more details.
2.5. Clearing House Services
A Federation as defined in [6] 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
Houri, et al. Expires April 30, 2009 [Page 5]
Internet-Draft Presence & IM Provisioning October 2008
that are important when connecting to Clearing House:
o Peer Network Privacy - Indication if all other Peer Networks in
the clearing house should be able to see and interact with this
Peer Network. if the Peer Network indicates that it does not wish
to be seen, then a list of the other Peer Networks that should see
this Peer Network should be provided.
3. XML Schema
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.
4. XML Schema Examples
TODO: provide XML examples
5. Conveying Protocols
There are several options for querying and conveying the provisioning
paremeters.
The SIP OPTIONS method is described in [1] 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] 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.
Houri, et al. Expires April 30, 2009 [Page 6]
Internet-Draft Presence & IM Provisioning October 2008
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.
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
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:
o All communication channels between Peer Network and between each
Peer Network and the clearing house have their authenticity and
confidentiality protected.
o The other Peer Network is really the Peering Network that it
claims to be.
o The other Peer Network is secure and trustful such that
information that is passed to it, will not reach a third party.
This includes information about specific users as well as
information about the authorization policies associated with user
information.
o The other Peer Network is secure and trustful such that it will
not modify or falsify data that it presents to its users except as
required by the authorization policy provided.
o If there is a third party (e.g. a clearing house) involved in the
connection between the two Peering Networks that element is also
verified to be secure.
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
Houri, et al. Expires April 30, 2009 [Page 7]
Internet-Draft Presence & IM Provisioning October 2008
close friend.
8. Informative 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] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[4] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[5] Campbell, B., Mahy, R., and C. Jennings, "The Message Session
Relay Protocol (MSRP)", RFC 4975, September 2007.
[6] Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress),
February 2008.
[7] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party
Instant Message (IM) Sessions Using the Message Session Relay
Protocol (MSRP)", draft-ietf-simple-chat-02 (work in progress),
February 2008.
[8] Garcia-Martin, 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-08 (work in progress),
May 2008.
[9] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
Federated Presence with View Sharing",
draft-ietf-simple-view-sharing-01 (work in progress),
July 2008.
[10] Channabasappa, S., "A Framework for Session Initiation Protocol
User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
Houri, et al. Expires April 30, 2009 [Page 8]
Internet-Draft Presence & IM Provisioning October 2008
Authors' Addresses
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
Houri, et al. Expires April 30, 2009 [Page 9]
Internet-Draft Presence & IM Provisioning October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Houri, et al. Expires April 30, 2009 [Page 10]
