INTERNET DRAFT Steve Hanna draft-hanna-sstp-00.txt ON Technology Simple Scheduling Transfer 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 inappropriate 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), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Simple Scheduling Transfer Protocol (SSTP) provides a mechanism for the exchange of scheduling information between independent scheduling systems. This will allow users to schedule meetings with anyone, no matter what scheduling system they use. It also allows user agents to access scheduling data that is stored in scheduling systems. This opens up scheduling data for much more sophisticated access, such as automated scheduling programs and network computers. 1 Introduction 1.1 Purpose Group schedulers and personal information managers are widely used to plan meetings and manage time. Unfortunately, each system is an island. Scheduling a meeting with someone who uses another system or sharing your own calendar between several systems is very difficult. SSTP bridges the gap between scheduling systems by defining a standard protocol with which these systems can talk to each other. Several other standards have recently been proposed for scheduling Hanna Expires 17-Jan-96 [Page 1] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT system information interchange. SSTP's primary advantages over these standards are: SSTP is simple, including only four commands. SSTP is scalable, including three levels of support from a minimal PIM implementation to a full-blown server implementation. SSTP is extensible, with built-in mechanisms that allow for safe, simple, and inexpensive extensibility. SSTP is based on established protocols and formats such as SMTP, POP, IMAP, MIME, Simplegrams, and vCalendar. 1.2 Requirements This specification uses the same words as RFC 1123 [1] for defining the significance of each particular requirement. These words are: MUST This word or the adjective "required" means that the item is an absolute requirement of the specification. SHOULD This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. MAY This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant." 1.3 Document Structure Hanna Expires 17-Jan-96 [Page 2] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT This document is divided into several major sections. The Protocol Overview section describes the protocol as a whole, including key concepts. The Commands section describes the specific commands supported by the protocol. The Scheduling Objects section describes the parts of the protocol that pertain most specifically to scheduling, the scheduling objects. The Levels of Support section describes three levels of support for the protocol's features. The Examples section includes several example SSTP sessions. The Formal Syntax section includes a formal syntax for the protocol. 2 Protocol Overview 2.1 Description All communications via SSTP occur in the context of an SSTP session. An SSTP session begins when an SSTP client contacts an SSTP server using a reliable data stream protocol such as TCP. Once a session has been established, the client sends a command and the server sends a reply. This is repeated until the session is terminated. The server cannot issue commands during a session or "turn" the session and become the client. Only one command can be pending at a time. That is, the client MUST NOT send a command until it has received the reply to the previous one. Normally, an SSTP session ends when the client sends a QUIT command and the server sends a result code and closes the connection. If an SSTP session is terminated in another way (network failure, for instance), it is undefined whether any pending command was completed. All data sent by client and server MUST consist of lines of US ASCII [2] text (character values 32 to 126 decimal only), terminated by CRLF. If client and server use the AUTHENTICATE command to agree on an encryption technique, the encrypted data may have any form. The decrypted data will continue to have the form described here. All user data is included in SSTP objects, which are transmitted using the Simplegram format [4]. The ENCODING and CHARSET parameters defined in this specification allow property values to include binary data or text in any character set, including Unicode. Each command or reply is a single line, unless it includes an object or objects. In that case, the first line MUST end with an equal sign ("="). The following lines are considered part of the command or reply until the sequence CRLF CRLF equal sign CRLF is read. Because this sequence is not a valid part of a Simplegram, it can easily be distinguished from the object or objects. Hanna Expires 17-Jan-96 [Page 3] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT 2.2 Commands Each SSTP command consists of a keyword, optionally followed by arguments. As described above, each command is a single line, unless it includes an object or objects. There are four commands in the standard SSTP command set, although more can be added and their presence indicated via the capabilities query mechanism. The required commands are SUBMIT, QUERY, and QUIT. The optional command is AUTHENTICATE. 2.3 Replies SSTP replies consist of a numerical result code, optionally followed by data. Successful completion of a command results in a result code of "000" followed by whatever data may be appropriate to the command. Failure of a command results in a non-zero result code followed by an optional textual description of the error. The following numerical result codes are defined. Servers MUST return a result codes in every reply. Clients MAY use these codes to attempt to recover from errors (for example, authenticating if code 100 is returned). Other three digit numerical result codes MAY be defined in extensions to this specification. If the client does not recognize a result code it MUST treat it as a code 900. Code Meaning ---- ------- 000 Command completed successfully. 100 Access denied. Try the AUTHENTICATE command? 200 Command or argument not supported. Check capabilities. 300 Authentication failed. 900 Other error. 2.4 SSTP Objects SSTP uses a very simple object format to transport data from one server to another. This allows the protocol to be very simple, yet easily extended to handle many different kinds of data. This format is called the Simplegram format and it is described in the next section. Specific SSTP object types are listed in the Object Types section below and described where they are used. 2.4.1 Simplegrams Whenever a large or extensible chunk of data needs to be sent, SSTP Hanna Expires 17-Jan-96 [Page 4] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT uses the Simplegram format [4] to send the data. This format is used by the vCalendar and vCard specifications, and it's a convenient way of communicating objects in an extensible, general-purpose fashion. A capsule summary of the Simplegram format appears in the next paragraph, although the original specification should be consulted for details. Several different object types are used in different parts of the SSTP protocol, including SSTP-Authentication objects, SSTP-Query objects, and SSTP-Storage objects. These types are defined in the Object Types section below. A Simplegram is a series of lines of ASCII text that represent one or more objects. Each object begins with a begin delimiter of the form "BEGIN: object-type" and ends with an end delimiter of the form "END: object-type". Between these delimiters come a sequence of property- value pairs of the form "PROPERTY-NAME[params]: value". Standard params include TYPE, VALUE, ENCODING, CHARSET, and LANGUAGE. Values are a single line of ASCII text unless ENCODING is BASE64 or QUOTED- PRINTABLE, in which case multiline values are permitted, ending at the first line that begins with a non-white space character. 2.4.2 Object Types Here is a list of object types defined in this document. For a description of each type, see the section where it is used. Other object types may be defined in SSTP protocol extensions. If an SSTP server encounters a type is does not recognize, it MUST return a result code of 200. SSTP-Authentication-Password SSTP-Stored-Object-Create-Request SSTP-Stored-Object-Change-Request SSTP-Stored-Object-Delete-Request SSTP-Stored-Object-Create-Result SSTP-Stored-Object-Change-Result SSTP-Stored-Object-Delete-Result SSTP-Query-Capability SSTP-Query-Results-Capability SSTP-Capability-Commands SSTP-Capability-Authentication SSTP-Capability-Queries SSTP-Capability-Descriptors SSTP-Descriptor-Event SSTP-Query-Busy-Time SSTP-Query-Results-Busy-Time SSTP-Busy-Time SSTP-Query-Calendar SSTP-Query-Results-Calendar Hanna Expires 17-Jan-96 [Page 5] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT 2.5 Stored Objects SSTP objects are purely transient. They are used only to transfer information from the SSTP client to the SSTP server. However, SSTP's main business is communicating information about stored objects. These are objects such as events that continue to exist even when no SSTP session is running. SSTP doesn't care where or how stored objects are stored, but it does make certain requirements on these objects so that they can be managed and referenced properly. Each stored object is owned by one SSTP server (the object owner), which is responsible for storing the master copy of the object, accepting requests to change the object, and distributing changes to other servers. Each stored object also has an object id, which is a string of printable ASCII characters assigned by the object owner. Together with the owner's server id, this object id uniquely identifies the object. Since SSTP does not describe where or how stored objects are stored, it cannot specify their exact format or content either. Instead, it defines specific types of SSTP objects called Stored Object Descriptors that provide a standard way of describing these stored objects. For instance, the Event Descriptor is an SSTP object that describes events, including start and end dates, attendees, etc. For information about specific Stored Object Descriptors, see the Scheduling Objects section below. 2.6 Server IDs SSTP servers are identified with a server ID, which must be an absolute DNS name (also known as a Fully Qualified Domain Name or FQDN). Server IDs are used to identify servers and to establish sessions with them. See the section on Establishing an SSTP Session below for more information. Because of the nature of DNS, a single server may have more than one server ID. However, each server ID resolves to only a single server. 2.7 User IDs SSTP manages meetings and events for users (or user equivalents such as meeting rooms). SSTP users are identified with a user id of the form user@server, where server is an SSTP server ID and user is a string of printable ASCII characters (values 32 to 126 decimal), not including an at sign ("@") or comma (","). Hanna Expires 17-Jan-96 [Page 6] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT Several user IDs may refer to the same user or even the same user account. For instance, hanna@on.com, shanna@on.com, and steve@sstp.on.com might all refer to the same account. hanna@homebiz.com might refer to a different account for the same user. staff@homebiz.com might refer to more than one user. Any aliasing or forwarding along these lines is the responsibility of the SSTP server referred to in the user ID. Other SSTP servers and clients should just treat each user ID as a single user. 2.8 Establishing an SSTP Session Whenever an SSTP client wants to contact an SSTP server with a certain ID, a DNS lookup on this name is performed and the TEXT records for this name are examined. If one of these records begins with "SSTP:", the rest of this record is taken to be a DNS name. A lookup is performed on this name and the A record is used to fetch an IP address. A TCP connection can now be made to the SSTP port (port 9243 for now) on this host. If no TEXT records are found for a server ID, the A record for this name is fetched and a TCP connection is made to the SSTP port on this host. If this process fails, the host in question cannot be contacted at this time. The SSTP client can try again later. As soon as a connection is established, the SSTP server must send a greeting line of the form 000 SSTP-1.0 [comments] CRLF. If an SSTP client receives a greeting line that does not begin with 000 SSTP- 1.0, it MUST close the connection because an incompatible version of SSTP is being used. It is hoped that the extensibility mechanisms built into the protocol will avoid any need to change the basic protocol. If no greeting line is received within a certain timeout, the SSTP client MAY close the connection. 3 Commands 3.1 AUTHENTICATE Arguments: auth-object Reply: 000 [auth-object] - Authentication proceeding or completed 200 - Command or argument not supported 300 - Authentication failed 900 - Other error Hanna Expires 17-Jan-96 [Page 7] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT The AUTHENTICATE command conducts an authentication process with the server. This process may be used to establish client and/or server identity and to begin encryption of the session. Depending on the policy of a given server, some or all operations may be restricted depending on the identity of the client. In order to support many different authentication techniques, the auth-object is a Simplegram containing a single object. The type of this object determines the authentication scheme used. If the object's type is not supported by the server, a 200 reply is sent. Otherwise, the object is passed to the appropriate authentication method. The object's content may vary depending on the method. If authentication fails, a 300 reply is sent. If it succeeds, a 000 reply is sent, perhaps with an auth-object. Some authentication methods may require several AUTHENTICATE commands to complete the authentication process. For instance, they may return a challenge key in the auth-object of their first reply. The client might then have to respond with another AUTHENTICATE command including a challenge response. Eventually, the authentication method would return an error reply or a success reply with an auth- object that indicates that the exchange is over and the client has been authenticated. The form of this exchange and the content of the auth-object is particular to the authentication method being used. Some authentication methods may enable encryption of the session. This is up to the authentication method and may be negotiated between the client and the server using the auth-objects, as defined in the description of authentication methods below. Whatever encryption is used, the plaintext of the session will remain the same. Note that the identity established by the AUTHENTICATE command may not correspond to a specific user ID. For instance, it could correspond to a trusted entity which is allowed to SUBMIT objects. 3.1.1 SSTP-Authentication-Password An object of type SSTP-Authentication-Password is used to send an account name and plaintext password to an SSTP server. This is the most basic form of authentication available with SSTP and does not provide for encryption. SSTP servers need not support this authentication technique. The ACCOUNT property contains an account name. The PASSWORD property contains a password. Hanna Expires 17-Jan-96 [Page 8] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT 3.2 QUIT Arguments: none Reply: 000 - No error The QUIT command terminates the current SSTP session. The server will send a 000 result code and terminate the session. The main point of having this command is so that the server can distinguish between normal and abnormal session completion. 3.3 SUBMIT Arguments: submission Reply: 000 submission-results - Submission accepted 100 - Access denied 200 - Command or argument not supported 900 - Other error The SUBMIT command submits stored object changes to the server. These changes are sent as a series of create, change, or delete request objects. If the command completes successfully, the server sends a 000 reply and a series of submission result objects, one for each request sent with the command. Successful completion of the SUBMIT command does not mean that all of the changes requested were made. It only means that they were received and attempted. The submission result objects must be examined and matched up with the requests sent to see what the outcome of each request was. This allows several requests to be submitted at once and have some succeed and some fail. If no changes can be performed with the identity that has been established, a 100 reply will be sent. If some part of the submission is not recognized or supported, a 200 reply will be sent. If any other error occurs, a 900 will be sent. 3.3.1 SSTP-Stored-Object-Create-Request Objects Hanna Expires 17-Jan-96 [Page 9] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT An object of type SSTP-Stored-Object-Create-Request is used to create a stored object on a server. The DATA property is a Stored Object Descriptor that describes the object to be created. If the object is already owned by another server and is simply being replicated to this server, several properties that identify the object precede the DATA property. The OWNER property is a server-id. The ID property is an object id. The server attempts to create an object using the data supplied. It returns the results in an SSTP-Stored-Object-Create-Result object. 3.3.2 SSTP-Stored-Object-Change-Request Objects An object of type SSTP-Stored-Object-Change-Request is used to change a stored object. The OWNER property is a server-id. The ID property is an object id. The DATA property is a Stored Object Descriptor that describes the changes being requested. The server attempts to change the specified object using the data supplied. It returns the results in an SSTP-Stored-Object-Change- Result object. 3.3.3 SSTP-Stored-Object-Delete-Request Objects An object of type SSTP-Stored-Object-Delete-Request is used to delete a stored object. The OWNER property is a server-id. The ID property is an object id. The server attempts to delete the specified object. It returns the results in an SSTP-Stored-Object-Delete-Result object. 3.3.4 SSTP-Stored-Object-Create-Result Objects An object of type SSTP-Stored-Object-Create-Result is used to return the results of an SSTP-Stored-Object-Create-Request object sent to the server. The RESULT property is a result code in the same format used for SSTP commands, that is a numerical result code followed by an optional textual error message. If the request completed successfully, the result code is 000. If the object had no owner, OWNER and ID properties describing the new object appear after the RESULT property. If an error occurred, the result code is non-zero and no other properties follow the RESULT property. Likely result codes include 100 (Access denied), 200 (Command or argument not supported), and 900 (Other error). Hanna Expires 17-Jan-96 [Page 10] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT 3.3.5 SSTP-Stored-Object-Change-Result Objects An object of type SSTP-Stored-Object-Change-Result is used to return the results of an SSTP-Stored-Object-Change-Request object sent to the server. The RESULT property is a result code in the same format used for SSTP commands, that is a numerical result code followed by an optional textual error message. If the request completed successfully, the result code is 000. If the object is owned by the server accepting the request, a DATA property describing the latest version of the object appear after the RESULT property. The DATA returned to the client may not include a complete description of the object. If the changes to the object are slight (especially if they only include the changes made in this request), little or no data need be included in the data object. If no data is needed, no DATA object need be sent. If an error occurred, the result code is non-zero and no other properties follow the RESULT property. Likely result codes include 100 (Access denied), 200 (Command or argument not supported), and 900 (Other error, such as no such object). 3.3.6 SSTP-Stored-Object-Delete-Result Objects An object of type SSTP-Stored-Object-Delete-Result is used to return the results of an SSTP-Stored-Object-Delete-Request object sent to the server. The RESULT property is a result code in the same format used for SSTP commands, that is a numerical result code followed by an optional textual error message. If the request completed successfully, the result code is 000. If an error occurred, the result code is non- zero. Likely result codes include 100 (Access denied), 200 (Command or argument not supported), and 900 (Other error). 3.4 QUERY Arguments: query Reply: 000 query-results - Query completed 100 - Access denied 200 - Command or argument not supported 900 - Other error Hanna Expires 17-Jan-96 [Page 11] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT The QUERY command submits a query object to the server, which returns the results in a query-results object. If this query cannot be performed with the identity that has been established, a 100 reply will be sent. If the query object received is not recognized or supported, a 200 reply will be sent. If any other error occurs (internal error, no such user, etc.), a 900 will be sent. For information about specific types of query and query results objects, see the Scheduling Objects section below. 3.4.1 SSTP-Query-Capability Objects An object of type SSTP-Query-Capability is used to find out what capabilities an SSTP server supports. There is one optional property for this object, the CAPABILITY-TYPE property. If this property is present, it requests that the server return only objects of the specified type in the SSTP-Query-Results-Capability object. This query object MUST be supported by all SSTP servers. 3.4.2 SSTP-Query-Results-Capability Objects An object of type SSTP-Query-Results-Capability is used to return the results of a capabilities query. The object contains a series of objects that describe various capabilities the server has. If the query being answered included a CAPABILITY-TYPE property, all capabilities that don't match that type are filtered out. Otherwise, all capabilities supported by the server will be returned. The client SHOULD read the objects, skipping those that it doesn't understand and parsing those that it does. If it doesn't find a capability that it was hoping for, it SHOULD assume that the server doesn't have this capability. The set of capabilities cannot change throughout a session, so the client MAY execute a single capabilities query at the start of a session. Actually, the client need not execute the query at all if it's prepared to handle 200 result codes. The standard set of capability objects is described in the next few sections. 3.4.3 SSTP-Capability-Commands Objects Hanna Expires 17-Jan-96 [Page 12] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT An object of type SSTP-Capability-Commands is used to describe the commands an SSTP server supports. The COMMAND property is the name of a single command. This property MAY appear multiple times within the same object. In fact, it usually will. Any result from an unrestricted capabilities query MUST include one object of this type. Under no circumstances may more than one of object of this type be included in a single SSTP-Query-Results-Capability object. 3.4.4 SSTP-Capability-Authentication Objects An object of type SSTP-Authentication is used to describe the authentication schemes an SSTP server supports. The AUTHENTICATION property is a single object type. This property MAY appear multiple times within the same object if more than one authentication scheme is supported. If no authentication schemes are supported, the SSTP server MUST NOT include an object of type SSTP-Authentication in any SSTP-Query-Results-Capability object and MUST NOT include the AUTHENTICATE command in any SSTP-Capability-Commands object. Under no circumstances may more than one of object of this type be included in a single SSTP-Query-Results-Capability object. 3.4.5 SSTP-Capability-Queries Objects An object of type SSTP-Capability-Queries is used to describe the query object types an SSTP server supports. The QUERY property is a single object type. This property MAY appear multiple times within the same object. In fact, it usually will. Since the SSTP-Query- Capabilities query is required, any result from an unrestricted capabilities query MUST include one object of this type and this object MUST include a QUERY property with the value SSTP-Query- Capabilities. Under no circumstances may more than one of object of this type be included in a single SSTP-Query-Results-Capability object. 3.4.6 SSTP-Capability-Descriptors Objects An object of type SSTP-Capability-Descriptors is used to describe the stored object descriptors an SSTP server supports. The DESCRIPTOR property is a single object type. This property MAY appear multiple times within the same object. In fact, it usually will. Any result from an unrestricted capabilities query MUST include one object of this type. Under no circumstances may more than one of object of this type be included in a single SSTP-Query-Results-Capability object. 4 Scheduling Objects These objects describe and apply to scheduling issues in particular. Hanna Expires 17-Jan-96 [Page 13] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT 4.1 Stored Object Descriptors Stored object descriptors are SSTP objects that are used to describe stored objects. They are used in object create and change requests submitted with the SUBMIT command and may be used in future query object types. 4.1.1 Event Descriptors An SSTP-Descriptor-Event object is used to describe events. The properties of this object include all of those described in the vCalendar specification for vEvent objects [3], with several additions. Also, none of the properties are required. This is important for object change requests, since it's common to change only a few properties of an object. For object create requests, the DTSTART and DTEND properties are required. Here is a description of the extra properties defined by this specification. The LOCATION property specifies a textual description of the event's location. The GUESTS property specifies a list of user ids, separated by commas. The PROPOSER property specifies the user id of the user proposing the event. This may be used when displaying the event to guests. Information about users may be stored in user information properties. These properties are named USER-INFO-property-name-user-id, where user-id is the user id in question and property-name is the property name. None of these properties are required. Some are only valid if the user is included in the guest property. Others are not. Most SSTP servers will allow a user (or their SSTP server) to change that user's information properties. The ACK user information property may have the values Y to indicate that this guest has confirmed their attendance or N to indicate that they have indicated they will not attend. The COMMENTS guest information property may include textual comments from the guest. The FULL-NAME user information property is the full name of the user. Hanna Expires 17-Jan-96 [Page 14] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT 4.2 Query Objects and Query Result Objects Query objects are SSTP objects that are used to define queries. They are used with the QUERY command. Query result objects are SSTP objects that are used to return the results of a query. 4.2.1 Busy Time Query Objects An object of type SSTP-Query-Busy-Time is used to find out when a user is busy. The USER property is the user-id of the user being queried. The DTSTART property is the date and time when the query period starts. The DTEND property is the date and time when the query period ends. 4.2.2 Busy Time Query Result Objects An SSTP-Query-Results-Busy-Time object is used to return the results of a busy time query. The object contains a series of SSTP-Busy-Time objects that represent busy times on the user's calendar, sorted in order of increasing start times. Each SSTP-Busy-Time object has only two properties: DTSTART and DTEND. These properties are identical to those used in vEvent objects. Depending on the server's configuration and implementation, contiguous or overlapping busy time objects may or may not be merged. Busy time includes any time that the user is not available for meetings, such as days off or evenings. 4.2.3 Calendar Query Objects An object of type SSTP-Query-Calendar is used to retrieve the contents of a user's calendar. The USER property is the user-id of the user being queried. The DTSTART property is the date and time when the query period starts. The DTEND property is the date and time when the query period ends. 4.2.4 Calendar Query Result Objects An SSTP-Query-Results-Calendar object is used to return the results of a calendar query. The object contains a series of SSTP- Descriptor-Event objects that represent events on the user's calendar, sorted in order of increasing start times. Recurring events should only be included once, even if they appear on the user's calendar several times during the query period. Events which this user has not indicated they will attend should not be included. Hanna Expires 17-Jan-96 [Page 15] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT Depending on the server's configuration and implementation and the access level of the current authorization, some information may be stripped out of these objects. For instance, some events may be visible to others while others are marked private. 4.2.5 Off Calendar Query Objects An object of type SSTP-Query-Off-Calendar is used to retrieve a list of events that include a certain user, but aren't on that user's calendar. The USER property is the user-id of the user being queried. The most common use of this query is to retrieve a set of events that include the user as a guest, but for which attendance has not yet been confirmed. 4.2.6 Off Calendar Query Result Objects An SSTP-Query-Results-Off-Calendar object is used to return the results of an off calendar query. The object contains a series of SSTP-Descriptor-Event objects that represent events, sorted in order of increasing start times. Depending on the server's configuration and implementation and the access level of the current authorization, some information may be stripped out of these objects. For instance, some events may be visible to others while others are marked private. 4.2.7 Other Query Objects Other kinds of query objects can be defined. For instance, an object query could return data describing a specific object. An object search query could search for objects based on their properties. 5 Levels of Support There are several levels at which a scheduling product can support SSTP. First, it can support SSTP as a means for interoperating with other scheduling systems. Second, it can allow user agents to access user calendars via SSTP. Third, it can support SSTP only as a client, using the protocol to act as a user agent for a scheduling system. All of these levels can be distinguished using the capabilities query. More advanced levels of support are possible using the extension mechanisms described herein. These are just several profiles which may be common. 5.1 Required Support Hanna Expires 17-Jan-96 [Page 16] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT All SSTP servers MUST support the SUBMIT, QUIT, and QUERY commands. They MUST be able to parse these commands and respond properly if they do not support one of the objects provided with the SUBMIT or QUERY commands. They also MUST support SSTP-Query-Capability objects and respond to them with at least SSTP-Capability-Commands and SSTP- Capability-Queries objects. SSTP servers are not required to support any other commands or queries. They are also not required to support any object descriptors. Of course, an SSTP server won't be much good if it doesn't support changing or querying objects. 5.2 Interoperating with Other Scheduling Systems To transfer data with other scheduling systems, a scheduling system must be able to use SSTP both as a client and as a server. When an event created on its system needs to be transferred to guests on another system, it must contact that other system as an SSTP client and attempt to create a stored object for that event on the other system, marking itself as the owner and assigning the event a unique ID. If this event changes, it SHOULD contact the other system and change the stored object to reflect these changes. If the guest on the other system responds to the event, the other system will contact the events owner using SSTP. This owner must respond as an SSTP server and allow the other system to change the user information properties of the guest in question. This means that as an SSTP server the system must support the SSTP- Descriptor-Event object type, allowing other systems to change the user information of guests and create events that are owned by those foreign systems. If one-way interoperability is desired, only part of this need be implemented. Optionally, the system may support the SSTP-Query-Busy-Time object either by using it to query remote systems about the availability of their users or by responding to it with information about the availability of its own users. Implementing the AUTHENTICATE command and allowing the administrator to configure a set of trusted server accounts would be wise. 5.3 Supporting User Agents To support user agents, a scheduling system must allow them to create events and assign those events unique IDs. It must also support the SSTP-Query-Calendar object type, which allows user agents to view Hanna Expires 17-Jan-96 [Page 17] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT their calendars or those of other users. Supporting the SSTP-Query- Busy-Time object is important, too. Implementing the AUTHENTICATE command is almost a must. 5.4 Acting as a User Agent To act as a user agent, a program need only use SSTP as a client to connect to an SSTP server, authenticate, and download its calendar and off-calendar events. Then it can create events, change them, or respond to off-calendar events. This will be especially handy with Network Computers and other systems that don't have persistent storage. 6 Security Considerations The AUTHENTICATE command may be used to authenticate the connection and optionally to begin an encrypted session. Scheduling systems may be configured so that they require authentication or encryption before they allow certain commands. If no authentication is required or a poor authentication scheme is used, SSTP could be used to access or modify scheduling data improperly. If encryption is not used, confidential data could be read. 7 Examples Here are several typical SSTP sessions, with comments. Comments are marked by lines beginning with #. Lines sent by the SSTP client begin with "C: ". Lines sent by the SSTP server begin with "S: ". 7.1 SSTP Client-Server Session In this session, SSTP is being used to communicate within a scheduling system between a client agent and an SSTP server (on.com). The client agent is creating an event proposed by shanna@on.com with libby@sun.com as a guest. S: 000 SSTP-1.0 Welcome to on.com. C: AUTHENTICATE = C: BEGIN: SSTP-Authenticate-Password C: ACCOUNT: shanna@on.com C: PASSWORD: freak7 C: END: SSTP-Authenticate-Password C: C: = S: 000 C: SUBMIT = C: BEGIN: SSTP-Stored-Object-Create-Request C: DATA: Hanna Expires 17-Jan-96 [Page 18] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT C: BEGIN: SSTP-Descriptor-Event C: DTSTART: 19960815T1145 C: DTEND: 19960815T1245 C: PROPOSER: shanna@on.com C: DESCRIPTION: Lunch C: LOCATION: Mary Chung's Restaurant C: STATUS: TENTATIVE C: GUESTS: shanna@on.com, libby@east.sun.com C: USER-INFO-FULL-NAME-shanna@on.com: Steve Hanna C: USER-INFO-ACK-shanna@on.com: Y C: END: SSTP-Descriptor-Event C: END: SSTP-Stored-Object-Create-Request C: C: = S: 000 = S: BEGIN: SSTP-Stored-Object-Create-Result S: RESULT: 000 S: OWNER: on.com S: ID: ABJ249 S: END: Stored-Object-Create-Result S: S: = C: QUIT S: 000 7.2 SSTP Server-Server Session with Object Creation In this session, SSTP is being used to communicate the event proposed in the last section from on.com (acting as an SSTP client in this exchange) to the SSTP server for east.sun.com. S: 000 SSTP-1.0 Welcome to east.sun.com. C: SUBMIT = C: BEGIN: SSTP-Stored-Object-Create-Request C: OWNER: on.com C: ID: ABJ249 C: DATA: C: BEGIN: SSTP-Descriptor-Event C: DTSTART: 19960815T1145 C: DTEND: 19960815T1245 C: PROPOSER: shanna@on.com C: DESCRIPTION: Lunch C: LOCATION: Mary Chung's Restaurant C: STATUS: TENTATIVE C: GUESTS: shanna@on.com, libby@east.sun.com C: USER-INFO-FULL-NAME-shanna@on.com: Steve Hanna C: USER-INFO-ACK-shanna@on.com: Y Hanna Expires 17-Jan-96 [Page 19] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT C: END: SSTP-Descriptor-Event C: END: SSTP-Stored-Object-Create-Request C: C: = S: 000 = S: BEGIN: SSTP-Stored-Object-Create-Result S: RESULT: 000 S: END: Stored-Object-Create-Result S: S: = C: QUIT S: 000 7.3 SSTP Server-Server Session with Object Change In this session, SSTP is being used to communicate libby@east.sun.com's response to the event proposed in the last section. In this communication, east.sun.com is acting as an SSTP client and on.com is acting as an SSTP server. Note that on.com changes the event's status from TENTATIVE to CONFIRMED because all guests have indicated that they plan to attend. Alternatively, this change might be communicated at a later time via a separate session from on.com to east.sun.com. S: 000 SSTP-1.0 Welcome to on.com. C: SUBMIT = C: BEGIN: SSTP-Stored-Object-Change-Request C: OWNER: on.com C: ID: ABJ249 C: DATA: C: BEGIN: SSTP-Descriptor-Event C: USER-INFO-ACK-libby@east.sun.com: Y C: END: SSTP-Descriptor-Event C: END: SSTP-Stored-Object-Change-Request C: C: = S: 000 = S: BEGIN: SSTP-Stored-Object-Change-Result S: RESULT: 000 S: DATA: C: BEGIN: SSTP-Descriptor-Event C: STATUS: CONFIRMED C: END: SSTP-Descriptor-Event S: END: Stored-Object-Change-Result S: S: = Hanna Expires 17-Jan-96 [Page 20] draft-hanna-sstp-00.txt SSTP INTERNET DRAFT C: QUIT S: 000 8 Formal Syntax Here is a first draft of a formal syntax for SSTP. The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [5]. args ::= *LWSP_char [message] *LWSP_char [object_args] atom ::= 1*ATOM_CHAR ATOM_CHAR ::= atom_specials ::= SPACE / CTL / "=" CHAR ::= command ::= command_name args CRLF command_name ::= "AUTHENTICATE" / "QUERY" / "QUIT" / "SUBMIT" / extended_cmd CR ::= CRLF ::= CR LF CTL ::= digit ::= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" extended_cmd ::= atom HTAB ::= LF ::= LWSP-char ::= SPACE / HTAB message ::= 1*