[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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       ::= <any CHAR except atom_specials>

   atom_specials   ::= SPACE / CTL / "="

   CHAR            ::= <any 7-bit US-ASCII character except NUL,
                                           0x01 - 0x7f>

   command         ::= command_name args CRLF

   command_name    ::= "AUTHENTICATE" / "QUERY" / "QUIT" / "SUBMIT" /
                          extended_cmd

   CR              ::= <ASCII CR, carriage return, 0x0C>

   CRLF            ::= CR LF

   CTL             ::= <any ASCII control character and DEL,
                           0x00 - 0x1f, 0x7f>

   digit           ::= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

   extended_cmd    ::= atom

   HTAB            ::= <ASCII HT, horizontal-tab>

   LF              ::= <ASCII LF, line feed, 0x0A>

   LWSP-char       ::= SPACE / HTAB

   message         ::= 1*<any CHAR except "=" and CTLs>

   object          ::= <Simplegram object, as defined in [4]>

   object_args     ::= "=" CRLF 1*object CRLF "="



Hanna                      Expires 17-Jan-96                   [Page 21]


draft-hanna-sstp-00.txt           SSTP                    INTERNET DRAFT


   result          ::= result_code args CRLF

   result_code     ::= digit digit digit

   SPACE           ::= <ASCII SP, space>

9 References

   [1]     R. Braden.
     "Requirements for Internet hosts - application and support." STD 3,
     RFC 1123, IETF, October 1989.

   [2]     US-ASCII. Coded Character Set - 7-Bit American Standard Code for
     Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.

   [3]     VERSIT Consortium
     "vCalendar: The Electronic Calendar and Scheduling Exchange Format",
     Draft Version 0.3, http://www.versit.com, April 25, 1996.

   [4]     VERSIT Consortium
     "Simplegram Specification"

   [5]     D. Crocker.
     "Standard for the Format of ARPA Internet Text Messages." STD 11,
     RFC 822, IETF, University of Delaware, August 1982.

10 Author's Address

   Stephen R. Hanna
   ON Technology Corporation
   One Cambridge Center
   Cambridge, MA 02142

   Phone: (617) 692-3153

   EMail: shanna@on.com

11 Unresolved Issues

   What should client or server do if the other one violates the
   protocol?

   Should support todos and perhaps other data. This should be a simple
   matter.

   Might want to support notification from server to client.

   Does the Simplegram specification really exist? If not, we should



Hanna                      Expires 17-Jan-96                   [Page 22]


draft-hanna-sstp-00.txt           SSTP                    INTERNET DRAFT


   write one up.

   Might want to support store and forward communications between client
   and server.















































Hanna                      Expires 17-Jan-96                   [Page 23]