Network Working Group R. Earhart Internet Draft: AP Carnegie Mellon Document: draft-earhart-ap-spec-00.txt May 1997 Expire in six months AP -- Access Protocol Status of this Memo This document is an Internet-Draft. 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 not appropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this draft is unlimited. The protocol discussed in this document is experimental and subject to change. Persons planning on either implementing or using this protocol are STRONGLY URGED to get in touch with the author before embarking on such a project. Abstract The Access Protocol defines a standard extensible framework upon which application-specific protocols may be layered, providing a piece of infrastructure for a common class of internet protocols. Earhart [Page 1]
Internet DRAFT Access Protocol May 19, 1997 Attributions Substantial portions of this protocol and of the text of this document come from early drafts of [ACAP], which itself borrows much from [IMAP4]. 1. Motivation There are an increasing number of internet application-level protocols which perform two disparate tasks -- defining a set of commands and their meanings, and a mechanism for encoding those commands on the wire. As time goes on, it's becoming increasingly obvious that many of the problems which these protocols are intended to address share quite a few characteristics with each other. Unfortunately, as all these protocols use a different wire encoding, it's difficult for these protocols to share technology. It's hoped that by defining a common infrastructure between the application-specific command suite and the underlying stream protocol, the state of the art in protocol design will improve and advance faster than if each idea had to be incorporated into each protocol individually (such as TLS and SASL). ASN.1/BER is *not* used, as there is a significant feeling in the applications area community that the complexity of these standards is a significant barrier to implementation. It is recognized that not all applications-level protocols will fit into this model; TELNET is a good example of a protocol that does not belong in this framework. Nevertheless, it is believed that this is of sufficient utility to enough protocols to be worth advancing as an IETF standard. 2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Earhart [Page 2]
Internet DRAFT Access Protocol May 19, 1997 3. Protocol Overview 3.1. Link Level The Access Protocol assumes a reliable data stream such as provided by TCP. The command protocol that uses the AP is responsible for specifying any parameters to be used in constructing the stream. 3.2. Commands and Responses An AP session consists of the establishment of a client/server connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result. All interactions transmitted by client and server are in the form of lines; that is, strings that end with a CRLF. The protocol receiver of an AP client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line. Both clients and servers MUST be capable of handling lines of arbitrary length. 3.2.1. Client Protocol Sender and Server Protocol Receiver The client command begins an operation. Each client command is prefixed with a identifier composed of one to thirty-two characters (typically a short alphanumeric string, e.g., A0001, A0002, etc.) called a "tag". A different tag is generated by the client for each command. There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in section <section>); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). In some of these cases, the server sends a command continuation request if it is ready for the next part of the command. This response is prefixed with the token "+". Note: If, instead, the server detected an error in the command, it sends a BAD or NO completion response with tag matching the command (as described below) to reject the command and prevent the client from sending any more of the command. It is also possible for the server to send a completion or intermediate response for some other command (if multiple commands Earhart [Page 3]
Internet DRAFT Access Protocol May 19, 1997 are in progress), or untagged data. In either case, the command continuation request is still pending; the client takes the appropriate action for the response, and reads another response from the server. The server reads a command line from the client, parses the command and its arguments, and transmits server data and a server command completion result. 3.2.1. Server Protocol Sender and Client Protocol Receiver Data transmitted by the server to the client come in four forms: command continuation requests, command completion results, intermediate responses, and untagged responses. A command continuation request is prefixed with the token "+". A command completion result indicates the success or failure of the operation. It is tagged with the same tag as the client command which began the operation. Thus, if more than one command is in progress, the tag in a server completion response identifies the command to which the response applies. There are three possible server completion responses: OK (indicating success), NO (indicating failure), or BAD (indicating protocol error such as unrecognized command or command syntax error). An intermediate response returns data which can only be interpreted within the context of a command in progress. It is tagged with the same tag as the client command which began the operation. Thus, if more than one command is in progress, the tag in an intermediate response identifies the command to which the response applies. A tagged response other than "OK", "NO", or "BAD" is an intermediate response. An untagged response returns data or status messages which may be interpreted outside the context of a command in progress. It is prefixed with the token "*". Untagged data may be sent as a result of a client command, or may be sent unilaterally by the server. There is no syntactic difference between untagged data that resulted from a specific command and untagged data that were sent unilaterally. The protocol receiver of an AP client reads a response line from the server. It then takes action on the response based upon the first token of the response, which may be a tag, a "*", or a "+" as described above. Earhart [Page 4]
Internet DRAFT Access Protocol May 19, 1997 A client MUST be prepared to accept any server response at all times. This includes untagged data that it may not have requested. This topic is discussed in greater detail in the Server Responses section. 3.3. State and Flow Diagram An AP server is in one of at least three states. Most commands are valid in only certain states. It is a protocol error for the client to attempt a command while the server is in an inappropriate state for that command. In this case, a server MUST respond with a BAD command completion result. 3.3.1. Non-Authenticated State In non-authenticated state, the user must supply authentication credentials before most commands will be permitted. This state is entered when a connection starts. 3.3.2. Authenticated State In authenticated state, the user is authenticated and most commands will be permitted. This state is entered when acceptable authentication credentials have been provided. 3.3.3. Logout State In logout state, the session is being terminated, and the server will close the connection. This state can be entered as a result of a client request or by unilateral server decision. 3.3.4. Other States Protocols using AP MAY define more states, as desired. These states MUST only be reachable from the authenticated state, and MUST only transition between themselves, to the authenticated state, or to the logout state. Protocol-specific states MUST only affect the operation of commands defined in those protocols, or in extensions to those protocols. In particular, the NOOP and LOGOUT commands MUST always be available. Earhart [Page 5]
Internet DRAFT Access Protocol May 19, 1997 Protocols MAY define new commands which transition to the logout state. +--------------------------------------+ |initial connection and server greeting| +--------------------------------------+ || (1) (2) || VV || +-----------------+ || |non-authenticated| || +-----------------+ || || (4) || (3) || || VV || || +----------------+ || || | authenticated |<=++ || || +----------------+ || || || || (4) || (5) || (5) || || || VV || || || || +------------+ || || || || |other states|==++ || || || +------------+ || || || || (4) || VV VV VV VV +--------------------------------------+ | logout and close connection | +--------------------------------------+ (1) connection (AP greeting) (2) rejected connection (BYE greeting) (3) successful AUTHENTICATE command (4) LOGOUT or other closing command, server shutdown, or connection closed. (5) State-transition command defined by protocol using AP 3.4. Operational Considerations 3.4.1. Untagged Status Updates At any time, a server MAY send data that the client did not request. It is recognized that this will cause perfectly good TCP connections to be torn down if the network is unavailable for some transient reason; nevertheless, this is better than forcing the client to poll the server for update information. 3.4.2. Response when No Command in Progress Earhart [Page 6]
Internet DRAFT Access Protocol May 19, 1997 Server implementations are permitted to send an untagged response while there is no command in progress. Server implementations that send such responses MUST deal with flow control considerations. pecifically, they must either (1) verify that the size of the data does not exceed the underlying transport's available window size, or (2) use non-blocking writes. 3.4.3. Autologout Timer Servers MAY implement an inactivity autologout timer. If such a timer is implemented, that timer MUST be at least 30 minutes' duration. The receipt of ANY data from the client during that interval MUST suffice to reset the autologout timer. Open Issue: is this really necessary? I'd rather forbid timers and the NOOP command, and say that it's the responsibility of the underlying stream protocol to ensure that the other side's still alive...) 3.4.4. Multiple Commands in Progress The client is not required to wait for the completion result of a command before sending another command, subject to flow control constraints on the underlying data stream. Similarly, a server is not required to process a command to completion before beginning processing of the next command, although the server MUST compute the results of a command as though any changes caused by previous commands had taken place, and as though any changes caused by subsequent commands have not yet taken place. Protocols which use this protocol as their basis SHOULD NOT define commands in such a way as to create an ambiguity when results from seperate commands are interlaced or reordered. 4. Protocol Elements 4.1. Data Formats AP uses textual commands and responses. Data in AP can be in one of four forms: atom, number, string, parenthesized list, or NIL. 4.1.1. Atom An atom consists of one to 1024 non-special characters. Earhart [Page 7]
Internet DRAFT Access Protocol May 19, 1997 4.1.2. Number A number consists of one or more digit characters, and represents a numeric value. 4.1.3. String A string is in one of two forms: literal and quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of restrictions of what may be in a quoted string. A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. There are two forms of literals transmitted from client to server. The form where the open brace ("{") and number of octets is immediately followed by a close brace ("}") and CRLF is called a synchronizing literal. When sending a synchronizing literal, the client must wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command). The other form of literal, the non- synchronizing literal, is used to transmit a string from client to server without waiting for a command continuation request. The non- synchronizing literal differs from the synchronizing literal by having a plus ("+") between the number of octets and the close brace ("}") and by having the octet data immediately following the CRLF. A quoted string is a sequence of zero to 1024 octets excluding CR, LF, double quote (<">), or backslash ("\") with double quote (<">) characters at each end. The empty string is respresented as "" (a quoted string with zero characters between double quotes), as {0} followed by CRLF (a synchronizing literal with an octet count of 0), or as {0+} followed by a CRLF (a non-synchronizing literal with an octet count of 0). Note: Even if the octet count is 0, a client transmitting a synchronizing literal must wait to receive a command continuation request. 4.1.4. Parenthesized List Earhart [Page 8]
Internet DRAFT Access Protocol May 19, 1997 Data structures are represented as a "parenthesized list"; a sequence of data items, delimited by space, and bounded at each end by parentheses. A parenthesized list can contain other parenthesized lists, using multiple levels of parentheses to indicate nesting. The empty list is represented as () -- a parenthesized list with no members. 4.1.5. NIL The special atom "NIL" represents the non-existence of a particular data item that is represented as a string or parenthesized list, as distinct from the empty string "" or the empty parenthesized list (). 4.2. Server Status Responses An OK, NO or BAD response from the server, whether tagged or untagged, is considered a status response. Status responses may include an optional response code. A response code consists of data inside parentheses in the form of an atom, possibly followed by a space and arguments. The response code contains additional information or status codes for client software beyond the OK/NO/BAD condition, and are defined when there is a specific action that a client can take based upon the additional information. The currently defined response code is: ALERT The human-readable text contains a special alert that MUST be presented to the user in a fashion that calls the user's attention to the message. Additional response codes MAY be defined by protocols layered on top of AP or by particular client or server implementations of those protocols. Additional response codes not defined in standards-track documents MUST be prefixed with an "X". Client implementations MUST ignore response codes that they do not recognize. 4.3. Server Command Continuation Request The command continuation request is indicated by a "+" token instead of a tag. This indicates that the server is ready to accept the continuation of a command from the client. The remainder of this response is a line of text. This response is used in the AUTHENTICATE command to transmit server Earhart [Page 9]
Internet DRAFT Access Protocol May 19, 1997 data to the client, and request additional client data. This response is also used if an argument to any command is a synchronizing literal. Protocols layered upon this protocol may define additional commands which use continuations, although these should be few and far between. The client is not permitted to send the octets of a synchronizing literal unless the server indicates that it expects it. This permits the server to process commands and reject errors on a line-by-line basis, assuming it checks for non-synchronizing literals at the end of each line. The remainder of the command, including the CRLF that terminates a command, follows the octets of the literal. If there are any additional command arguments the literal octets are followed by a space and those arguments. 5. Protocol Specification 5.1. Initial Connection Upon session startup, the server sends one of two untagged responses: AP or BYE. The BYE response is documented in section 5.2.6. Open Issue: I'm tempted to change this a little - have the client send its capabilities list in its greeting, and have the server send back a tagged OK, NO, BAD, or BYE response. This would cause negligable network load when used with TCP (the data could be carried in the initial TCP SYN packet which has to be sent anyway), and would allow the server to discover what the client's capable of, at the expense of changing the state diagram a little, hosing backwards compatibility, and adding an additional step for people accessing servers via telnet. 5.1.1. AP Untagged Response Data: capability list The untagged AP response indicates that the session is ready to accept commands and contains a space-separated listing of capbilities that the server supports. Each capability is an atom name, possibly followed by an argument in parenthesis (the argument MAY contain parenthesis, but the parenthesis MUST be balanced). AP capability names MUST be defined in a standards track or IESG approved experimental RFC and registered with IANA according to the rules in section <section>. Earhart [Page 10]
Internet DRAFT Access Protocol May 19, 1997 Client implementations MAY require any capability names, but MUST ignore any unknown capability names. It is recommended that clients require as few capabilities as possible. The following initial capabilities are defined: IMPLEMENTATION The IMPLEMENTATION capability has one argument which is a string describing the server implementation. AP clients MUST NOT alter their behavior based on this value. It is intended primarily for debugging purposes. SASL The SASL capability includes a list of the authentication mechanisms supported by the server. See [SASL] for more information. Example: S: * AP IMPLEMENTATION ("ACME v3.5") SASL ("GSSAPI") 5.2. Any State The following commands and responses are valid in any state. 5.2.1 NOOP Command Arguments: none Data: no specific data for this command (but see below) Result: OK - noop completed BAD - command unknown or arguments invalid The NOOP command always succeeds. It does nothing. It can be used to reset any inactivity autologout timer on the server. Example: C: a002 NOOP S: a002 OK "NOOP completed" 5.2.2 LOGOUT Command Arguments: none Data: mandatory untagged response: BYE Result: OK - logout completed Earhart [Page 11]
Internet DRAFT Access Protocol May 19, 1997 BAD - command unknown or arguments invalid The LOGOUT command informs the server that the client is done with the session. The server must send a BYE untagged response before the (tagged) OK response, and then close the network connection. Example: C: A023 LOGOUT S: * BYE "Server logging out" S: A023 OK "LOGOUT completed" (Server and client then close the connection) 5.2.3. OK Response Data: optional response code human-readable text The OK response indicates an information message from the server. When tagged, it indicates successful completion of the associated command. The human-readable text may be presented to the user as an information message. The untagged form indicates an information-only message; the nature of the information may be indicated by a response code. Example: S: * OK (ALERT) "System shutdown in 10 minutes" 5.2.4. NO Response Data: optional response code human-readable text The NO response indicates an operational error message from the server. When tagged, it indicates unsuccessful completion of the associated command. The untagged form indicates a warning; the command may still complete successfully. The human-readable text describes the condition. Example: C: A222 AUTHENTICATE "DUMB" S: * NO (ALERT) "System shutdown in 10 minutes" S: A222 NO "Unknown SASL mechanism" 5.2.5 BAD Response Data: optional response code human-readable text Earhart [Page 12]
Internet DRAFT Access Protocol May 19, 1997 The BAD response indicates an error message from the server. When tagged, it reports a protocol-level error in the client's command; the tag indicates the command that caused the error. The untagged form indicates a protocol-level error for which the associated command can not be determined; it may also indicate an internal server failure. The human-readable text describes the condition. Example: C: ...empty line... S: * BAD "Empty command line" C: A443 BLURDYBLOOP S: A443 BAD "Unknown command" C: A444 NOOP Hello S: A444 BAD "invalid arguments" 5.2.6. BYE Untagged Response Data: optional response code human-readable text The untagged BYE response indicates that the server is about to close the connection. The human-readable text may be displayed to the user in a status report by the client. The BYE response may be sent as part of a normal logout sequence, or as a panic shutdown announcement by the server. It SHOULD also used by server implementations as an announcement of an inactivity autologout. This response is also used as one of two possible greetings at session startup. As a greeting, it indicates that the server is not willing to accept a session from this client. Example: S: * BYE "Autologout; idle for too long" 5.3. Non-Authenticated State In non-authenticated state, the AUTHENTICATE command establishes authentication and enters authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques. Server implementations may allow non-authenticated access to certain information. The convention is to use an AUTHENTICATE command with the userid "anonymous" with the SASL XXX mechanism. Once authenticated (including as anonymous), it is not possible to re-enter non-authenticated state. Earhart [Page 13]
Internet DRAFT Access Protocol May 19, 1997 In addition to the universal commands (NOOP and LOGOUT), the only command valid in non-authenticated state is AUTHENTICATE. 5.3.1 AUTHENTICATE Command Arguments: SASL mechanism name optional initial response Data: continuation data may be requested Result: OK - authenticate completed, now in authenticated state NO - authenticate failure: unsupported authentication mechanism, credentials rejected BAD - command unknown or arguments invalid, authentication exchange cancelled The AUTHENTICATE command indicates an authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTHENTICATE command by sending a tagged NO response. The authentication protocol exchange consists of a series of server challenges and client answers that are specific to the authentication mechanism. A server challenge consists of a command continuation request with the "+" token followed by a BASE64 encoded string. The client answer consists of a line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it should issue a line with a single "*". If the server receives such an answer, it must reject the AUTHENTICATE command by sending a tagged BAD response. The optional initial-response argument to the AUTHENTICATE command is used to save a round trip when using authentication mechanisms that are defined to send no data in the initial challenge. When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses the data in the initial-response argument as if it were sent in response to the empty challenge. If the initial-response argument to the AUTHENTICATE command is used with a mechanism that sends data in the initial challenge, the server rejects the AUTHENTICATE command by sending a tagged NO response. The service name specified by this protocol's profile of SASL is Earhart [Page 14]
Internet DRAFT Access Protocol May 19, 1997 "ap". If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the tagged OK response for the server. The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any protection mechanisms. If an AUTHENTICATE command fails with a NO response, the client may try another authentication mechanism by issuing another AUTHENTICATE command. In other words, the client may request authentication types in decreasing order of preference. Example: S: * OK IMPLEMENTATION ("Blorfysoft v3.5") SASL (KERBEROS_V4) C: A001 AUTHENTICATE KERBEROS_V4 S: + AmFYig== C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: + or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw== S: A001 OK "Kerberos V4 authentication successful" Note: the line breaks in the first client answer are for editorial clarity and are not in real authenticators. 5.3. Authenticated State In the authenticated state, the universal commands (NOOP and LOGOUT) are valid, in addition to any commands defined by protocols that use AP as their foundation. 6. Design Philosophy Protocols layered on top of AP SHOULD define a set of commands to be valid in the authenticated state. In addition, protocols MAY define an atom to be returned in the initial AP greeting. Ideally, protocols should limit themselves as much as possible to a simple, uncomplicated suite of commands that relate to each other. Where possible, protocols should be broken up into orthogonal components, such that the components may be reused in other Earhart [Page 15]
Internet DRAFT Access Protocol May 19, 1997 protocols. Example: Instead of defining an advisory lock mechanism, advisory locking should be split into a seperate extension, useable by whatever protocols happen to require it. Quota management is another set of commands that could be done as an extension and made available to all protocols that involve quotas. New commands and responses SHOULD only be defined for the Authenticated state. Responses to commands SHOULD be tagged. This is essential for allowing multiple commands to execute simultaneously, and experience shows that this leads to much simpler implementations for both clients and servers. Where textual data is exchanged, protocols SHOULD use UTF8 [UTF8] whenever possible, for internationalization. New command completion responses MUST NOT be defined -- every command MUST be completed by an "OK", "NO", or "BAD" response. 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [IMAIL] with one exception; the delimiter used with the "#" construct is a single space (SPACE) and not one or more commas. Protocols based on AP should refer to this formal syntax, and augment selected parts using the ABNF ::+ operator, as indicated in the comments. The client produces a sequence of octets matching "command-client"; the server consumes these, and returns a sequence of octets matching "response-server". Protocols using AP MAY augment "capability" (subject to the requirement that "capability" MUST match "capability-generic"), "command" (subject to the requirement that "command" MUST match "command-generic"), "response" (subject to the requirement that "response" MUST match "response-generic"), or "resp-code" (again, subject to the requirement that "resp-code" MUST match "resp-code- generic"). Other syntax elements SHOULD NOT be redefined. Earhart [Page 16]
Internet DRAFT Access Protocol May 19, 1997 To aid readability, the protocol elements that are intended to be augmented are defined with "::+"; all others are defined via "::=". A number of symbols are defined solely for use by protocols using AP. ALPHA ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / ;; Case-sensitive ATOM-CHAR ::= <any CHAR except ATOM-SPECIALS> ATOM-SPECIALS ::= "(" / ")" / "{" / SPACE / CTL / QUOTED-SPECIALS BASE64-CHAR ::= ALPHA / DIGIT / "+" / "/" CHAR ::= <any 7-bit US-ASCII character except NUL> CR ::= <ASCII CR, carriage return, 0x0C> CRLF ::= CR LF DIGIT ::= "0" / DIGIT-NZ DIGIT-NZ ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" LF ::= <ASCII LF, line feed, 0x0A> OCTET ::= <any octet value 0x00 - 0xFF> QUOTED-CHAR ::= <any TEXT-UTF8-CHAR except QUOTED-SPECIALS> / "\" QUOTED-SPECIALS QUOTED-SPECIALS ::= <"> / "\" SPACE ::= <ASCII SP, space, 0x20> TEXT-UTF8-CHAR ::= <any UTF8-CHAR except CR and LF> UTF8-CHAR ::= <TODO: UTF-8 character> Earhart [Page 17]
Internet DRAFT Access Protocol May 19, 1997 argument ::= atom / string / number / "(" #argument ")" atom ::= 1*1024ATOM-CHAR base64-token ::= *(4BASE64-CHAR) [base64-terminal] base64-terminal ::= (2BASE64-CHAR "==") / (3BASE64-CHAR "=") capability ::+ "IMPLEMENTATION" SPACE "(" quoted ")" capability ::+ "SASL" SPACE "(" 1#quoted ")" ;; other capabilities MAY be defined by protocols using AP, ;; but MUST syntactically match capability-generic capability-arg ::= atom / quoted / "(" #capability-arg ")" capability-generic ::= atom [SPACE "(" #capability-arg ")"] command-client ::= tag SPACE command CRLF command ::+ "NOOP" command ::+ "LOGOUT" command ::+ "AUTHENTICATE" SPACE atom [SPACE base64-token] *(CRLF base64-token) ;; other commands MAY be defined by protocols using AP, ;; but MUST syntactically match command-generic command-generic ::= atom *(SPACE argument) literal ::= "{" number [ "+" ] "}" CRLF *OCTET ;; The number represents the number of octets nil ::= "NIL" nstring ::= nil / string number ::= 1*DIGIT Earhart [Page 18]
Internet DRAFT Access Protocol May 19, 1997 nz-number ::= DIGIT-NZ *DIGIT quoted ::= <"> *QUOTED-CHAR <"> resp-argument ::= atom / quoted / number / "(" #resp-argument ")" resp-body ::= ["(" resp-code ")" SPACE] quoted resp-code ::+ "ALERT" ;; other resp-codes MAY be defined by protocols using AP, ;; but MUST syntactically match resp-code-generic resp-code-generic ::= atom *(SPACE resp-argument) response ::+ "OK" resp-body response ::+ "NO" resp-body response ::+ "BAD" resp-body response ::+ "BYE" resp-body response ::+ "AP" *(SPACE capability) ;; other responses MAY be defined by protocols using AP, ;; but MUST syntactically match response-generic response-generic ::= atom *(SPACE argument) response-server ::= (tag / "*") response CRLF string ::= quoted / literal tag ::= 1*32<any ATOM-CHAR except "+" or "*"> 8. Security Considerations AP protocol transactions are sent in the clear over the network unless some form of privacy protection is negotiated in the AUTHENTICATE command. AP's security is defined by SASL, and is as strong or as weak as that protocol. Earhart [Page 19]
Internet DRAFT Access Protocol May 19, 1997 9. References [RFC 2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. <ftp://ds.internic.net/rfc/rfc2119.txt> [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. <ftp://ds.internic.net/rfc/rfc2060.txt> [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, Alis Technologies, October 1996. <ftp://ds.internic.net/rfc/rfc2044.txt> [IMAIL] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. <ftp://ds.internic.net/rfc/rfc822.txt> [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", draft-myers-auth-sasl-xx.txt [ACAP] Myers, J., and Newman, C., "Application Configuration Access Protocol (ACAP)", Work in Progress of the IETF ACAP WG, draft-ietf- acap-spec-??.txt. Check Internet Drafts listing for latest version. 10. Author's Address Robert H. Earhart Carnegie Mellon 5000 Forbes Ave. Pittsburgh PA, 15213-3890 Email: earhart+@cmu.edu Earhart [Page 20]