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 Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Colin Benson Net Effect 4144 Lankershim Boulevard Suite 200 North Hollywood, CA 91602 USA John Stracke ECal Corp. 234 N. Columbus Blvd., 2nd Floor Philadelphia, PA 94043 USA Christophe Vermeulen Alcatel Research Center DS9/C0 F. Wellesplein, 1 B-2018 Antwerp Belgium