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]