INTERNET-DRAFT Sonu Aggarwal
Expires: June 17, 2000 Microsoft
Colin Benson
NetEffect
John Stracke
ECal
Christophe Vermeulen
Alcatel
Transport Protocol for Presence Information/ Instant Messaging
draft-ietf-impp-pitp-mitp-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 document and related documents are discussed on the impp mailing
list. To join the list, send mail to impp-request@iastate.edu. To
contribute to the discussion, send mail to impp@iastate.edu. The
archives are at http://www.imppwg.org/ml_archives.html. The IMPP
working group charter, including the current list of group documents,
can be found at http://www.ietf.org/html.charters/impp-charter.html.
2. Abstract
Presence and Instant Messaging have recently emerged as a new medium
of communications over the Internet. Presence is a means for finding,
retrieving, and subscribing to changes in the presence information
(e.g. "online" or "offline") of other users. Instant Messaging is a
means for sending small, simple messages that are delivered immediately
to online users. A goal of the Instant Messaging and Presence Protocol
(IMPP) Working Group is to produce an Internet Standard for Presence
and Instant Messaging.
The document draft-ietf-impp-reqts-04.txt [Requirements] specifies a
detailed set of requirements that such a protocol must meet. The
document series draft-ietf-impp-pitp-mitp-xx is a prospective
deliverable of the Working Group, with the eventual goal of specifying a
transport protocol for Presence Information and Instant Messaging that,
in conjunction with the other deliverables of the Working Group, meet
the requirements in [Requirements].
This version of the document specifies the scope of the transport
protocol document(s), discusses the design options for the key issues,
and then characterizes the state of discussion on the IMPP mailing list
for these key issues. Later revisions of the document will specify
protocol details, as the issues are gradually resolved in the Working
Group.
3. Scope of PITP/MITP
The Presence and Instant Messaging Transport document(s) will eventually
specify protocol operations that include, but are not necessarily
limited to, the following operations (see [Model] for definitions of the
capitalized terms):
- Publishing PRESENCE INFORMATION
- Establishing SUBSCRIPTIONS
- Retrieving PRESENCE INFORMATION
- Retrieving WATCHER INFORMATION
- Sending NOTIFICATIONS of changes to PRESENCE INFORMATION
- Sending INSTANT MESSAGES
In order to specify protocol details for the above operations, the
document(s) need to first resolve key issues such as the following:
- Domain architecture
- Base and higher-level transport layers (e.g. TCP/UDP/SMTP/HTTP/etc.)
- Addressing and name resolution
- Connection model
Once the above issues are resolved, the transport protocol specification
can include the following aspects:
- Command model
- Command encoding formats
- Command set
- Error handling
- Protocol syntax by command
Further details about the terminology above are given later in the
document, where each aspect is independently described.
Since the Working Group is expected to be chartered to specify transport
protocols for Presence and Instant Messaging in separate documents,
future versions of this document may be produced as two separate
documents, depending on the degree of commonality in the transport
protocols. Regardless of whether eventually specified in one document
or two, the transport protocol(s) must support deploying Presence and
Instant Messaging as separate services, as mandated in [Requirements].
This document series complements the other proposed deliverables of the
Working Group. The [Security] deliverable will specify all security-
related aspects of IMPP. Since security considerations are of great
import even in the initial stages of designing a transport protocol,
technical discussions in this document commence with a summary
discussion of security considerations and guiding principles. It is
expected that this discussion is consistent with the current intent of
authors of the [Security] deliverable. The [PIDF] deliverable will
specify a data format for PRESENCE INFORMATION. The [MIDF] deliverable
will specify a data format for INSTANT MESSAGES. The [Service]
deliverable will specify operational aspects of IMPP deployments.
There have been notable earlier efforts in the IMPP transport area,
including the IMPP Interim Meeting in San Francisco, as well as the
[Basis] and [Vermeulen-Transport] documents. This document is intended
to build upon those efforts.
4. Security considerations
There is a separate team [Security] chartered to investigate the
security aspects of the IMPP protocol. It is necessary however to keep
some security related aspects of [Requirements] in mind when
designing PITP and MITP.
There are many access control requirements. PITP must allow a
PRINCIPAL to control which WATCHERS are allowed by a PRESENCE SERVICE
to access the PRINCIPAL'S PRESENCE INFORMATION. At a minimum the
protocol must allow the PRINCIPAL to configure the PRESENCE SERVICE to
make such decisions autonomously ([Requirements] Section 5.3.7). It
might be desirable to allow the PRINCIPAL to exercise this kind of
control manually when possible but it doesn't seem to be part of
[Requirements] that this be the case. The access control portion of
PITP must also allow a PRINCIPAL to specify that only certain portions
of it's PRESENCE INFORMATION be made available to a given WATCHER. To
further complicate things, a PRINCIPAL must be able to grant limited
control of a PRESENTITY to other PRINCIPALS. One mechanism for
achieving this kind of control is an access control list (often called
an ACL). At the time of writing there is much controversy on the WG
mailing list surrounding the proper place for such an ACL.
A similar set of access control requirements apply to INSTANT INBOXES.
The controlling PRINCIPAL of an INSTANT INBOX must be able to decide
which other PRINCIPALS can send messages to or receive messages from
that INSTANT INBOX.
If the group reaches a consensus suggesting that ACLs or some other
similar mechanism are part of the PITP and MITP then it may be
possible to adopt a similar scheme for authorizing access to both
PRESENCE INFORMATION and INSTANT INBOXES.
Other than access control, the requirements also generally stipulate
that the protocol must have sound authentication and encryption
capabilities. Design of the transport protocol must take into
account the need for such operations across the Internet, across
different administrative entities (e.g. domains).
5. Key Issues
We now describe some key transport issues that the PITP/MITP effort must
address, that largely influence further specification of protocol
details. For each issue, we describe the different design options and
considerations for each option, as well as the current state of
discussion on the list and in prior submissions.
5.1. Base Transport
The PITP/MITP base transport is concerned with the business of getting
presence and instant messaging data between clients and servers. It
doesn't address the format of that data or its semantics. As with
every other interesting issue in IMPP, there is a lot of overlap
between the issues surrounding the base transport and many other areas
including but not limited to security, higher level transport issues
and the connection model. A (probably partial) list of the issues most
closely linked with the base transport protocol follows:
- Reliability
- Efficiency
- Security
- Multiplexing of IM and PP
- Request/response matching
Discussion of these issues has generated three main options, TCP,
UDP and Hybrid TCP/UDP.
5.1.1. TCP
TCP's primary advantages are well-known: it's a reliability layer
that's already in the OSes, that's been debugged over the past 20
years, and that plays nicely with firewalls. However, there remains a
camp that believes TCP is too heavyweight for our needs, and that
something better could be designed today. There is some reason to
believe that a custom reliability protocol could serve us better,
because it could be packet-oriented instead of byte-oriented; the
problem is that, since it wouldn't be as widely used as TCP, it
wouldn't get the attention that TCP gets, and so it wouldn't get
refined as much. It is worth noting that the there are two sub-options
within TCP. First, a long lived connection could be used. This causes
difficulties with existing wireless networks and so may not be
viable. Another option is to use TCP for single transactions or
short-lived, closely related groups of transactions (ala HTTP).
5.1.2. UDP
UDP's primary advantage is that it is lightweight: it is much easier
to implement than TCP, and, since it doesn't require connection setup,
it gives less latency and consumes less bandwidth. In addition, it
may be easier to support on a WAP-type device (WAP has been declared
out of scope, but it's still on some people's It Would Be Nice If
lists). However, UDP does not provide reliability or congestion
control. (The latter is most serious; TCP's congestion control is one
of the things that keeps the Internet from collapsing.) Any pure UDP
protocol would have to implement these features; by the time you're
done, you've done almost as much work as a TCP implementation.
5.1.3. Hybrid TCP/UDP - Dynamic Switching
A hybrid approach would be to send each message via UDP, and then, if
the receiver does not acknowledge the message, retry via TCP. This
approach was suggested by the UDP camp as an answer to the
difficulties of pure UDP. The counter-arguments are (a) it does not
free the endpoint from having to support a TCP stack; (b) it requires
extra machinery to prevent duplicate messages (when the message gets
through, but the acknowledgement doesn't); (c) it means you're still
sending one non-flow-controlled UDP packet per message.
5.1.4 Hybrid TCP/UDP - Negotiation Based
Another type of hybrid approach that might be taken is to allow
clients to negotiate for their preferred means of
communication. Clients who don't want to use TCP don't have
to. However doing so requires that we build congestion control
etc. into the UDP protocol or get agreement from the WG chairs/IESG to
allow the protocol to violate the requirements in some cases.
5.2. Higher-level Transport
5.2.1. Goals
A higher level transport operates over the basis transport. It
provides semantics linked to multi-operation sequences, security and
addressing. The higher level transport has several goals.
5.2.1.1. Support small clients
It appears to be universally accepted in the working group that we
want a protocol that will function acceptably in low-bandwidth,
slow-CPU environments (e.g., PDAs with wireless connectivity).
5.2.1.2. Avoid long-lived connections
Some of the working group participants with experience in the wireless
space point out that many current wireless services charge by the
minute, even when no data is flowing, and so users should not have to
keep a connection open when they aren't using it; if the server needs
to notify the client, it should open a new connection.
5.2.1.3. Avoid server-to-client connections
Nearly all business users, and many home users, are behind firewalls
and/or NATs, which means that it is difficult or impossible for them
to accept incoming connections.
Obviously, this goal conflicts with "avoid long-lived connections"
(above). At this time, most of the working group seems to feel that
this goal is more important; for one thing, it seems likely that most
wireless services will eventually transition from per-minute to
per-packet pricing models.
5.2.1.4. Minimize latency
It appears to be universally accepted in the working group that we
want to minimize the latency in the protocol. This is required by
section 7.3.1 of [Requirements] which states that we must be able to
provide conversational performance.
5.2.1.5. Avoid frequent connection setups
Setting up a connection in a reliable protocol such as TCP is
relatively slow; it would be useful to do it as infrequently as
possible. If every IM delivered required a connection setup step, it
might drive up latency unacceptably.
This could mean that we need long-lived connections, which conflicts
with "avoid long-lived connections" (5.2.1.2 above).
5.2.1.6. Security
We probably want the security features to be as low in the stack as
possible (but no lower). Security is difficult to get right; if we
can share it between IM and presence, then we can do one security
analysis instead of two, and implementers can write one set of
security code instead of two. However, it's not clear how many of the
security requirements are common between messaging and presence
information.
5.2.1.6. Rapid development
We would like to get this protocol designed quickly, because the
existing IM world badly needs standardization. This does not mean we
should be willing to make mistakes, but we need to keep our eyes open
for safe shortcuts.
5.2.1.7. Resolving the conflicts
It might be possible to support two modes, one with long-lived
connections and one with short-lived connections, set up for each
message or for a few messages at a time. This approach has not been
extensively discussed on the mailing list; the problem with it is that
each server must support both modes, which makes inter-operability more
difficult. No consensus exists on how to resolve this problem.
5.2.2. Necessary characteristics
These are the characteristics the protocol must have in order to meet
the above goals.
5.2.2.1. Simple
To support small clients, the protocol will have to be simple, in
order to reduce memory footprint and CPU requirements.
5.2.2.2. Low Overhead
To support small clients, the protocol will have to have minimal
overhead, in order to reduce bandwidth requirements.
5.2.2.3. Minimal Round Trips
To minimize latency, we must minimize round trips. The usual
counter-example is SMTP without pipelining, where the client must issue
a sequence of commands and wait for the response to each. It will
probably be necessary to have round-trip delays during authentication
(since the client must wait to find out what authentication schemes
the server supports); but, after that, all round-trip delays should be
avoided.
5.2.2.4. Unsolicited Messages
To minimize round trips, it must be possible for either end of the
connection to send a message (IM or presence notification) at any time
(as long as it isn't already sending a message). If end A is already
sending a message, it must be possible for end B to start sending a
message without waiting for A to finish.
5.2.2.5. Protocol Reuse
To get the design completed quickly, it makes sense to reuse existing
work whenever possible, provided we can do so without compromising our
other goals.
5.2.3. Options
5.2.3.1. HTTP
We could build MITP and PITP over HTTP.
5.2.3.2. LDAP
We could build PITP over LDAP, with the extensions being developed by
the ldapext group.
5.2.3.3. Custom
We could design our own protocol(s).
5.2.3.3.1. One protocol
We could design one core protocol to be used by both MITP and PITP.
It remains an open question whether MITP and PITP would be layered
over the core protocol, or would be extensions to the core protocol.
5.2.3.3.2. Two protocols
We could design two distinct protocols.
5.2.3.3.3. Pros and cons
If the needs for MITP and PITP overlap enough, then one protocol will
be easier than two. The uncertainty is whether we will discover
significant mismatches in their needs.
The list has not yet seen much discussion on this point; the consensus
seems to be that we would like to have just one protocol, but we'll
have to wait and see whether it's workable.
5.2.3.4. Pros and cons
Using HTTP provides the Simple and Protocol Reuse characteristics, but
it has problems. Building any sort of event notification (including
IM or presence) over HTTP is fraught with difficulties, because of its
limited request/response structure (it does not have the Unsolicited
Messages characteristic). There has been some discussion on the list
on this point; the proponents of HTTP pointed out that it is possible
to emulate unsolicited responses via something like the
multipart/x-mixed-replace Content-Type. The counter-argument is that
such an approach would do a poor job of maintaining anything like a
long-term session; if the client needs to change its session state, it
has to close the current HTTP connection and open a new one. More
generally, HTTP comes with a lot of features that don't make sense for
notification (e.g., caching), and doesn't provide other features that
do (e.g., Unsolicited Messages).
It might be possible to build a presence service over LDAP; this would
give us Protocol Reuse. (Note: there has not been much discussion on
this option on the list so far, so this paragraph is somewhat
speculative.) For a limited service (no SUBSCRIBERs), we wouldn't
even have to wait for ldapext; [LDAPv3] provides the dynamic update
features we would need. However, it's unclear whether dynamic LDAP
can provide the necessary performance; LDAP's original speed benefits
over DAP were achieved in part by omitting dynamic update features.
In addition, the fact that it is based on ASN.1 may make it too
heavyweight for small clients (it doesn't have the Simple and Low
Overhead characteristics); and we don't really need its powerful
searching capabilities. Also, since LDAP probably wouldn't be usable
for IM, even with ldapext, we'd have to design our own IM protocol
anyway, so, even though we'd have the Protocol Reuse characteristic,
we wouldn't meet the rapid development goal.
Designing our own protocol may be more work, but it seems to be the
only way to get the characteristics we need. Recent discussion seems
to have assumed that this is the direction we will take.
5.3. Domain architecture
The term 'domain architecture' refers to the distribution of both
client and server functions. For example, we could choose to have two
separate protocols, one for client to server interaction and another
for server to server interaction. The issues that drive our decision
making here include but are not limited to:
- making good use of the performance characteristic of LAN and WAN
networks where they are applicable.
- avoiding conflicts with potential security schemes (especially since
a potential goal for the security team is the avoidance of imposing
new security schemes for sites that already have one that they like).
5.3.1 Pros and Cons
Using the same protocol in for both client-server and server-server
communications may yield some simplifications, since we'd be able to
leverage the overlap between the two cases. On the other hand, if the
requirements for the two cases turn out to be substantially different,
this may cause more trouble than it saves.
This point has been brought up on the list, but there has been little
or no technical discussion so far; the motivation has been to develop
a server-server protocol first, so that existing proprietary systems
can inter-operate. As a result, we have not yet figured out which way
is technically better.
5.3.2. Do we allow nested domains?
Nested domains are domains in which, say, foo@example.com may actually
be foo@bar.example.com; the server for example.com manages the mapping
somehow, either by forwarding or by redirecting incoming connections.
It sounds like a good idea; it makes for greater manageability in
large domains, and reduces the cost to remote sites. However, when it
was discussed recently, several problems came up. The server for
example.com becomes a bottleneck for its subdomains; it becomes
necessary for bar.example.com to trust example.com (sounds reasonable,
but it is also necessary for example.com to trust com, which is more
of a problem); and the redirection approach means that remote servers
don't get to maintain fewer connections (which means costs aren't
reduced), while the forwarding approach increases latency.
The proponents of nested domains seem to have accepted that they do
not provide benefits in proportion to the complexity they require.
5.3.3. Can clients talk to remote servers?
Do clients talk only to local servers or can they also talk to
remote servers? This point has not been discussed much; most
discussion has more or less assumed the client->server->server->client
model.
First of all, it is clearly the case that a client cannot talk to a
remote server if the client-server and server-server protocols are
different.
It seems likely that a client cannot talk to a remote server unless
the client plays the part of a server. This comes about as a result
of our goal of preventing forged messages (see section 8.4.3 of
[Requirements]). The domain model is designed to meet this goal, by
giving the domain's IMPP servers the responsibility of authenticating
their users. The simplest way to do this is for every IM or
NOTIFICATION leaving the domain to pass through the domain's IMPP
servers. So a client which wants to connect directly to a remote
server must be able to identify itself as a domain server for its
domain. (How that identification is done is still undetermined.)
However, there is an alternative: if we wanted to permit a client to
connect to a remote server, then we could design a model in which the
client connects to the remote server and presents its credentials; the
remote server then finds the IMPP server for the client's home domain
and asks it to authenticate the credentials. This approach requires
credentials that can be passed around safely (it would obviously be
inappropriate with passwords, for example).
It is not clear whether the flexibility of connecting directly to
remote servers is worth the complexity of forwarding credentials.
More discussion is needed.
Another attribute of a scheme that allows clients to be occasional
servers is that it enables efficient messaging on systems where
privacy and security are a lesser concern, E.g. within a corporate
LAN. It seems unlikely that this will work well for presence
information which may forecast one of the areas that PITP and MITP
diverge.
5.4. Addressing
We need to determine three things: the format of addresses, how they
are resolved, and how our choices interact with DHCP.
5.4.1. Name format
It is taken as given that we do not use IP addresses, since that would
violate several requirements in [Requirement] which specify that users
must be able to communicate without revealing their IP addresses.
(For example, see sections 8.1.18, 8.2.5, and 8.2.6)
5.4.2. URL
We could define a URL scheme or schemes which identify IMPP-related
names. This approach is favored by people who want to be able to
express any COMMUNICATIONS ADDRESS as a URL; what the model calls
COMMUNICATIONS MEANS and CONTACT ADDRESS then become the URL scheme
and the part after the scheme. We could define a single impp: URL
scheme, which is used to refer to both INSTANT MESSAGE INBOXES and
PRESENTITIES. We could define two separate schemes for IM and
presence (say, im: and pi:), the better to separate the two protocols.
5.4.2.1. Pros and cons
The advantage of a single URL is simplicity; the advantage of separate
URLs is that it makes it easier to, say, get your IM and presence
services from two different servers. This hasn't been discussed on
the list but several WG meetings seem to have found that having
separable IM and PP addresses is important.
5.4.3. Email format
An alternate approach is to use an RFC-822 style address. In one
scenario, we use an email address format, but don't actual use email
addresses. One common proposal is to use RFC-2303 tagged email. In
another scenario, we use something that looks like an ordinary email
address, normally the same as the user's actual email address.
5.4.3.1. Pros and cons
The "actual email address" scenario seems to have surfaced just
recently, and it's not yet clear what all the tradeoffs are. The main
advantage is that a user can give out one contact address; if you know
somebody's email address, you know their IM address. The main
disadvantage is that there's no way for the protocol to ensure that
foo@example.com actually goes to the same person via IM as via email,
which means that there'd be a risk of messages getting delivered to
the wrong person. However, we have not yet figured out whether this
is likely to be a problem in actual practice.
5.4.4. Email format in a URL
This scenario defines a URL scheme with an email-like format for the
rest of the URL, as in "im:foo@example.com". The idea is to make the
URL format more intuitive than "im://example.com/foo". It could also
be used to provide the ability to embed a "send me an IM" link in a
Web page, even if we don't use URLs internally.
5.4.4.1. Pros and cons
The advantages of using a URL scheme are (a) it permits "send me an
IM" links (like mailto: links), (b) it provides IMPP systems a clean
way to gateway to other systems (just tell your server you want to
send an IM to, say, "sms:+3585551234567"), and (c) it permits PIDF to
treat INSTANT INBOX ADDRESSes the same as other COMMUNICATIONS
ADDRESSes.
The chief advantage of using email format is that it's what users are
used to; if we adopt actual email addresses, then it reduces their
memorization load, too. Some usability testing has indicated that
this is what users actually want; they do not want URL-like addresses,
and they do not want to have to learn a new set of addresses for their
friends.
5.4.5. Resolution
Any of the above formats basically boils down to an ordered pair
(User, Domain). To be neutral, this section will use the ordered pair
syntax. For brevity, this section refers to instant messaging only,
although everything said here applies equally to presence.
Given the INSTANT INBOX ADDRESS (User, Domain), it is necessary to be
able to find a server that can deliver messages to the INSTANT INBOX
it represents. [Note: the server might be part of a client
implementation on the same LAN segment as the sender] There have been
a few proposals along these lines.
This section refers to "the sender", which is simply the entity (be it
a SENDER USER AGENT, a SERVER, a PRESENCE USER AGENT, or a wombat)
which needs to find the server for (User, Domain).
5.4.5.1. DNS-based
This approach uses DNS to map Domain to a server; User is ignored.
5.4.5.1.1. A only
In this scenario, the sender does a DNS lookup looking for A records
for Domain; if at least one is found, then the sender uses the server
it specifies.
5.4.5.1.2. SRV only
In this scenario, the sender searches for SRV records according to the
algorithm of [SRV]. If an SRV record is found, then the sender uses
the server it specifies.
5.4.5.1.3. A followed by SRV
In this scenario, the sender tries the "A only" algorithm first; if it
fails, or if the sender cannot connect to an IM server on the host
found, the sender then tries the "SRV only" algorithm.
5.4.5.1.4. SRV followed by A
In this scenario, the sender tries the "SRV only" algorithm first; if
it fails, or if the sender cannot connect to an IM server on the host
found, the sender then tries the "A only" algorithm.
5.4.5.1.5. Pros and cons
As long as SRV is defined only in an Experimental RFC, "A only" is the
only approach that can be standard. We could take on the task of
moving SRV to Proposed Standard, or see if we can get a DNS-related WG
to do so; we would have to consult with the Area Directors for advice
first, of course.
"SRV only" is clearly problematic, since there are probably DNS
servers deployed that don't support SRV. Nobody has suggested it on
the mailing list; it is mentioned here merely for completeness.
"A followed by SRV" is also problematic, since Domain's A record might
predate IMPP, and the host it specifies might not be running an IM
server, which means that the sender would incur an unnecessary latency
in attempting to connect.
"SRV followed by A" uses SRV the way it's meant to be used: as a more
specific way of pointing to a server for Domain. It can incur
unnecessary latencies when Domain has an A record rather than an SRV
record (since it introduces an extra DNS lookup); but, if DNS negative
caching ([DNS NCACHE])is implemented, then the latency will be reduced
in most cases.
5.4.6. Directory search
Some of the proponents of URL-based naming syntaxes have proposed that
we use URLs internally and use directory searches to map user-friendly
names to URLs.
5.4.6.1. Pros and cons
The main advantage of a directory search is flexibility; for example,
a directory could map a single user-friendly address to multiple
alternate URLs. The disadvantage is that it's slow and complex. In
addition, we would need some way of finding out which directory server
to look in. LDAP referrals would be nice, but they aren't ubiquitous
enough, so we'd probably have to use DNS, at which point we might as
well use DNS directly.
5.4.7. DHCP
5.4.7.1. Servers
It is assumed that any site which uses DHCP to assign IP addresses to
its servers will have its DHCP server communicate with its DNS server,
so that a server is always available at the same hostname.
5.4.7.2. Clients
If we support/require server-to-client connections, we will have to
provide some way for a client whose IP address has changed to notify
the server. Otherwise, there is no difficulty; the client simply
keeps a connection open to the server, and closes and reopens the
connection when its IP address changes.
5.5. Connection Model
There are several questions to be asked in relation to the connection
model. They include (but are probably not limited to):
- Does connectivity imply presence?
- Do LANs and WANs offer useful opportunities for different modes of
behavior?
- Should client-client connections be permitted?
- Do we have to worry about connection management?
- Can we optimize server-server connections? Is it worth doing?
5.5.1. Connectivity and Presence
If the client opens a connection to a server and sends some kind of
keep-alive periodically, the server can use the presence of this
connection (whether TCP or UDP) to indicate PRESENCE. Is this a good
idea?
5.5.1.1. Pros and Cons
On the positive side, connectivity implying presence works well on a
LAN segment where frequent keep-alive messages are a reasonable thing
to do. It is a simple and easily understood semantic. On the negative
side, the notion doesn't work well for clients with slower or less
reliable WAN connections. The notion is no help when a client wishes to
inform only a subset of SUBSCRIBERs of a change in status.
5.5.2 Client-Client Communications
If two clients are on the same corporate LAN (or some other setting
where a relaxed privacy model is appropriate) then it is possible that
they could send instant messages to each other directly and avoid
involving a server in their conversation.
5.5.2.1. Pros and Cons
On the positive side, the process is more efficient. If the server is
outside the company firewall it also offers easier security for
intra-net communications. On the negative side, either a new
client-client protocol must be built or clients must include aspects
of the server-side protocol (though it should be noted that this can
be an optional feature so that devices with limited resources don't
have to support this mode of interaction).
5.5.3. Connection Management
If we permit long-lived TCP connections (a separate but related issue)
then we have to have a way for servers to force the release of TCP
connections when server data structures (E.g. sockets) are in short
supply.
5.5.3.1. Pros and Cons
Creating such a capability is needed if long-lived TCP connections are
to be permitted so all of their positive and negative attributes are
associated with this item. In addition it should be noted that
allowing a server to abort connections (whether based on inactivity or
random selection) interferes with the use of connectivity to indicate
presence and requires a more complex implementation on both client and
server components.
5.5.4. Server-Server connection optimization
It is possible that some servers (especially those operated by ISPs
and larger corporations) will have many inter-domain connections to
large servers operated by other enterprises. It might be useful to
gang multiple conversations onto a single TCP connection for the
purposes of getting more efficient use of the Internet.
5.5.4.1 Pros and Cons
The obvious advantage is that fewer TCP connections are used to carry
a given amount of traffic than might otherwise be necessary. It is
not clear that there are any disadvantages except to note that no one
has demonstrated that a significant portion of traffic from large
servers has the correct traffic pattern to take advantage of this
scheme. A good place to look for this kind of information might be in
the email statistics for large companies access to other large
companies.
6. Other Protocol Aspects
The following are aspects of the protocol that will be discussed and
specified after the key issues are resolved. The issues are described
below with the intent of illustrating the scope of further work in the
transport area, and of encouraging discussion about these issues once
the key issues are resolved. Both the list of aspects and the scope of
each are probably not exhaustive at this point.
6.1. Command Model
The transport protocol will likely consist of a number of discrete
operations, or "commands". The protocol may prescribe a certain
general pattern of interaction between clients and servers. For
example, will a command sequence consist of a "request" followed by a
"response"? If so, how can requests and responses be interleaved in a
valid interaction? (For example, is pipelining allowed?) How do the
various components of a command - e.g. the request and response - get
transmitted across intervening "hops", if any?
6.2. Command set
This will specify the various discrete protocol operations (such as
"FETCH", "CHANGE", etc., for example) and the specific purposes they
are used for.
6.3. Command encoding
This will specify the general format for individual protocol
operations. For example, a request may consist of a command name,
certain parameters, a security descriptor, etc., arranged in a certain
order; this section will specify the order and syntax of the different
"fields" in a protocol entity. The format may be partially or
completely adapted from an existing protocol such as IMAP or HTTP, or
may be distinct from existing formats.
Note that data formats for PRESENCE INFORMATION and INSTANT MESSAGES
will be entirely specified by the [PIDF] and [MIDF] deliverables; this
section will only define the other transport-related aspects of
protocol formats.
6.4. Error handling
The protocol will specify error handling policies. How are errors
identified, and by which entities? Does the protocol adopt end-to-end
or hop-by-hop error detection? How do various entities respond to
errors? What policy do entities adopt for retrying protocol
operations? How do entities respond gracefully to crashes or
unanticipated failures?
6.5. Error set
The protocol will specify an exhaustive and useful set of error
conditions. Such a set may or may not draw upon existing error sets,
such as that used by HTTP.
6.6. Command syntax and semantics, by command
For each protocol command, the protocol will specify the precise syntax
specific to that command, including the arguments and other fields
present in both the request and response (if organized as such) for
that command. In addition, the protocol will specify semantics
specific to the command, as well as handling of error conditions
specific to that command. For example, the command(s) to establish
SUBSCRIPTIONS may specify a mechanism to establish leases on
SUBSCRIPTIONS, and similarly the command to publish PRESENCE
INFORMATION may specify a mechanism to establish a lease or a timeout
on that information.
6.7. Scenarios
The protocol will also specify, though perhaps as an informational
exercise rather than a binding specification, actual scenarios such as
a user "logging on" to a Presence/Instant Messaging service, adding
users to their "contact list", maintaining up-to-date status for those
users, and sending users Instant Messages.
It may also be useful to describe specific scenarios that pertain
solely to either Presence or Instant Messaging, since the
[Requirements] stipulate that the services must be deployable
independently.
7. References
[Basis] S. Aggarwal, M. Day, G. Hudson, and G. Mohr, "Proposed Design
Decisions for IMPP," work in progress, draft-day-impp-basis-00.txt,
October 1999.
[DNS NCACHE] M. Andrews, "Negative Caching of DNS Queries (DNS
NCACHE)", RFC-2308
[LDAPv3] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory
Access Protocol (v3): Extensions for Dynamic Directory Services",
RFC-2589
[MIDF] Hudson et al, "Message Information Data Format," work in
progress, draft-ietf-impp-midf-00.txt.
[Model] M. Day, J. Rosenberg, and H. Sugano, "A Model for Presence and
Instant Messaging," work in progress, draft-ietf-impp-model-03.txt.
[PIDF] Sugano et al, "Presence Information Data Format," work in
progress, draft-ietf-impp-pidf-00.txt.
[Requirements] S. Aggarwal, M. Day, G. Mohr, and J.Vincent, "Presence
Information Protocol Requirements," work in progress,
draft-aggarwal-pip-reqts- 04.txt, December 1999.
[Security] Klyne et al, "Security Framework for Instant Messaging and
Presence Protocol," work in progress,
draft-ietf-impp-security-framework-00.txt.
[Service] Horowitz et al, "Service Considerations for IMPP," work in
progress, draft-ietf-impp-service-00.txt.
[SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location
of services (DNS SRV)", RFC-2052.
[Vermeulen-Transport] C. Vermeulen, "A Presence Information Transport
Protocol," work in progress, draft-vermeulen-impp-pitp-00.txt,
November 1999.
8. Safety Notice
No wombats where harmed in the production of this internet draft.
9. Authors' Addresses
Sonu Aggarwal
<sonuag@microsoft.com>
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Colin Benson
<colin@neteffect.com>
Net Effect
4144 Lankershim Boulevard
Suite 200
North Hollywood, CA 91602
USA
John Stracke
<francis@ecal.com>
ECal Corp.
234 N. Columbus Blvd., 2nd Floor
Philadelphia, PA 94043
USA
Christophe Vermeulen
<Christophe.Vermeulen@alcatel.be>
Alcatel
Research Center DS9/C0
F. Wellesplein, 1
B-2018 Antwerp
Belgium