Internet Engineering Task Force Akari Harada
Internet-Draft Nobuo Ogashiwa
Intended Status: Informational Maebashi Kyoai Gakuen College
Expires: July 31, 2012 Hirotaka Sato
Keio Univ.
Yoshihiro Suzuki
D3 Communications
January 29, 2012
SRV record query extension for XMPP
draft-harada-xmpp-srv-record-query-00
Abstract
According to RFC 6120, XMPP clients should use SRV records within
the connection establishment process to servers. There are two
purposes for using SRV records. The one is to advertise the FQDN of
at least one server to clients to establish an initial TCP
connection. The other purpose is to advertise at least two or more
FQDN with priority and weight information to clients to accomplish
load balancing, a redundant server environment and so on. However,
most standard resolver libraries of recent client OSs don't support
SRV record resolution. Furthermore, many DNS hosting services also
don't support SRV records. This document proposes a solution that
enables a server and client to achieve load balancing and a
redundant server environment in case SRV records cannot be used.
Moreover, the proposed IQ-result message can include minimum wait
time to reconnect, allowing clients to reconnect after the most
suitable wait time avoiding congestion.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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."
Harada, et al. Expires July 31, 2012 [Page 1]
Internet-Draft XMPP SRV Record Query January 2012
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 July 31, 2012.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Client Resolver . . . . . . . . . . . . . . . . . . . . . . 3
2.2 DNS Hosting Service . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Overview of the solution . . . . . . . . . . . . . . . . . 4
3.2 IQ-get message . . . . . . . . . . . . . . . . . . . . . . 4
3.3 IQ-result message. . . . . . . . . . . . . . . . . . . . . . 4
3.4 IQ-error message . . . . . . . . . . . . . . . . . . . . . . 5
4. Reconnection Policy Information . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Normative References . . . . . . . . . . . . . . . . . . . 6
7.2 Informative References . . . . . . . . . . . . . . . . . . 7
Harada, et al. Expires July 31, 2012 [Page 2]
Internet-Draft XMPP SRV Record Query January 2012
1. Background
In section 3 "TCP Binding", RFC 6120 specifies that XMPP clients
should use DNS SRV records to connect to servers. There are two
purposes for using SRV records within the connection establishment
process. They are as follows:
(A.1) To inform initiating entities of at least one server hostname
for TCP connection establishment.
(A.2) To inform initiating entities of at least two or more server
hostnames with priority and weight information to achieve
load-balancing or a redundant server environment.
2. Problems
However, at present, there are many cases of incompletely supported
SRV records in both clients and servers.
2.1 Client Resolver
Many of the deployed DNS resolver implementations which are
implemented as a standard library on popular client OSs support 'A
record' and 'AAAA record' resolution but don't support 'SRV record'
resolution. If a standard library doesn't support SRV record
resolution, client software has to have the original code of
resolver functions. However, implementing original resolver
functions can result in serious implementation costs.
There are some solutions relating to (A.1), which are A record
resolutions or 'hardcode' of the server hostname.
However, there are no solutions relating to (A.2) described in the
above section.
2.2 DNS Hosting Service
There are many DNS Hosting Services and many of them don't support
SRV record registration via a web-based user interface. In this
case, to accomplish (A.2), internal redundancy technologies like
internal clustering technologies will be required. However,
establishment of such internal redundancy environments can result
in serious operation costs.
Harada, et al. Expires July 31, 2012 [Page 3]
Internet-Draft XMPP SRV Record Query January 2012
3. Proposed Solution
3.1 overview of the solution
This section describes a new info/query stanza as a solution for
the above problem. This is done by sending an get over the
stream from the client to the server.
3.2 IQ-get message
Example 1. IQ-get message(client - server)
The client requests the server for information similar to a SRV
record. If the server supports similar SRV record information, it
MUST return an IQ-result with that information to the client.
3.3 IQ-result message
Example2. IQ-result message (server - client)