draft-ietf-calsch-irip-01.txt   draft-ietf-calsch-irip-02.txt 
Network Working Group Andre Courtemanche/CS&T Network Working Group Andre Coutemanche/CS&T
Internet Draft Steve Mansour/Netscape Internet Draft Steve Mansour/Netscape
<draft-ietf-calsch-irip-01.txt> Pete O'Leary/Amplitude <draft-ietf-calsch-irip-02.txt Pete O'Leary/Amplitude
Expires six months after August 3, 1998 Expires six months from: November 19, 1998
ICalendar Real-time Interoperability Protocol (IRIP) ICalendar Real-time Interoperability Protocol (IRIP)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas, and
andits working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or made obsolete by other Internet-Drafts may be updated, replaced, or made obsolete by other
documents at any time. It is not appropriate to use Internet-Drafts as documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress". "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
This document specifies a binding from the iCalendar This document specifies a binding from the iCalendar
Transport-independent Interoperability Protocol [ITIP] to a real-time Transport-independent Interoperability Protocol [ITIP] to a real-time
transport. Calendaring entries defined by the iCalendar Object Model transport. Calendaring entries defined by the iCalendar Object Model
[ICAL] are composed using constructs from [RFC-2045], [RFC-2046], [ICAL] are composed using constructs from [RFC-2045], [RFC-2046],
[RFC-2047], [RFC-2048] and [RFC-2049]. [RFC-2047], [RFC-2048] and [RFC-2049].
skipping to change at line 50 skipping to change at line 50
Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
More information about the IETF CALSCH working group activities can be More information about the IETF CALSCH working group activities can be
found on the IMC website at http://www.imc.org, the IETF website at found on the IMC website at http://www.imc.org, the IETF website at
http://www.ietf.org/html.charters/calsch-charter.html. Refer to the http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this document for further information on how to references within this document for further information on how to
access these various documents. access these various documents.
Distribution of this document is unlimited. Comments and suggestions Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent to the authors. for improvement should be sent to the authors.
Courtemanche/Mansour/O'Leary 1 Expires February 1998 1 Introduction
1. Introduction
This binding document provides the transport specific information This binding document provides the transport specific information
necessary convey iCalendar Transport-independent Interoperability necessary convey iCalendar Transport-independent Interoperability
Protocol [ITIP] over a real-time transport. Protocol [ITIP] over a real-time transport.
1.1 Related Memos 1.1 Related Memos
Implementors will need to be familar with several other memos that, Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and along with this memo, form a framework for Internet calendaring and
scheduling standards. scheduling standards.
This document - specifies an Internet email binding for [ITIP]. This document - specifies a real-time binding for [ITIP].
[ICMS] - specifies a common terminology and abstract;
[ICAL] - specifies a core specification of objects, data types, - [ICAL] specifies a core specification of objects, data types,
properties and property parameters; properties and property parameters;
[ITIP] - specifies an interoperability protocol for scheduling - [ITIP] specifies an interoperability protocol for scheduling between
between different implementations; different implementations;
[IMIP] - specifies a messaging-based protocol binding for [ITIP]. - [IMIP] specifies a messaging-based protocol binding for [ITIP].
This memo does not attempt to repeat the specification of concepts or This document does not attempt to repeat the specification of concepts
definitions from these other memos. Where possible, references are made or definitions from these other memos. Where possible, references are
to the memo that provides for the specification of these concepts or made to the memo that provides for the specification of these concepts
definitions. or definitions.
1.2 Formatting Conventions 1.2 Formatting Conventions
The mechanisms defined in this memo are defined in propose. In order to The mechanisms defined in this memo are defined in propose. In order to
refer to elements of the calendaring and scheduling model, core object refer to elements of the calendaring and scheduling model, core object
or interoperability protocol defined in [ICMS], [ICAL] and [ITIP] some or interoperability protocol defined in [ICMS], [ICAL] and [ITIP] some
formatting conventions have been used. formatting conventions have been used.
Calendaring and scheduling roles defined by [ICMS] are referred to in Calendaring and scheduling roles defined by [ICMS] are referred to in
quoted-strings of text with the first character of each word in upper quoted-strings of text with the first character of each word in upper
case. For example, "Organizer" refers to a role of a "Calendar User" case. For example, "Organizer" refers to a role of a "Calendar User"
within the scheduling protocol defined by [ITIP] within the scheduling protocol defined by [ITIP].
Calendar components defined by [ICAL] are referred to with capitalized, Calendar components defined by [ICAL] are referred to with capitalized,
quoted-strings of text. All calendar components start with the letter quoted-strings of text. All calendar components start with the letter
"V". For example, "VEVENT" refers to the event calendar component, "V". For example, "VEVENT" refers to the event calendar component,
"VTODO" refers to the to-do calendar component and "VJOURNAL" refers to "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to
the daily journal calendar component. the daily journal calendar component.
Scheduling methods defined by [ITIP] are referred to with capitalized, Scheduling methods defined by [ITIP] are referred to with capitalized,
quoted-strings of text. For example, "REQUEST" refers to the method for quoted-strings of text. For example, "REQUEST" refers to the method for
requesting a scheduling calendar component be created or modified, requesting a scheduling calendar component be created or modified,
"REPLY" refers to the method a recipient of a request uses to update "REPLY" refers to the method a recipient of a request uses to update
their status with the "Organizer" of the calendar component. their status with the "Organizer" of the calendar component.
Properties defined by [ICAL] are referred to with capitalized, Properties defined by [ICAL] are referred to with capitalized,
quoted-strings of text, followed by the word "property". For example, quoted-strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey the "ATTENDEE" property refers to the iCalendar property used to convey the
calendar address of a calendar user. calendar address of a calendar user.
Property parameters defined by [ICAL] are referred to with lower case, Property parameters defined by [ICAL] are referred to with lower case,
Courtemanche/Mansour/O'Leary 2 Expires February 1998
quoted-strings of text, followed by the word "parameter". For example, quoted-strings of text, followed by the word "parameter". For example,
"VALUE" parameter refers to the iCalendar property parameter used to "VALUE" parameter refers to the iCalendar property parameter used to
override the default data type for a property value. override the default data type for a property value.
2. Architecture 2 Architecture
iRIP enables real-time interoperability between scheduling systems [IRIP] enables real-time interoperability between scheduling systems
using the iCalendar [ICAL] format for information exchange. iRIP is using the iCalendar [ICAL] format for information exchange. [IRIP] is
designed primarily to allow Calendar Services (CS) as defined in [ICSM] designed primarily to allow Calendar Services (CS) as defined in [ICSM]
to forward real-time requests on behalf of Calendar User Agents (CUA). to forward real-time requests on behalf of Calendar User Agents (CUA)
The goal of iRIP is to allow two or more CS's to establish connections and receive real-time responses. The goal of [IRIP] is to allow two or
between them and operate as a single Calendar Domain. more CS's to establish connections with each other. However, the design
of [IRIP] does not preclude its use from CUA directly to CS. [IRIP]
allows a CS to initiate a session and perform operations on behalf of
multiple CUA's without the need to reauthenticate the session for each
CUA.
iRIP allows a CS to initiate a session and perform operations on behalf The sections and examples below refer to a "user", a "sender", and a
of multiple CUA's without the need to reauthenticate the session for "receiver". For purposes of this document these terms are defined as
each CUA. follows:
The design of iRIP does not preclude its use from a CUA directly to user - the CU that initiates a request.
a CS. iRIP does not support client access functions such as calendar sender - the agent used to contact a receiving device, send commands,
browsing, retrieval, and search. and receive replies.
Terms used in the following discussion include: receiver - the agent that accepts commands and sends replies.
User - the CU that initiates a request. The sender and receiver can take on varying roles of CUA and CS as
Sender - the agent used to contact a receiving device, send described in [ICMS].
commands, and receive replies
Receiver - the agent that accepts commands and sends replies.
The Sender and Receiver can take on varying roles of CUA and CS as [IRIP] allows two CS's to establish different levels of trust. When an
described in [ICMS]. iRIP allows two CS's to establish different [IRIP] connection is first established, both parties to the connection
levels of trust so that scheduling operations can be performed as authenticate one another using the AUTHENTICATE command. The Sender can
efficiently as possible. When an iRIP connection is first established, then initiate commands that the Receiver MUST interpret relative to the
both parties to the connection authenticate one another using the Sender's access control. The AUTHENTICATE command supports proxy
AUTHENTICATE command. The Sender can then initiate commands which the operations via [SASL].
Receiver MUST interpret relative to the Sender's access control. The
AUTHENTICATE command supports proxy operations via [SASL].
2.1 State Diagram 1.3 State Diagram
An iRIP session begins when a TCP/IP connection is made on port 5228. An [IRIP] session begins when a TCP/IP connection is made on port 5228.
The protocol begins in the Connected state. The AUTHENTICATE command, The protocol begins in the Connected state. The AUTHENTICATE command,
when successful, begins the Authenticated state. From the Authenticated when successful, begins the Authenticated state. From the Authenticated
state, the sender can initiate a request using the RECIPIENT command. state, the sender can initiate a request using the RECIPIENT command.
The Sender can then issues as many RECIPIENT commands as the operation The Sender can then issues as many RECIPIENT commands as the operation
in progress requires until sending an ICALDATA command. After in progress requires until sending an ICALDATA command. After
completing the ICALDATA command, the Sender must wait for a response completing the ICALDATA command, the Sender must wait for a response
from the receiver. The Receiver can respond that the request has been from the receiver. The Receiver's response can indicate that the
completed or that the request could not be completed in the time request has been completed or that the request could not be completed
specified by the Sender. When the Receive has ended, the Sender returns in the time specified by the Sender. When the response has ended, the
to the Authenticated state where another request can be initiated. Sender returns to the Authenticated state where another request can be
Implementations should be prepared to handle a DISCONNECT at any point initiated. Implementations should be prepared to handle a DISCONNECT
in this state diagram. at any point in this state diagram.
Courtemanche/Mansour/O'Leary 3 Expires February 1998 +---------SWITCH-----------+ +------------+
+----------SWITCH------------+ +---------------+ | | +-DISCONNECT->| TERMINATED |
| | | | | | | +------------+
V | V | V | | A
+------------+ +---------------+ | +------------+ +---------------+ |
| Connected |--AUTHENTICATE-->| Authenticated |-----+ | | Connected |--AUTHENTICATE-->| Authenticated |----ERROR--+
+------------+ +---->| (Proxy) | | | +------------+ | |<--------+
| +---------------+ | | +--------------ABORT--------->| (Proxy) | |
+--RECIPIENT---+ | | | | | +---->| |<---+ |
| | +----------+ | | | | +---------------+ | |
| | | | | +--RECIPIENT--+ | | | | |
+----------+ V | | | | | +--AUTHENTICATE--+ | | |
| Send |<---------------RECIPIENT----------------+ | +----------+ V | | COMPLETE
+----------+ | | Send |<---------------RECIPIENT--------+ | or
| | +----------+ | ABORT
ICALDATA ABORT/Complete | +--------COMPLETE or ERROR-------------+ |
| | ICALDATA | |
| | |
| +---------+ +--------+ | | +---------+ +--------+ |
+->| Receive |--(Response from Server)-->| Idle |---+ +->| Receive |--(Response from Server)-->| Idle |---+
+---------+ +--------+ +---------+ +--------+
A | A |
| | | |
+--------------CONTINUE---------------+ +--------------CONTINUE---------------+
2.2 Calendar Address 1.4 Calendar Address
Calendar addresses are URIs. IRIP uses the following forms of URI. Calendar addresses are URIs. IRIP uses the following forms of URI.
[protocol:]//host.domain[:port]/CSID irip://<host>:<port>/<relativeCALID>
mailto:CSID@host.domain
where: where:
CSID is an identifier that uniquely identifies the calendar store. <host> is address of the computer on which the IRIP server is
There is no implied structure in a CSID, it is an arbitrary string of running
characters. It may refer to the calendar of a user or of a resource
such as a conference room.
protocol is optional. Its default value is "IRIP". <port> is optional. Its default value is 5228.
port is optional. Its default value is 5228. <relativeCALID> is an identifier that uniquely identifies the calendar.
There is no implied structure in a relativeCALID, it is an arbitrary
string of characters. It may refer to the calendar of a user or of a
resource such as a conference room.
Examples: Examples:
mailto:user1@example.com
irip://calendar.example.com/user1 irip://calendar.example.com/user1
irip://calendar.example.com/conferenceRoomA irip://calendar.example.com/conferenceRoomA
irip://calendar.example.com/89798-098-zytytasd irip://calendar.example.com/89798-098-zytytasd
2.3 Bounded Latency 1.5 Bounded Latency
iRIP is designed so that the Sender can either obtain an immediate [IRIP] is designed so that the Sender can either obtain an immediate
response from a request or discover within a known amount of time that response from a request or discover within a known amount of time that
the request cannot be completed. When the Sender initiates a command the request cannot be completed. When the Sender initiates a command
that the Receiver cannot complete within a given amount of time, the that the Receiver cannot complete within a given amount of time, the
Receiver can return an error code to the Sender indicating this Receiver can return an error code to the Sender indicating this
condition. The Sender then issues either a CONTINUE or ABORT command. condition. The Sender then issues either a CONTINUE or ABORT command.
The ABORT command immediately terminates the command in progress. The The ABORT command immediately terminates the command in progress. The
CONTINUE command instructs the Receiver to continue processing the CONTINUE command instructs the Receiver to continue processing the
Courtemanche/Mansour/O'Leary 4 Expires February 1998
command. The ABORT command causes the Receiver to discard the current command. The ABORT command causes the Receiver to discard the current
command and return to the Authenticated state. command and return to the Authenticated state.
3. Commands 3 Protocol
In the examples below, lines preceded with "S:" refer to the Sender and 3.1 Commands
lines preceded with "R:" refer to the Receiver.
Reply codes MAY be followed by arbitrary text. The length of the reply Reply codes MAY be followed by arbitrary text. The length of the reply
code, any subsequent text, and the terminating <CRLF> MUST be l024 code, any subsequent text, and the terminating <CRLF> MUST be 1024
characters or less. characters or less. The length of a RECIPIENT command and its single
argument, and the terminating <CRLF> MUST be l024 characters or less.
Implementations may truncate RECIPIENT lines or reply code lines that
exceed 1024 characters.
3.1 ABORT In the examples below, lines preceded with "S:" refer to the Sender and
lines preceded with "R:" refer to the Receiver.
3.1.1 ABORT
The ABORT command is issued by the Sender to stop an ICALDATA request The ABORT command is issued by the Sender to stop an ICALDATA request
from being processed further. When the latency time is specified on the from being processed further. When the latency time is specified on the
ICALDATA command, the Receiver must issue a reply to the Sender within ICALDATA command, the Receiver must issue a reply to the Sender within
the specified time. The reply may be a reply code indicating that the the specified time. The reply may be a reply code indicating that the
server has not yet processed the request. The Sender must then tell server has not yet processed the request. The Sender must then tell
the server whether to continue or abort. the server whether to continue or abort.
The ABORT command can also be issued at any time by the Sender after The Sender can issue the ABORT command at any time after the ICALDATA
the ICALDATA command has been completed but before the Sender receives command has been completed but before the Sender receives a reply.
a reply.
Example: Example:
... ...
S: ICALDATA:10 S: ICALDATA:10
R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: quoted-printable S: Content-Transfer-Encoding: quoted-printable
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: ... S: ...
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
<10 seconds elapse...> <10 seconds elapse...>
R: . R: .
R: 7.0 TIMEOUT R: 2.0.2
S: ABORT S: ABORT
R: 2.0 OK R: 2.0.3
S: <sender can now begin another command or it can disconnect> S: <sender can now begin another command or it can disconnect>
3.2 AUTHENTICATE The Receiver will issue the 8.2 reply code if it receives an ABORT when
the ICALDATA command is not in progress. This could happen if the
Sender issues an ABORT command at a point in time after the Receiver
has completed the operation and issued the reply code but before the
Sender has actually received the reply code. For example:
The authentication mechanism used in iRIP is based on [SASL]. This S: ICALDATA:10
allows the iRIP senders and receivers to dynamically negotiate S: <an ICAL object>
authentication and encryption mechanisms. SASL defines authentication S: .
<10 seconds elapse...>
S: ABORT
R: 2.0
R: 8.2
In this case, the reply code 2.0 is in response to the [ICAL] object
and the reply code 8.2 is in response to the ABORT command.
3.1.2 AUTHENTICATE
The authentication mechanism used in [IRIP] is based on [SASL]. This
allows the [IRIP] senders and receivers to dynamically negotiate
authentication and encryption mechanisms. [SASL] defines authentication
methods such as ANONYMOUS and encapsulates concepts of PROXY used in methods such as ANONYMOUS and encapsulates concepts of PROXY used in
iRIP. [IRIP].
The AUTHENTICATE command is used by the client to identify itself to The AUTHENTICATE command is used by the client to identify itself to
the server. Authenticate is required before any other command can be the server. Authentication is required before the following commands
used and must be the first one sent following the server's welcome can be issued:
message. The format of the command is of the following:
AUTHENTICATE <mechanism> <initial data> ABORT
AUTHENTICATE
CONTINUE
DISCONNECT
ICALDATA
RECIPIENT
SWITCH
Courtemanche/Mansour/O'Leary 5 Expires February 1998 The format of the command is of the following:
from which the standard SASL interchange will take place as defined in AUTHENTICATE <mechanism> <initial data>
the SASL profile.
from which the standard [SASL] interchange will take place as defined
in the [SASL] profile. Authentication mechanisms will differ from one
server to the other, from one version to another. The CAPABILITY
command must be used by the sender to determine the best authentication
mechanism to use.
Example of an authentication session with kerberose version 4: Example of an authentication session with kerberose version 4:
R: 2.0 Welcome IRIP Server R: 2.0 Welcome IRIP Server
S: AUTHENTICATE KERBEROS_V4 744RTU3r# S: AUTHENTICATE KERBEROS_V4 744RTU3r#
S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf
S: slkfjgsdlfjg;dslfjgdsfg S: slkfjgsdlfjg;dslfjgdsfg
S: ;lasfgsdfg 45243 z!$14325dc S: ;lasfgsdfg 45243 z!$14325dc
R: 2.0 OK Kerberos V4 authentication successful R: 2.0
3.2.1 Authentication with Proxy Access 3.1.2.1 Authentication with Proxy Access
The proxy mechanism is the ability to have data posted from through an The proxy mechanism is the ability to have data posted by an indirect
indirect source. To handle this requirement, SASL mechanisms have a source. To handle this requirement, [SASL] mechanisms have a separate
separate "Authentication" and "authorization" identity. Thus, server A "Authentication" and "authorization" identity. Thus, server A could
could authenticate to server B using server A's credentials with the authenticate to server B using server A's credentials with the
authorization identity of user X. This effectively allows PROXY authorization identity of user X. This effectively allows PROXY
operations between servers. Some older SASL mechanisms do not support operations between servers. Some older [SASL] mechanisms do not
both authentication and authorization and therefore can't be used when support both authentication and authorization and therefore cannot be
PROXY operations are required. As per the SASL profile, the used when PROXY operations are required. As per the [SASL] profile,
authorization identity is the one used to determine if the operation the authorization identity is the one used to determine if the
should be allowed or not. The authentication identity ensures the operation should be allowed or not. The authentication identity ensures
transaction is originating from a trusted sender. the transaction is originating from a trusted sender.
3.2.2 Authentication for Anonymous Access 3.1.2.2 Authentication for Anonymous Access
SASL defines an ANONYMOUS authentication mechanism that must be used if SASL defines an ANONYMOUS authentication mechanism that must be used if
anonymous access is to be implemented by an iRIP capable server. This anonymous access is to be implemented by an [IRIP] capable server. This
is done by using the standard SASL authentication method and requesting is done by using the standard [SASL] authentication method and
the ANONYMOUS mechanism. The mechanism consists of a single message requesting the ANONYMOUS mechanism. The mechanism consists of a single
from the client to the server. The client sends optional trace message from the client to the server. The client sends optional trace
information in the for of a human readable string. It is recommended information in the form of a human readable string. It is recommended
that the trace information take one of three forms: An [RFC-822] that the trace information take one of three forms: An [RFC-822]
Internet e-mail address, an opaque ASCII string wich does not contain Internet e-mail address, an opaque ASCII string which does not contain
the "@" character and can be interpreted by the system administrator of the "@" character and can be interpreted by the system administrator of
the client's domain or nothing. the client's domain or nothing. Anonymous authentication is further
described in [ANON-SASL].
The following is an example of anonymous access using an opaque ASCII The following is an example of anonymous access using an opaque ASCII
string: string:
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228> S: <establish a connection to TCP port 5228>
R: 2.0 AboutTime iRIPServer@xyx.com Ready R: 2.0
S: AUTHENTICATE ANONYMOUS S: AUTHENTICATE ANONYMOUS
R: + R: +
S: c21yaGM S: c21yaGM
R: 2.0 Welcome anonymous R: 2.0
3.2.3 Authentication whit plain text password: An example 3.1.3 CAPABILITY
SASL allows for a server implementation to support simultaniousely many The CAPABILITY command tells the server to return a list of
different authentication mechanism, one of them being the well known capabilities it supports. The server must return a CAPABILITY response
plain text password. Altough plain text password is a very vulnerable with "IRIPrev1" as one of the listed capabilities. The CAPABILITY
authentication mechanism, it may be adequate for some applications and command can be issued in any connection state. The response may differ
is illustrated here because it is well known and understood. To depending on the current state of the connection. The responses may
properly implement the PLAIN authentication mechanism, refer to also differ depending upon the authenticated user.
[PLAINTRAN-SASL] as listed in the bibliography section of this
Courtemanche/Mansour/O'Leary 6 Expires February 1998 The format of the capabilities response is a series of lines with the
form <name>[=<value>]. Each name-value pair is delimited by a <CRLF>
character sequence. The sequence <CRLF>.<CRLF> followed by a reply code
terminates the response.
document. Example:
R: <listen on TCP port 5228> S: CAPABILITY
S: <establish a connection to TCP port 5228> R: CAPABILITY IRIPrev1
R: 2.0 AboutTime iRIPServer@xyx.com Ready R: AUTH=KERBEROS_V4
S: AUTHENTICATE PLAIN johndoe@xyz.com \0 open-sesame R: AUTH=PLAIN
R: 2.0 Welcome johndoe@xyz.com R: .
R: 2.0
3.3 CAPABILITY The table below summarizes the information available response to a
CAPABILITY command.
The CAPABILITY command tells the server to return a list of Capability Occurs Description
capabilities it supports. The server must return a CAPABILITY response --------------------- ------- ----------------------------------
with "IRIPrev1" as one of the listed capabilities. The CAPBILITY IRIPrev1 1 Revision of IRIP, must be
command can be issued in any connection state and the reply is not "IRIPrev1"
dependent upon the connection state.
A capability name which begins with "AUTH=" indicates that the server AUTH 0+ Authentication mechanism(s)
supports that particular authentication mechanism. supported
Example: MAXICALOBJECTSIZE 0 or 1 An integer value that specifies
The largest ICAL object the server
will accept. Objects larger than
this will be rejected.
S: CAPABILITY MAXDATE 0 or 1 The datetime value beyond which
R: CAPABILITY IRIPrev1 AUTH=KERBEROS_V4 AUTH=PLAIN the server cannot accept.
R: 2.0 OK
3.4 CONTINUE MINDATE 0 or 1 The datetime value prior to which
the server cannot accept.
3.1.4 CONTINUE
The CONTINUE command is issued by the Sender to allow an ICALDATA The CONTINUE command is issued by the Sender to allow an ICALDATA
request to continue being processed. When the latency time is specified request to continue being processed. When the latency time is specified
on the ICALDATA command, the Receiver must issue a reply to the Sender on the ICALDATA command, the Receiver must issue a reply to the Sender
within the specified time. The reply may be a reply code indicating within the specified time. The reply could be a reply code indicating
that the server has not yet processed the request. The Sender must that the server has not yet processed the request. The Sender must
then tell the server whether to continue or abort. then tell the server whether to continue or abort the command in
progress.
The CONTINUE has the following form: The CONTINUE has the following form:
CONTINUE[:latencyTime] CONTINUE[:latencyTime]
If the optional latencyTime is present, it specifies the maximum number If the optional latencyTime is present, it is a positive integer that
of seconds the client will wait for the next response. specifies the maximum number of seconds the client will wait for the
next response. If it is omitted, the receiver waits an indefinite
period of time for the response.
In this example, the Sender requests some sort of response from the In this example, the Sender requests some sort of response from the
server every 10 seconds. server every 10 seconds.
... ...
S: ICALDATA:10 S: ICALDATA:10
R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
<etc> <etc>
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
<after 10 seconds...> <after 10 seconds...>
R: . R: .
R: 2.0.2 Reply Pending R: 2.0.2 Reply Pending
S: CONTINUE:10 S: CONTINUE:10
R: BEGIN:VCALENDAR R: BEGIN:VCALENDAR
<etc> <etc>
R: END:VCALENDAR R: END:VCALENDAR
R: . R: .
R: 2.0
Courtemanche/Mansour/O'Leary 7 Expires February 1998 3.1.5 DISCONNECT
R: 2.0 OK
3.5 DISCONNECT
The DISCONNECT command signals the end of communication between the The DISCONNECT command signals the end of communication between the
Sender and Receiver. Sender and Receiver. It can be sent from any state.
Example: Example:
S: DISCONNECT S: DISCONNECT
R: 2.1 EXAMPLE.COM IRIP Service closing transmission channel R: 2.0
3.6 ICALDATA 3.1.6 ICALDATA
The ICALDATA is used specify the iCalendar Object that is to be The ICALDATA command is used specify the iCalendar Object that is to be
delivered to one or more recipients specified in the RECIPIENT delivered to one or more recipients specified in the RECIPIENT
command. The format of the command is: command. The format of the command is:
S: ICALDATA[:latencyTime] S: ICALDATA[:latencyTime]
S: <MIME encapsulated iCalendar Object> R: 2.0.1
S: <CRLF>.<CRLF> S: <MIME encapsulated ITIP Message>
R: <MIME encapsulated iCalendar Object > S: .
R: <CRLF>.<CRLF> R: <MIME encapsulated ITIP Message>
R: .
R: <reply code> R: <reply code>
The optional latencyTime value specifies the maximum number of seconds The optional latencyTime value specifies the maximum number of seconds
the Sender can wait for a reply. If it is not present, the client the Sender can wait for a reply. If it is not present, the client
places no time limit on the server for a reply. Following the ICALDATA places no time limit on the server for a reply. A reply code of 2.0.1
keyword is the iCalendar Object data. The data is terminated by the indicates that the [ITIP] message data can be sent. When the entire
special sequence <CRLF>.<CRLF>. The server reply may optionally contain message has been sent, the sender terminates sending data with the
an iCalendar Object, the special sequence <CRLF>.<CRLF> followed by a special sequence <CRLF>.<CRLF>. The receiver reply may optionally
reply code. contain an ITIP message followed by the special sequence <CRLF>.<CRLF>
followed by a reply code. Only the [ITIP] message is optional in the
reply, the <CRLF>.<CRLF> sequence must be present.
S: ICALDATA S: ICALDATA
R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
<etc.> <etc.>
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: . R: .
R: 2.0 OK R: 2.0
3.7 RECIPIENT 3.1.7 RECIPIENT
The RECIPIENT command is used to identify a recipient of the iCalendar The RECIPIENT command is used to identify a recipient of the iCalendar
Object. Use multiple RECIPIENT commands to specify multiple Object. Use multiple RECIPIENT commands to specify multiple
recipients. The command format is: recipients. The command format is
RECIPIENT <calendar address> RECIPIENT <calendar address>
3.8 SWITCH A response code of 2.0 indicates that the calendar address is available
for [ITIP] messages. If the receiver does not accept [ITIP] messages
for the specified calendar address, it may respond with [ITIP] reply
code 5.3 to indicate that the calendar address is unknown or the IRIP
referral reply code, 10.1, and supply the new calendar address. In
either case, the IRIP server does not deliver the [ITIP] message when
the reply code is 5.3 or 10.1.
3.1.8 SWITCH
The SWITCH command is used to allow the Sender and Receiver to change The SWITCH command is used to allow the Sender and Receiver to change
roles. Its format is: roles. Its format is:
SWITCH SWITCH
Courtemanche/Mansour/O'Leary 8 Expires February 1998
The SWITCH command is useful in environments where the firewall of a The SWITCH command is useful in environments where the firewall of a
Sender would not allow the Receiver to initiate a connection. The Sender would not allow the Receiver to initiate a connection. The
SWITCH command is issued by the Sender to give the Receiver the SWITCH command is issued by the Sender to give the Receiver the
opportunity to take the role of the Sender. The Sender must be in the opportunity to take the role of the Sender. The Sender must be in the
authenticated state before the SWITCH command can be used. authenticated state before the SWITCH command can be used.
The Receiver must respond in one of the following fashions: The Receiver must respond in one of the following fashions:
a) send an OK reply and take on the role of Sender * send an OK reply and take on the role of Sender
b) send a error reply indicating refusal and retain the role of * send a error reply indicating refusal and retain the role of Receiver
Receiver
If program-A is currently the Sender and sends the SWITCH command and If program-A is currently the Sender and sends the SWITCH command and
receives an OK reply then program-A becomes the Receiver. Program-A is receives an OK reply then program-A becomes the Receiver. Program-A is
then in its initial state and sends a service ready greeting message. then in its initial state and sends a service ready greeting message.
If program-B is currently the Receiver and sends an OK reply in If program-B is currently the Receiver and sends an OK reply in
response to a SWITCH command then program-B becomes the Sender. response to a SWITCH command then program-B becomes the Sender.
Program-B is then in the initial state as if the transmission channel Program-B is then in the initial state (connected) as if the
just opened, and expects to receive a service ready greeting. transmission channel just opened, and expects to receive a service
ready greeting.
3.9 Error Codes 3.2 Fanout and Queued Transactions
iRIP error codes follow the format defined for Status Replies in An IRIP server must be able to fanout requests targeted at other IRIP
servers. An IRIP server may queue information targeted at other IRIP
servers. There are several reasons for queing requests. One reason is
that firewall issues may prevent one server from contacting another.
IRIP provides a SWITCH command described later in this document to help
address this situation.
IRIP servers can establish trust relationships between each other. A
trusted relationship means:
- one server must authenticate with the other
- authenticated calendars on one server are trusted and treated as
authenticated on the other.
The trusted relationship need not be bi-directional. That is, the fact
that IRIP server A trusts IRIP server B does not necessarily mean that
B trusts A.
A trusted relationship between two IRIP servers means that one server
can queue transactions for the other server and deliver them some time
later. If IRIP server B trusts A, then A can queue requests for B. If A
does not trust B then B cannot accumulate requests for A.
Certain requests may need to be delivered and replied to in real-time.
In fact, a requester may wish to cancel the request if the reply cannot
be delivered in real-time. In IRIP it is possible to detect whether or
not a reply will be made in real-time and cancel the request if
necessary.
3.3 Reply Codes
[IRIP] error codes follow the format defined for Status Replies in
[ITIP]. All Status Replies as defined in [ITIP] are valid error codes [ITIP]. All Status Replies as defined in [ITIP] are valid error codes
when returned by an iRIP command.
In addition to those defined in [ITIP], iRIP defines the following when returned by an [IRIP] command.
In addition to those defined in [ITIP], [IRIP] defines the following
error codes: error codes:
2.0.1 START-ICALDATA Start ICAL input; end with <CRLF>.<CRLF> REPLY
CODE DESCRIPTOR MEANING
------ ---------------------- --------------------------------------
2.0.1 START-ICALDATA Start ICAL input; end with
<CRLF>.<CRLF>
2.0.2 REPLY-PENDING A timeout has occurred. The server is 2.0.2 REPLY-PENDING A timeout has occurred. The server is
still working on the reply. Use CONTINUE still working on the reply. Use
to continue waiting for the reply or CONTINUE to continue waiting for the
ABORT to terminate the command. reply or ABORT to terminate the
command.
6.0 AUTHORIZATION FAILED General authorization failure
6.1 TRANSITION-NEEDED Indicates the transition from 2.0.3 ABORTED In response to the client issuing an
a legacy database to a more ABORT command, this reply code
secure password mechanism, and indicates that any command currently
reports that the new mechanism underway was successsfully aborted.
is not usable until "AUTHENTICATE
PLAIN" or a login procedure is used.
6.2 AUTH-TOO-WEAK Indicates that multiple remote 2.0.4 TRUSTED-WILL-ATTEMPT The specified Calendar is not here
services are offered, and therefore but a trust relationship exists
there is no practical way to transition between this server and the server
every remote service. So, the mechanism on which the Calendar exists. An
must not allow users to have different attempt will be made to deliver the
passwords for different services. The request or reply to the Calendar
error code reports that no new plaintext anyway.
passwords will be accepted from the user
at a later date. It could also indicate
that the requested mechanism is not
available.
Courtemanche/Mansour/O'Leary 9 Expires February 1998 2.0.5 TRUSTED-WILL-QUEUE The specified Calendar cannot be
contacted directly. The request or
reply will be queued and delivered to
the target calendar when its IRIP
server contacts this server and issues
the SWITCH command.
6.3 ENCRYPT-NEEDED Indicates that the requested mechanism 2.0.6 WILL-ATTEMPT The specified Calendar is not here
it to be used in conjunction with a but an attempt will be made to deliver
strong external encryption layer. the request or reply to the Calendar
anyway.
7.0 TIMEOUT The requested operation could not be 2.0.7 QUEUED The request or reply has been queued
completed in the time allotted. for delivery.
Command execution is suspended pending
a reply to continue or abort.
8.0 GENERAL FAILURE A failure has occurred in the Receiver 8.0 GENERAL FAILURE A failure has occurred in the Receiver
that prevents the operation from that prevents the operation from
succeeding. succeeding.
8.1 SERVER TOO BUSY Sent when a connection cannot be
established because the iRIP Receiver
is too busy.
9.0 INVALID IRIP COMMAND An unrecongnized command was received. 8.1 SERVER TOO BUSY Sent when a session cannot be
established because the [IRIP]
Receiver is too busy.
10.0 NOT HERE The Receiver does not know how to 8.2 ICAL OBJECT TOO BIG Used to signal that an ICAL object has
contact the Calendar Store for the exceeded the server's size limit.
specified RECIPIENT.
8.3 DATE TOO LARGE A DATETIME value was too large to be
represented on this Calendar.
8.4 DATE TOO SMALL A DATETIME value was too far in the
past to be represented on this
Calendar.
9.0 INVALID IRIP COMMAND An unrecongnized command was received.
10.1 REFERRAL Accompanied by an alternate address. 10.1 REFERRAL Accompanied by an alternate address.
The RECIPIENT specified should be The RECIPIENT specified should be
contacted at the given alternate contacted at the given alternate
address. address. The referral address MUST
follow the reply code.
4. Security Considerations 10.2 SERVER SHUT DOWN The server is shutting down.
The security of iRIP with SASL support is highly dependent on the 10.3 SERVER STOPPING FLOOD
mechanism used to authenticate the client and whether or not the
security layer is further negotiated. Without a robust security layer,
iRIP transactions are subject to eavesdropping and the integrity of
iRIP transactions may be compromised. Since iRIP is designed
specifically for real time Internet transactions, it is recommended
that implementations use the highest degree of authentication and
transmission security possible.
Authentication is fundamental to iRIP. It is the basis for granting and 10.4 EXCEEDED QUOTAS
denying access. Without a robust security layer iRIP will be subject to
many possible attacks and the full contents of the server itself may be
at risk.
4.1 SASL ANONYMOUS Mechanism 10.5 QUEUED TOO LONG The ITIP message has been queued too
too long. Delivery has been aborted.
Implementing support for the Anonymous SASL significantly increases the 4 Implementation Considerations
vulnerability of the calendar server and its data. Refer to [ANON-SASL]
for further information on many threats specific to Anonymous SASL
access.
4.2 SASL Profile Definition for the protocol It is strongly recommended that when an IRIP implementation encounters
an error requiring the communication channel between the Sender and
Receiver to be dropped that the DISCONNECT command be issued rather
than simply breaking the communication channel.
The implementation of SASL in iRIP requires the server and client to [Editors note: What is the expectation for calstore recipients that
comply to the following profile extension: don't exist on this server?]
AUTHENTICATE command. Full description of the challenge/response 5 Security Considerations
definition. Starting octet. Interpretation of the authorization
identity passed should be interpreted.
Courtemanche/Mansour/O'Leary 10 Expires February 1998 The security of [IRIP] with [SASL] support is highly dependent on the
mechanism used to authenticate the client and whether or not the
security layer is further negotiated. Without a robust security layer,
[IRIP] transactions are subject to eavesdropping and the integrity of
[IRIP] transactions may be compromised. Since [IRIP] is designed
specifically for real time Internet transactions, it is recommended
that implementations use the highest degree of authentication and
transmission security possible.
4.3 ITIP Threats Authentication is fundamental to [IRIP]. It is the basis for granting
and denying access. Without a robust security layer [IRIP] will be
subject to many possible attacks and the full contents of the server
itself may be at risk.
Threat: Spoofing the organizer or attendee. 5.1 SASL ANONYMOUS Mechanism
Solution: The entire protection for spoofing attendees or organizer of Implementing support for the Anonymous [SASL] significantly increases
a meeting resides in the fact that the connection needs to be the vulnerability of the calendar server and its data. Refer to
authenticated. Spoofing would be possible in the absence of [ANON-SASL] for further information on many threats specific to
authentication. Anonymous [SASL] access.
Threat: Eavesdropping on the traffic. 5.2 SASL Profile Definition for the protocol
Solution: If SASL is used to negotiate with the server a security The implementation of [SASL] in [IRIP] requires the server and client
layer, then traffic is no longer in the clear and eavesdropping will
not be restricted.
Threat: Flooding of a calendar to comply with the following profile extension:
Solution: Implementation of iRIP should limit the size and traffic of - AUTHENTICATE command.
transaction from a given source. - Full description of the challenge/response definition.
- Starting octet.
- Authorization identity supplied by the sender must the one used to
grant or denied the requested operation.
Threat: Procedural Alarms 5.3 Security Threats
Solution: Implementation of iRIP should remove or disallow procedural 5.3.1 Eavesdropping
alarms before delivery.
4.4 IRIP-Specific Threats If [SASL] is used to negotiate a security layer with the server, then
traffic is no longer in the clear and eavesdropping will not be
restricted.
Threat: Flooding of connections 5.3.2 Connection Flooding
Solution: Connections that have not been authenticated within 3 seconds Connections that have not been authenticated within a configurable
should be disconnected. number of seconds should be disconnected.
5. Examples 5.3.3 Denial of Service Attacks
5.1 Unathenticated Freebusy Request [Editors note: need explanation and recommendation: ???]
6 Examples
6.1 Unauthenticated Freebusy Request
This examples shows an anonymous request for the freebusy time of This examples shows an anonymous request for the freebusy time of
sman@example.com. irip://cal.example.com/sman. Note that once xyz is authenticated on
the irip server either the fully qualified IRIP CALID or the relative
CALID can be used to reference a Calendar. That is,
"irip://cal.example.com/xyz" and "xyz" refer to the same calendar and
can be used interchangeably.
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228> S: <establish a TCP connection to cal.example.com port 5228>
R: 2.0 BIG-Time iRIPServer@example.com Ready R: 2.0
S: AUTHENTICATE ANONYMOUS xyz@unknown.com S: AUTHENTICATE ANONYMOUS xyz
R: 2.0 Welcome xyz@example.com R: 2.0
S: RECIPIENT:sman S: RECIPIENT:sman
R: 2.0 OK R: 2.0
S: ICALDATA S: ICALDATA
R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit S: Content-Transfer-Encoding: 7bit
S: S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: PRODID:-//ACME/DesktopCalendar//EN S: PRODID:-//ACME/DesktopCalendar//EN
S: METHOD:REQUEST S: METHOD:REQUEST
S: VERSION:2.0 S: VERSION:2.0
S: BEGIN:VFREEBUSY S: BEGIN:VFREEBUSY
S: ORGANIZER:mailto:xyz@unknown.com S: ORGANIZER:xyz
S: ATTENDEE:mailto:sman@example.com S: ATTENDEE:sman
S: DTSTAMP:19971113T190000Z S: DTSTAMP:19971113T190000Z
Courtemanche/Mansour/O'Leary 11 Expires February 1998
S: DTSTART:19971115T160000Z S: DTSTART:19971115T160000Z
S: DTEND:19971116T040000Z S: DTEND:19971116T040000Z
S: UID:www.example.com-873970198738777@host.com S: UID:www.example.com-873970198738777@host.com
S: END:VFREEBUSY S: END:VFREEBUSY
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
<server looks up the freebusy time and builds a reply>
R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
R: Content-Transfer-Encoding: 7bit R: Content-Transfer-Encoding: 7bit
R: R:
R: BEGIN:VCALENDAR R: BEGIN:VCALENDAR
R: PRODID:-//EXAMPLE/DesktopCalendar//EN R: PRODID:-//EXAMPLE/DesktopCalendar//EN
R: METHOD:REPLY R: METHOD:REPLY
R: VERSION:2.0 R: VERSION:2.0
R: BEGIN:VFREEBUSY R: BEGIN:VFREEBUSY
R: ATTENDEE:mailto:sman@example.com S: ORGANIZER:irip://cal.example.com/xyz
R: ATTENDEE:irip://cal.example.com/sman
R: DTSTAMP:19971113T190005Z R: DTSTAMP:19971113T190005Z
R: DTSTART:19971115T160000Z R: DTSTART:19971115T160000Z
R: DTEND:19971116T040000Z R: DTEND:19971116T040000Z
R: UID:www.example.com-873970198738777@host.com R: UID:www.example.com-873970198738777@host.com
R: FREEBUSY:19971113T230000Z/PT1H,19971114T210000Z/PT30M R: FREEBUSY:19971113T230000Z/PT1H,19971114T210000Z/PT30M
R: END:VFREEBUSY R: END:VFREEBUSY
R: END:VCALENDAR R: END:VCALENDAR
R: . R: .
R: 2.0 OK R: sman 2.0
R: .
S: DISCONNECT S: DISCONNECT
R: 2.0 OK R: 2.0
R: <disconnect> R: <disconnect>
S: <disconnect> S: <disconnect>
5.2 Using Switch 6.2 Using Switch
This session demonstrates how a poll can be accomplished using the This session demonstrates how a poll can be accomplished using the
SWITCH command. In this case, the sender (S) becomes the receiver (R) SWITCH command. In this case, the sender (S) becomes the receiver (R)
after issuing the switch command. after issuing the switch command.
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228> S: <establish a connection to TCP port 5228>
R: 2.0 BIG-Time iRIPServer@example.com Ready R: 2.0
S: AUTHENTICATE KERBEROS_V4 93407205 S: AUTHENTICATE KERBEROS_V4 93407205
S: <more authentication information> S: <more authentication information>
R: 2.0 OK R: 2.0
S: SWITCH S: SWITCH
R: 2.0 OK R: 2.0
<sender now becomes the receiver ...> <sender now becomes the receiver>
S: 2.0 Other-BIG-Time iRIPServer@example2.com Ready S: 2.0
R: AUTHENTICATE KERBEROS_V4 273678199dao986pq8u98u9e8w0-0--0--0werg R: AUTHENTICATE KERBEROS_V4 27367ao986pq8u98u9e8w0-0--0--0werg
S: 2.0 Welcome S: 2.0
<receiver can now authenticate and send anything pending for the sender> <receiver can now authenticate and send anything pending for the
sender>
5.3 Resource Scheduling 6.3 Queued Requests
In the diagram below, sender S has authenticated to the IRIP server
B.foo.com. C.foobar.com, D.bar.com, and E.barfoo.com all have IRIP
servers. B has a trusted relationship with both C and D. A firewall is
in place that prohibits B from initiating a connection to D. However, D
can connect to B.
+--------------+
+------| C.foobar.com |
| +--------------+
|
+-----------+ | +-----------+
S ---------| B.foo.com |------#--| D.bar.com |
+-----------+ | +-----------+
|
| +--------------+
+------| E.barfoo.com |
+--------------+
6.3.1 Meeting Invitation
In this example, S sends an event request to the IRIP server on B for
calendars on B, C, D, and E.
R: <listen on TCP port 5228>
S: <establish a TCP connection to b.foo.com port 5228>
R: 2.0
S: AUTHENTICATE KERBEROS_V4 93407205
S: <more authentication information>
R: 2.0
S: RECIPIENT:irip://B.foo.com/bill
R: 2.0
S: RECIPIENT:irip://C.foobar.com/cathy
R: 2.0.4
S: RECIPIENT:irip://D.bar.com/david
R: 2.0.5
S: RECIPIENT:irip://E.barfoo.com/eddie
R: 2.0.6
S: ICALDATA: 16
R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: PRODID:-//ACME/DesktopCalendar//EN
S: METHOD:REQUEST
S: VERSION:2.0
S: BEGIN:VEVENT
S: ORGANIZER:irip://B.foo.com/bill
S: ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:irip://B.foo.com/bill
S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://C.foobar.com/cathy
S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://D.bar.com/david
S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://E.barfoo.com/eddie
S: DTSTAMP:19981011T190000Z
S: DTSTART:19981101T200000Z
S: DTEND:19981101T2100000Z
S: SUMMARY:Conference
S: UID:calsrv.example.com-873970198738777@example.com
S: SEQUENCE:0
S: STATUS:CONFIRMED
S: END:VEVENT
S: END:VCALENDAR
S: .
R: .
R: irip://B.foo.com/bill 2.0
R: irip://C.foobar.com/cathy 2.0
R: irip://D.bar.com/david 2.0.7
R: irip://E.barfoo.com/eddie 2.0
S: DISCONNECT
R: 2.0
R: <disconnect>
S: <disconnect>
The invitation is written to the calendar B.foo.com/bill. IRIP server
B.foo.com authenticates to C.foobar.com and sends the event request,
which is successfully written to C.foobar.com/cathy. The IRIP server on
B.foo.com cannot contact D.bar.com, but a trust relationship exists
between them and the request is queued for delivery. This request will
be delivered the next time the IRIP server on D.bar.com connects to the
IRIP server on B.foo.com and issues a SWITCH command. The IRIP server
on B.foo.com connects to the IRIP server on E.barfoo.com and
authenticates as anonymous since it has no trust relationship with
E.barfoo.com. If the anonymous authentication is successful, the event
request is delivered to E.barfoo.com/eddie.
[Editors note: in the case of the anonymous authentication, B could
also provide E with the same credentials as S provided to B]
6.3.2 Busy Time Request
In this example, the sender S sends a Freebusy request to B for
calendars on B, C, D, and E. S needs the information immediately and
will abort any attempt to queue requests.
R: <listen on TCP port 5228>
S: <establish a TCP connection to cal.example.com port 5228>
R: 2.0
S: AUTHENTICATE KERBEROS_V4 93407205
S: <more authentication information>
R: 2.0
S: RECIPIENT:irip://B.foo.com/bill
R: 2.0
S: RECIPIENT:irip://C.foobar.com/cathy
R: 2.0.4
S: RECIPIENT:irip://D.bar.com/david
R: 2.0.5
S: RECIPIENT:irip://E.barfoo.com/eddie
R: 2.0.6
<the sender cannot accept a queued request and response. The
current operation will be canceled. The operation will be tried
again with all attendees that have requests queued dropped from the
RECIPIENT list...>
S: ABORT
R: 2.0.3
S: RECIPIENT:irip://B.foo.com/bill
R: 2.0
S: RECIPIENT:irip://C.foobar.com/cathy
R: 2.0.4
S: RECIPIENT:irip://E.barfoo.com/eddie
R: 2.0.6
S: ICALDATA
R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: PRODID:-//ACME/DesktopCalendar//EN
S: METHOD:REQUEST
S: VERSION:2.0
S: BEGIN:VFREEBUSY
S: ORGANIZER:irip://B.foo.com/bill
S: ATTENDEE:irip://B.foo.com/bill
S: ATTENDEE:irip://C.foobar.com/cathy
S: ATTENDEE:irip://D.bar.com/david
S: ATTENDEE:irip://E.barfoo.com/eddie
S: DTSTAMP:19971113T190000Z
S: DTSTART:19971115T160000Z
S: DTEND:19971116T040000Z
S: UID:www.example.com-873970198738777@host.com
S: END:VFREEBUSY
S: END:VCALENDAR
S: .
<server looks up the freebusy time for B.foo.com/bill,
requests and receives the freebusy time for
irip://C.foobar.com/cathy and irip://E.barfoo.com/eddie. Then it
builds a reply>
R: Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"
R:
R: This is a multi-part message in MIME format.
R:
R:----FEE3790DC7E35189CA67CE2C
R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
R: Content-Transfer-Encoding: 7bit
R:
R: BEGIN:VCALENDAR
R: PRODID:-//EXAMPLE/DesktopCalendar//EN
R: METHOD:REPLY
R: VERSION:2.0
R: BEGIN:VFREEBUSY
S: ORGANIZER:irip://B.foo.com/bill
R: ATTENDEE:irip://B.foo.com/bill
R: DTSTAMP:19971113T190005Z
R: DTSTART:19971115T160000Z
R: DTEND:19971116T040000Z
R: UID:www.example.com-873970198738777@host.com
R: FREEBUSY:19971115T200000Z/PT1H,19971116T170000Z/PT30M
R: END:VFREEBUSY
R: END:VCALENDAR
R:
R:----FEE3790DC7E35189CA67CE2C
R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
R: Content-Transfer-Encoding: 7bit
R:
R: BEGIN:VCALENDAR
R: PRODID:-//EXAMPLE/DesktopCalendar//EN
R: METHOD:REPLY
R: VERSION:2.0
R: BEGIN:VFREEBUSY
S: ORGANIZER:irip://B.foo.com/bill
R: ATTENDEE:irip://C.foobar.com/cathy
R: DTSTAMP:19971113T190005Z
R: DTSTART:19971115T160000Z
R: DTEND:19971116T040000Z
R: UID:www.example.com-873970198738777@host.com
R: FREEBUSY:19971115T230000Z/PT1H,19971116T210000Z/PT30M
R: END:VFREEBUSY
R: END:VCALENDAR
R:
R:----FEE3790DC7E35189CA67CE2C
R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
R: Content-Transfer-Encoding: 7bit
R:
R: BEGIN:VCALENDAR
R: PRODID:-//EXAMPLE/DesktopCalendar//EN
R: METHOD:REPLY
R: VERSION:2.0
R: BEGIN:VFREEBUSY
S: ORGANIZER:irip://B.foo.com/bill
R: ATTENDEE:irip://E.barfoo.com/eddie
R: DTSTAMP:19971113T190005Z
R: DTSTART:19971115T160000Z
R: DTEND:19971116T040000Z
R: UID:www.example.com-873970198738777@host.com
R: FREEBUSY:19971115T230000Z/PT1H,19971116T210000Z/PT30M
R: END:VFREEBUSY
R: END:VCALENDAR
R:
R:----FEE3790DC7E35189CA67CE2C
R: .
R: irip://B.foo.com/bill 2.0
R: irip://C.foobar.com/cathy 2.0
R: irip://E.barfoo.com/eddie 2.0
S: DISCONNECT
R: 2.0
R: <disconnect>
S: <disconnect>
Since each reply is delivered immediately, the reply is sent as a
Multipart/Mixed. Transport reply codes for each recipient are returned
after the Multipart/Mixed data.
6.4 Resource Scheduling
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <connect to port 5228> S: <connect to port 5228>
R: 2.0 Welcome R: 2.0
S: AUTHENTICATE KERBEROS_V4 7SF8S3&# S: AUTHENTICATE KERBEROS_V4 7SF8S3&#
S: <more authentication information> S: <more authentication information>
R: 2.0 OK, you're in like Flynn R: 2.0
S: RECIPIENT Large_Conference_Room S: RECIPIENT Large_Conference_Room
R: 2.0 OK R: 2.0
Courtemanche/Mansour/O'Leary 12 Expires February 1998
S: RECIPIENT Overhead_Projector_1 S: RECIPIENT Overhead_Projector_1
R: 2.0 OK R: 2.0
S: ICALDATA: 10 S: ICALDATA: 10
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Inlet MIMEDIR//EN S: PRODID:-//Foo Corporation//Inlet MIMEDIR//EN
S: VERSION:2.0 S: VERSION:2.0
S: METHOD:REQUEST
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: ORGANIZER:irip://cal.example.com/xyz
S: ATTENDEE:irip://cal.example.com/Large_Conference_Room
S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1
S: DTSTART:19980706T190000Z S: DTSTART:19980706T190000Z
S: DTEND:19980706T203000Z S: DTEND:19980706T203000Z
S: LOCATION:Large Conference Room S: LOCATION:Large Conference Room
S: DESCRIPTION:Big customer meeting in Large Conference room. S: DESCRIPTION:Big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting S: SUMMARY:Customer meeting
S: PRIORITY:1 S: PRIORITY:1
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: <looks up availability in database> R: <looks up availability in database>
R: . R: .
R: 2.0 OK R: 2.0 Large_Conference_Room
R: 2.0 Overhead_Projector_1
S: RECIPIENT Large_Conference_Room S: RECIPIENT Large_Conference_Room
R: 2.0 OK R: 2.0
S: RECIPIENT Overhead_Projector_1 S: RECIPIENT Overhead_Projector_1
R: 2.0 OK R: 2.0
S: ICALDATA: 10 S: ICALDATA: 10
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
S: VERSION:2.0 S: VERSION:2.0
S: METHOD:REQUEST
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: ORGANIZER:irip://cal.example.com/xyz
S: ATTENDEE:irip://cal.example.com/Large_Conference_Room
S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1
S: DTSTART:19980708T220000Z S: DTSTART:19980708T220000Z
S: DTEND:19980708T230000Z S: DTEND:19980708T230000Z
S: LOCATION:Large Conference Room S: LOCATION:Large Conference Room
S: DESCRIPTION:Another big customer meeting in Large Conference room. S: DESCRIPTION:Another big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting S: SUMMARY:Customer meeting
S: PRIORITY:1 S: PRIORITY:1
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: <looks up availability in database> R: <looks up availability in database>
R: . R: .
R: 4.0 No, Large_Conference_Room not available at that time. < Large_Conference_Room not available, thus the response code is...>
R: 4.0
S: RECIPIENT Large_Conference_Room S: RECIPIENT Large_Conference_Room
R: 2.0 OK R: 2.0
S: RECIPIENT Overhead_Projector_1 S: RECIPIENT Overhead_Projector_1
R: 2.0 OK R: 2.0
S: ICALDATA: 10 S: ICALDATA: 10
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
S: VERSION:2.0 S: VERSION:2.0
S: METHOD:REQUEST
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: ORGANIZER:irip://cal.example.com/xyz
S: ATTENDEE:irip://cal.example.com/Large_Conference_Room
S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1
S: DTSTART:19980708T160000Z S: DTSTART:19980708T160000Z
S: DTEND:19980708T170000Z S: DTEND:19980708T170000Z
S: LOCATION:Large Conference Room S: LOCATION:Large Conference Room
S: DESCRIPTION:Another big customer meeting in Large Conference room. S: DESCRIPTION:Another big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting S: SUMMARY:Customer meeting
S: PRIORITY:1 S: PRIORITY:1
S: END:VEVENT S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: <looks up availability in database> R: <looks up availability in database>
<10 seconds pass>
Courtemanche/Mansour/O'Leary 13 Expires February 1998
R: <10 seconds pass>
R: . R: .
R: 7.0 Database too busy, try again later <Database too busy, thus the response code is...>
R: 2.0.2
S: ABORT
R: 2.0
S: DISCONNECT S: DISCONNECT
R: 2.0 OK R: 2.0
R: <drops TCP connection> R: <drops TCP connection>
6. Acknowledgments 7 Acknowledgments
The following have participated in the drafting and discussion of this The following have participated in the drafting and discussion of this
memo: memo:
Doug Royer, Mugino Saeki Bruce Kahn, Doug Royer, Mugino Saeki
7. Bibliography
[ANON-SASL] "Anonymous SASL mechanism", draft-newman-sasl-anon-00.txt
[PLAINTRAN-SASL] "Plain text password SASL mechanism", 8 Bibliography
draft-newman-sasl-plaintrans-03.txt
[ICAL] "Internet Calendaring and Scheduling Core Object Specification - [ ICAL] "Internet Calendaring and Scheduling Core Object Specification
iCalendar", Internet-Draft, July 1997, - iCalendar", Internet-Draft, July 1997,
ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-02.txt. ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-10.txt.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft, July [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July
1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt. 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt.
[ITIP] "iCalendar Transport-Independent Interoperability Protocol [ITIP] "iCalendar Transport-Independent Interoperability Protocol
(iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ",
Internet-Draft, October 1997, Internet-Draft, October 1997,
http://www.imc.org/draft-ietf-calsch-itip-01.txt. http://www.imc.org/draft-ietf-calsch-itip-06.txt.
[IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP),
Internet-Draft, October 1997, Internet-Draft, October 1997,
http://www.imc.org/draft-ietf-calsch-imip-02.txt. http://www.imc.org/draft-ietf-calsch-imip-05.txt.
[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
Internet-Draft, July,1996, Internet-Draft, July,1996,
ftp://ftp.ietf.org/internet-drafts/draft-yergeau-utf8-01.txt. ftp://ftp.ietf.org/internet-drafts/draft-yergeau-utf8-01.txt.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982. Messages", STD 11, RFC 822, August 1982.
[RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC
1847, October 1995. 1847, October 1995.
[RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC
2112, March 1997. 2112, March 1997.
[RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)," [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP),"
RFC 2015, October 1996. RFC 2015, October 1996.
[RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail
skipping to change at line 842 skipping to change at line 1183
2112, March 1997. 2112, March 1997.
[RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)," [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP),"
RFC 2015, October 1996. RFC 2015, October 1996.
[RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
2045, November 1996. 2045, November 1996.
[RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail
Courtemanche/Mansour/O'Leary 14 Expires February 1998
Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996. November 1996.
[RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048, Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048,
January 1997. January 1997.
[RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)", [RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. RFC 2222, October 1997.
8. Open Issues 9 Open Issues
Registration of the SASL profile for iRIP with the IANA. Registration of the [SASL] profile for [IRIP] with the IANA.
Calendar addressing
Port Number registration Port Number registration
10 Author's Address
9. Author's Address
The following address information is provided in a vCard v2.1, The following address information is provided in a vCard v2.1,
Electronic Business Card, format. Electronic Business Card, format.
BEGIN:VCARD BEGIN:VCARD
FN:Andre Courtemanche FN:Andre Courtemanche
ORG:CS&T ORG:CS&T
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 3L5;Canada ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R
3L5;Canada
TEL;WORK;MSG:+1-514-733-8500 TEL;WORK;MSG:+1-514-733-8500
TEL;WORK;FAX:+1-514-733-8788 TEL;WORK;FAX:+1-514-733-8788
EMAIL;INTERNET:andre@cst.ca EMAIL;INTERNET:andre@cst.ca
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:2.1 VERSION:2.1
FN:Steve Mansour FN:Steve Mansour
ORG:Netscape Communications Corporation ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
skipping to change at line 894 skipping to change at line 1232
TEL;WORK;MSG:+1-650-937-2378 TEL;WORK;MSG:+1-650-937-2378
TEL;WORK;FAX:+1-650-937-2103 TEL;WORK;FAX:+1-650-937-2103
EMAIL;INTERNET:sman@netscape.com EMAIL;INTERNET:sman@netscape.com
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
FN:Pete O'Leary FN:Pete O'Leary
ORG:Amplitude ORG:Amplitude
ADR;WORK;POSTAL;PARCEL:;; ADR;WORK;POSTAL;PARCEL:;;
TEL;WORK;MSG:+1-415-659-3511 TEL;WORK;MSG:+1-415-659-3511
TEL;WORK;FAX:+1-415 TEL;WORK;FAX:+1-415-659-0006
EMAIL;INTERNET:pete@amplitude.com EMAIL;INTERNET:pete@amplitude.com
END:VCARD END:VCARD
The iCalendar object is a result of the work of the Internet The iCalendar object is a result of the work of the Internet
Engineering Task Force Calendaring and scheduling Working Group. The Engineering Task Force Calendaring and scheduling Working Group. The
chairman of that working group is: chairman of that working group is:
BEGIN:VCARD BEGIN:VCARD
FN:Anik Ganguly FN:Anik Ganguly
ORG:Open Text, Inc.
ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road Suite 101;
Livonia;MI;48152;USA
TEL;WORK;MSG:+1-734-542-5955
EMAIL;INTERNET:ganguly@acm.org
END:VCARD
Courtemanche/Mansour/O'Leary 15 Expires February 1998 The co-chairman of that working group is:
ORG:Open Text Inc. BEGIN:VCARD
ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road;Suite 101 VERSION:2.1
Livonia;MI;USA FN:Robert Moskowitz
TEL;WORK;MSG:+1-734-542-5955 EMAIL;INTERNET: rgm-ietf@htt-consult.com
EMAIL;INTERNET:ganguly@acm.com
END:VCARD END:VCARD
10. Full Copyright Statement 11 Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it MAY be copied and furnished to This document and translations of it MAY be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation MAY be prepared, copied, published and assist in its implmentation MAY be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself MAY NOT be modified in any way, such as by removing the document itself MAY NOT be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of developing
 End of changes. 188 change blocks. 
365 lines changed or deleted 708 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/