Subject: IRIP version 4

From: [email-masked] (Steve Mansour)
Date: Tue, 09 Mar 1999 22:44:38 -0800

Folks,

There were some formatting issues with the submitted draft submitted on
Feb 25.  We apologize for this, but we thought it would be a good idea
to post the draft to the list anyway. We'll fix the formatting issues
and resubmit it.

-Steve

Network Working Group                           Andre Courtemanche, CS&T
Internet Draft                  IRIP             Steve Mansour, Netscape
<draft-ietf-calsched-irip-04.txt>                Pete O'Leary, Amplitude
Expires 6 months after:                                February 25, 1999

         ICalendar Real-time Interoperability Protocol (IRIP)

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.
Internet-Drafts may be updated, replaced, or made obsolete by other
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
"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.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 
Distribution of this document is unlimited.

Abstract

This document specifies a binding from the iCalendar
Transport-independent Interoperability Protocol [RFC-2446] to a
real-time transport. Calendaring entries defined by the iCalendar
Object Model [RFC-2445] are composed using constructs from [RFC-2045],
[RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

This document is based on discussions within the Internet Engineering
Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
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
http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
references within this document for further information on how to
access these various documents.

Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent to the authors.

Courtemanche/Mansour/O'Leary      1                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

1 Introduction

This binding document provides the transport specific information
necessary to convey iCalendar Transport-independent Interoperability
Protocol [ITIP] messages over a real-time transport.

1.1 Related Memos

Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and
scheduling standards.

This document specifies a real-time binding for [ITIP].

* [ICAL] specifies a core specification of objects, data types,
properties and property parameters;

* [ITIP] specifies an interoperability protocol for scheduling between
different implementations;

* [IMIP] specifies a messaging-based protocol binding for [ITIP].

This document does not attempt to repeat the specification of concepts
or definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these concepts
or definitions.

1.2 Formatting Conventions

The mechanisms defined in this memo are defined in propose. In order to
refer to elements of the calendaring and scheduling model, core object
or interoperability protocol defined in [ICAL] and [ITIP] some
formatting conventions have been used.

Calendaring and scheduling roles defined by [ITIP] are referred to in
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"
within the scheduling protocol defined by [ITIP].

Calendar components defined by [ICAL] are referred to with capitalized,
quoted-strings of text. All calendar components start with the letter
"V". For example, "VEVENT" refers to the event calendar component,
"VTODO" refers to the to-do calendar component and "VJOURNAL" refers to
the daily journal calendar component.

Scheduling methods defined by [ITIP] are referred to with capitalized,
quoted-strings of text. For example, "REQUEST" refers to the method for
requesting a scheduling calendar component be created or modified,
"REPLY" refers to the method a recipient of a request uses to update
their status with the "Organizer" of the calendar component.

Properties defined by [ICAL] are referred to with capitalized,
quoted-strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey the
calendar address of a calendar user.

Property parameters defined by [ICAL] are referred to with lower case,
quoted-strings of text, followed by the word "parameter". For example,

Courtemanche/Mansour/O'Leary      2                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

"VALUE" parameter refers to the iCalendar property parameter used to
override the default data type for a property value.

2 Architecture

[IRIP] enables real-time interoperability between scheduling systems
using the iCalendar [ICAL] format for information exchange. [IRIP] is
designed primarily to allow Calendar Services (CS) to forward real-time
requests on behalf of Calendar User Agents (CUA) and receive real-time
responses. The goal of [IRIP] is to allow two or 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.

The sections and examples below refer to a "user", a "sender", and a
"receiver". For purposes of this document these terms are defined as
follows:

  user     - the CU that initiates a request.
  sender   - the agent used to contact a receiving device, send 
	     commands, and receive replies.
  receiver - the agent that accepts commands and sends replies.

The sender and receiver can take on varying roles of a Calendar User
Agent (CUA) and Calendar Store (CS).

[IRIP] allows two CS's to establish different levels of trust. When an
[IRIP] connection is first established, the sender CS authenticates as
the IRIP server acting as a proxy for the originator of each ITIP
message being sent to the receiver.

Courtemanche/Mansour/O'Leary      3                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

2.1 Protocol States

The IRIP state diagram is shown below.  The states are shown in the
boxes. State names are written with the first letter capitalized. The
commands used to switch between states are shown next to an arrow
connecting the states. The commands are listed in all capital letters.
A condition that causes a state to change is shown in lower case
letters.

   CAPABILITY
   or SWITCH
     +----+
     V    |
+-------------+   DISCONNECT    +---------------+
|             |---------------->|  Terminated   |
|  Connected  |                 +---------------+
|             |<---+                   A
+-------------+    |                   |
  |                |                   |
  |AUTHENTICATE    |   AUTHENTICATE    |DISCONNECT
  |                |   or CAPABILITY   |
  |          SWITCH|     +----+        |
  |                |     V    |        |
  |    +----------------------------------+           
  +--->|                                  |    ABORT   +--------+
       |          Authenticated           |<-----------|  Idle  |
  +--->|                                  |<--+        +--------+
  |    +----------------------------------+   |           |   A
  |        |                       |  complete|           |   |
  |ABORT   |RECEIVE         DEQUEUE|        or|   CONTINUE|   |latency 
  |        |                       |     ABORT|           |   |reply
  |        V                       V          |           |   |from
+-------------+                 +---------------+         |   |server
|             |    ICALDATA     |               |<--------+   |
|    Send     |---------------->|    Receive    |             |
|             |                 |               |-------------+
+-------------+                 +---------------+
    A    |
    +----+
   RECIPIENT

An [IRIP] session begins when a TCP/IP connection is made on port 5228.
The protocol begins in the Connected state. Once connected, the sender
can issue the CAPABILITY which leaves the protocol in the Connected
state. The sender can also issue the SWITCH command requesting the
receiver to switch roles with the sender. Whether the receiver accepts
or declines the request, the protocol remains in the Connected state.
The DISCONNECT command terminates the connection.  The AUTHENTICATE
command, when successful, begins the Authenticated state. From the
Authenticated state, the sender can:

1. begin sending an ITIP message to the receiver by issuing the
   RECIPIENT command,
2. re-authenticate as a different calendar using the AUTHENTICATE
   command,
3. request a queued ITIP message for the authenticated calendar using
   the DEQUEUE command,
4. execute the CAPABILITY command,
5. disconnect

Courtemanche/Mansour/O'Leary      4                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

In order to send an ITIP message to other calendars, the sender begins
by issuing the RECIPIENT command causing the protocol to enter the Send
state. The sender repeats the RECIPIENT command as many times as needed
to indicate all the target calendars. When all recipients have been
specified, the sender issues the ICALDATA command and supplies the
[ITIP] message. This causes the protocol to enter the Receive state
where the sender waits for a response from the receiver. If the
receiver's response indicates that the request has been completed the
protocol returns to the Authenticated state. If the receiver indicates
that the request could not be completed in the time specified by the
sender the protocol enters the Idle state. At this point the sender
must decide how to proceed. If the sender issues the CONTINUE command,
the command in progress continues and the session returns to the
Receive state. If the sender issues the ABORT command the command is
aborted and the session is returned to the Authenticated state.

The sender may decide to abort sending the ITIP message while it issues
the RECIPIENT commands (perhaps because a RECIPIENT does not exist). If
the sender issues the ABORT command after one or more RECIPIENT
commands, the protocol returns to the Authenticated state.

A sender can abort an operation in progress while it is in the Receive
state by sending an ABORT command to the receiver.

From the Authenticated state, a sender can also issue the DEQUEUE
command causing the protocol to request the receiver to return a single
queued ITIP message. Issuing the DEQUEUE command changes the protocol
to the Receive state. The receiver replies with a single queued [ITIP]
request or a status code to indicate that there are no more queued
requests for the authenticated user.

Though the DISCONNECT command should only be issued from the
Authenticated or Cnnected states, implementations should be prepared to
handle a DISCONNECT at any point in this state diagram.

2.2 Calendar Address

Calendar addresses, or CALIDs, are URIs. IRIP CALIDs use the following
form of URI.

    [<scheme>://<host>:<port>/]<relativeCALID>

where:

    <scheme> must be "irip"

    <host> is address of the computer on which the IRIP server is
           running. This is also called the Calendar Store ID or CSID.

    <port> is optional. Its default value is 5228.

    <relativeCALID> is an identifier that uniquely identifies the calendar
           on a particular calendar store. 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.

Courtemanche/Mansour/O'Leary      5                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

If the CSID is present the CALID is said to be "qualified". Qualified
CALIDs are necessary when the CSID of the [IRIP] server is different
form that of the CALID.

Examples:

    irip://calendar.example.com/user1
    user1
    irip://calendar.example.com/conferenceRoomA
    irip://calendar.example.com/89798-098-zytytasd

For the IRIP server on calendar.example.com, the first two addresses
refer to the same calendar.

2.3 Bounded Latency

[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
the request cannot be completed. When the Sender initiates a command
that the Receiver cannot complete within a given amount of time, the
Receiver can return an error code to the Sender indicating this
condition. The Sender then issues either a CONTINUE or ABORT command.
The ABORT command immediately terminates the command in progress. The
CONTINUE command instructs the Receiver to continue processing the
command. The ABORT command causes the Receiver to discard the current
command and return to the Authenticated state.

3 Protocol

3.1 Commands

IRIP commands are summarized in the table below and described in detail
in the following sections.

+=================================================+
| Command         Issued from State               |
+=================================================+
| ABORT           Idle, Send, Receive             |
| AUTHENTICATE    Connected, Authenticated        |
| CAPABILITY      Connected, Authenticated, Send  |
| CONTINUE        Idle                            |
| DEQUEUE         Authenticated                   |
| DISCONNECT      Connected, Authenticated        |
| ICALDATA        Send                            |
| RECIPIENT       Authenticated, Send             |
| SWITCH          Authenticated                   |
+=================================================+

Commands have the general form:

<command> [arguments...]

where <command> is a command listed in the table above. A command MAY
have arguments. Arguments are defined in the detailed command
definitions below. The length of a command and its arguments, and the
terminating <CRLF> MUST be l024 characters or less.

Responses to commands have the following general form:

Courtemanche/Mansour/O'Leary      6                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

[ICAL OBJECT]
.
<reply code> [arguments...]

A response MAY include an [ICAL] object.  This is followed by a
<CRLF>.<CRLF> and a reply code. The reply code may have associated
arguments. These arguments are defined in the REPLY CODE section below.
Arguments MUST NOT be present unless they are specifically called for
by the particular reply code. The length of the reply code, any
arguments, and the terminating <CRLF> MUST be l024 characters or less.

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
from being processed further. When the latency time is specified 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 that the
server has not yet processed the request.  The sender must then tell
the server whether to continue or abort.

The Sender can issue the ABORT command at any time after the ICALDATA
command has been completed but before the sender receives a reply.

Example:
	
...
S: RECIPIENT irip://cal.example.com/abc
R: 2.0
S: RECIPIENT irip://cal.example.com/def
R: 2.0
S: ICALDATA:10
R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: quoted-printable
S: 
S: BEGIN:VCALENDAR
S: ...
S: END:VCALENDAR
S: .
<10 seconds elapse...>
R: .
R: 2.0.2 irip://cal.example.com/abc
R: 2.0.2 irip://cal.example.com/def
S: ABORT
R: 2.0.3
S: <sender can now begin another command or it can disconnect>

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:

S: ICALDATA:10
S: <an ICAL object>
S: .

Courtemanche/Mansour/O'Leary      7                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

<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 AUTHENTICATE command is used by the client to identify the user to
the server.  [IRIP] uses the [SASL] specification for authentication.
This allows [IRIP] users to choose from a variety of authentication
mechanisms.  The only IRIP] commands which can be issued before
authentication occurs are AUTHENTICATE, CAPABILITY, SWITCH and
DISCONNECT.

The AUTHENTICATE command initiates the authentication protocol
exchange.  It takes the following form:

AUTHENTICATE <mechanism> [<initial data>]

Where <mechanism> is a registered SASL authentication mechanism.
(Refer to [SASL] for information on obtaining a list of currently
registered mechanisms.) <initial data> is an optional parameter which
can be used for mechanisms which require an initial Sender response.

If the mechanism is not supported by the Receiver it must indicate this
with a "." CRLF and the reply code 6.1 indicating that the
authentication mechanism is not supported.  Supported authentication
mechanisms can be discovered using the CAPABILITY command.

If the mechanism is supported an authentication protocol exchange takes
place, in the form of a series of Receiver challenges and Sender
responses.  The Receiver terminates the exchange with a "." on a single
line followed by a reply code.  Successful authentication is indicated
with the reply code 2.0, and unsuccessful authentication is indicated
with the reply code 6.0.  If the authentication was successful, but the
authorization identity was not accepted the status code 6.3 is used.
Upon successful authentication the protocol enters the Authenticated
state, otherwise it remains in the Connected state.

In the authentication protocol exchange both Receiver challenges and
Sender responses consist of the authentication mechanism data
transformed into BASE64 and followed by a CRLF.  If the Sender wishes
to cancel an authentication exchange, it issues a line with a single
".".  Upon receipt of such an answer, the Receiver MUST indicate the
end of the exchange with a "."  CRLF followed by reply code 6.2
indicating that the exchange was aborted.

If a security layer was negotiated it comes into effect for the
Receiver starting with the first octet transmitted after the CRLF which
follows the 2.0 reply code, and for the Sender starting with the first
octet after the CRLF that concludes the authentication exchange for the
client.  Data is transmitted as described in [SASL].

The service name specified by this protocol's profile of SASL is
"irip".

Courtemanche/Mansour/O'Leary      8                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

The following examples illustrate the various possiblities for an
authentication protocol exchange using Kerberos Version 4.

Successful authentication:

S: AUTHENTICATE KERBEROS_V4
R: AmFYig==
S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
R: or//EoAADZI=
S: DiAF5A4gA+oOIALuBkAAmw==
R: .
R: 2.0

Failed authorization:

S: AUTHENTICATE KERBEROS_V4
R: AmFYig==
S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
R: or//EoAADZI=
S: DiAF5A4gA+oOIALuBkAAmw==
R: .
R: 6.3

Failed authentication:

S: AUTHENTICATE KERBEROS_V4
R: AmFYig==
S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
R: .
R: 6.0

Sender aborted authentication:

S: AUTHENTICATE KERBEROS_V4
R: AmFYig==
S: .
R: .
R: 6.2

Unsupported mechanism:

S: AUTHENTICATE Experimental_Auth
R: .
R: 6.1

3.1.2.1 Authentication with Proxy Access

Some [SASL] mechanisms allow the Sender to transmit an authorization
identity which is different from the authentication identity.  [IRIP]
depends upon this ability in that it is servers who authenticate to
each other in order to process requests for users.  The user which the
Sender is representing is transmitted as the authorization identity
during the [SASL] exchange.  This identity takes the form of a
caladdress URL.

The authorization identity is used to administer the [ITIP] security
paradigm. Thus in an [IRIP] session REQUESTs may be issued for events
of which the authorized caladdress is the Organizer, RESPONSEs or
COUNTERs may be issued for events which the authorized caladdress is

Courtemanche/Mansour/O'Leary      9                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

Attending, etc.

3.1.2.2 Selection of an Authentication Mechanism

The authentication mechanisms which a Receiver supports may be
discovered through use of the CAPABILITY.  From the supplied list the
Sender may choose its preferred mechanism.

Not all mechanisms will be supported on all servers.  There is no
minimum level of security which an [IRIP] compliant server is required
to suppot.  This may result in iRIP servers which are unable to talk to
each other through lack of a common mechanism.  This issue is covered
in more detail in the Security Considerations section of this
document.  3.1.3 CAPABILITY

The CAPABILITY command tells the server to return a list of
capabilities it supports.  The server must return a CAPABILITY response
with "IRIPrev1" as one of the listed capabilities.  The CAPABILITY
command can be issued in any connection state. The response may differ
depending on the current state of the connection. The responses may
also differ depending upon the authenticated user.

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. Each line, including the terminating <CRLF> MUST be
1024 characters or less. The sequence <CRLF>.<CRLF> followed by a reply
code terminates the response.

The table below summarizes the information available in response to a
CAPABILITY command.

Capability            Occurs  Description
--------------------- ------- ----------------------------------
IRIPrev1                  1   Revision of IRIP, must be
                              "IRIPrev1"

AUTH                      0+  Authentication mechanism(s)
                              supported  

MAXICALOBJECTSIZE     0 or 1  An integer value that specifies 
                              The largest ICAL object the server
                              will accept. Objects larger than
                              this will be rejected.

MAXDATE               0 or 1  The datetime value beyond which
                              the server cannot accept.

MINDATE               0 or 1  The datetime value prior to which
                              the server cannot accept.

Examples:

When executed from the Connected state the following occur:

S: CAPABILITY
R: CAPABILITY IRIPrev1
R: AUTH=KERBEROS_V4
R: AUTH=PLAIN
R: .

Courtemanche/Mansour/O'Leary     10                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

R: 2.0

When executed from the Authenticated state the following occur:

S: CAPABILITY
R: CAPABILITY IRIPrev1
R: AUTH=KERBEROS_V4
R: AUTH=PLAIN
R: MAXICALOBJECTSIZE=50000
R: .
R: 2.0

3.1.4 CONTINUE

The CONTINUE command is issued by the sender to allow an ICALDATA
request to continue being processed. When the latency time is specified
on the ICALDATA command, the Receiver must issue a reply to the Sender
within the specified time.  The reply could be a reply code indicating
that the server has not yet processed the request.  The Sender must
then tell the server whether to continue or abort the command in
progress.

The CONTINUE has the following form:

	CONTINUE[:latencyTime]

If the optional latencyTime is present, it is a positive integer that
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
server every 10 seconds.

...
S: ICALDATA:10
R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
<etc>
S: END:VCALENDAR
S: .
<after 10 seconds...>
R: .
R: 2.0.2  Reply Pending
S: CONTINUE:10
R: BEGIN:VCALENDAR
<etc>
R: END:VCALENDAR
R: .
R: 2.0

3.1.5 DEQUEUE

The DEQUEUE command requests the Receiver to send a single queued
message to the Sender. This differs from using the SWITCH command in

Courtemanche/Mansour/O'Leary     11                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

several ways:

* the SWITCH command results in the Connected state after the Sender
and Receiver roles are reversed. This means that both the Sender and
Receiver must be prepared to handle the AUTHENTICATE command. Using the
DEQUEUE command, queued commands can be collected by the original
Sender without it having to handle the AUTHENTICATE command.

* Only one message is transferred per DEQUEUE command.

* The single and implicit receiver of a DEQUEUE message is the
currently authenticated Sender.

The DEQUEUE command has the following format:

DEQUEUE calid

If the Receiver has a queued message for the CALID and the
authenticated user is allowed to access the queue, it will be sent as
the reply to the DEQUEUE message. The message is followed by a
(required) <CRLF>.<CRLF> and a (required) response code.

Example:

S: DEQUEUE irip://cal.example.com/sman
R: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
R: Content-Transfer-Encoding: 7bit
R:
R: BEGIN:VCALENDAR
<etc.>
R: END:VCALENDAR
R: .
R: 2.0
S: DEQUEUE irip://cal.example.com/sman
R: .
R: 2.0.8
3.1.6 DISCONNECT

The DISCONNECT command signals the end of communication between the
Sender and Receiver. It can be sent from any state.

Example:

S: DISCONNECT
R: 2.0

3.1.7 ICALDATA

The ICALDATA command is used to specify the iCalendar Object that is to
be delivered to one or more recipients specified in the RECIPIENT
command.  The format of the command sequence is:

S: ICALDATA[:latencyTime]
R: 2.0.1
S: <MIME encapsulated ITIP Message>
S: .
R: <MIME encapsulated ITIP Message>
R: .
R: <reply code>

Courtemanche/Mansour/O'Leary     12                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

The optional latencyTime value specifies the maximum number of seconds
the sender will wait for a reply.  If it is not present, the client
places no time limit on the server for a reply. A reply code of 2.0.1
indicates that the [ITIP] message data can be sent.  The data must be
broken into lines that are 1024 characters (including the ending <CRLF>
or less. When the entire message has been sent, the sender terminates
sending data with the special sequence <CRLF>.<CRLF>. The receiver
reply may optionally contain an ITIP message followed by the special
sequence <CRLF>.<CRLF> followed by a reply code for each of the
recipients. Only the [ITIP] message is optional in the reply, the
<CRLF>.<CRLF> sequence must be present. The command sequence for an
IRIP server that does not include an [ITIP] message in the reply might
appear as follows:

S: RECIPIENT irip://cal.example.com/johndoe
R: 2.0
S: RECIPIENT irip://cal.othersystem.com/xyz
R: 2.0.5
S: ICALDATA
R: 2.0.1
<lots of data>
S: .
R: .
R: 2.0 irip://cal.example.com/johndoe
R: 2.0.7 irip://cal.othersystem.com/xyz

IRIP servers are not required to send [ITIP] messages in the reply to
ICALDATA command. However, the protocol allows for high performance
servers to do so. IRIP senders MUST accept the [ITIP] message if the
receiver includes it the reply.  3.1.8 RECIPIENT

The RECIPIENT command is used to identify a recipient of the iCalendar
Object.  Use multiple RECIPIENT commands to specify multiple
recipients.  The command format is

RECIPIENT <calendar address>

A reply code will be returned for each calendar address supplied. A
response code for each valid calendar address will also be returned
after the ICALDATA command completes.

A reply 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 responds with [ITIP] reply code
5.3 to indicate that the calendar address is unknown. If the receiver
knows has a referral calendar address it responds with reply code 10.1
and supplies 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.

After the ITIP message has been sent, a reply code will be returned for
each of the recipients.

3.1.8.1 Fanout Issues On RECIPIENT

A receiver may be implemented such that it will fanout requests to
other IRIP servers. That is, a sender connects to IRIP receiver at
A.example.com and specifies a RECIPIENT calendar address on

Courtemanche/Mansour/O'Leary     13                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

B.example1.com. If the IRIP server at A.example.com handles getting the
request to the receiver at B.example1.com it supports fanout.

               IRIP                         IRIP
    Sender ----------- [A.example.com] --------------- [B.example.com]
                         
An IRIP server implementation can implement fanout in different ways.
One way involves verifying remote recipient calendars in real-time.
Another way saves up all remote recipient calendars and simply attempts
to access them later. The advantage of verifying remote calendars in
real-time is that the sender is notified immediately, via the reply
code, whether or not the recipient calendar exists and is accessible.
For example, suppose that the IRIP server on A.example.com just
received the following command from Sender:

RECIPIENT irip://b.example.com/sam

If A.example.com immediately contacts B.example.com and issues a
RECIPIENT irip://b.example.com/sman and returns the reply back to
Sender, the sender will have an authoritative reply code (2.0 -
success, 3.7 - invalid calendar, or 10.1 - referral). On the other
hand, if A.example.com simply collect all the remote calendar addresses
and attempt to access them later in the transaction the reply will be
2.0.4 (will attempt). The disadvantage of this approach is that the
sender does not know the status of the target calendar during the
RECIPIENT negotiation.

3.1.9 SWITCH The SWITCH command is used to allow the Sender and
Receiver to change roles. After a switch command is executed and the
new Sender authenticates, all queued commands that the new Sender has
queued for the new Receiver will be delivered. Its format is:

    SWITCH

The SWITCH command is useful in environments where the firewall of a
Sender would not allow the Receiver to initiate a connection. 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
authenticated state before the SWITCH command can be used.

The Receiver must respond in one of the following fashions:

* send an OK reply and take on the role of Sender
* send a error reply indicating refusal and retain the role of Receiver

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
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
response to a SWITCH command then program-B becomes the Sender.
Program-B is then in the initial state (connected) as if it had just
connected to Program-A, and expects to receive a service ready
greeting.

3.2 Fanout and Queued Transactions

An IRIP server must be able to fanout requests targeted at other IRIP
servers. An IRIP server may queue information targeted at other IRIP

Courtemanche/Mansour/O'Leary     14                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

servers. There are several reasons for queing requests. One reason is
that firewall issues may prevent one server from contacting another.

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.  [Editors
Note: do we really want to impose this restriction?]

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 the reply code to the RECIPIENT
command indicates whether or not a reply will be made in real-time.
This allows the sender to abort the request if necessary.

3.3 Bi-Directional Queue Operation

It is possible that firewall configurations may not allow a connection
between two IRIP servers in either direction. That is, in the diagram
below, suppose there are two users, sender1 and sender2, who wish to
exchange [ITIP] messages. Their calendar addresses are
irip://B.foo.com/sender1 and irip://D.bar.com/sender2.  The firewall in
front of B.foo.com prevents external connection on the IRIP server
port. Similarly, the firewall in front of D.bar.com also prevents
connections on the IRIP server port. To allow sender1 and sender2 to
exchange IRIP messages an intermediate IRIP server, C.foobar.com, is
used to queue messages for both of their calendars. A trust
relationship between the intermediate IRIP server and the endpoint
servers (B.foo.com and D.bar.com) is desirable but not required.
[Editors note: is desired but not required OK with everyone?]

         IRIP   +-----------+           +-----------+  IRIP
sender1 --------| B.foo.com |--#--+--#--| D.bar.com |------- sender2
                +-----------+     |     +-----------+
                                  |
                          +----------------+
                          |  C.foobar.com  |
                          +----------------+

3.4 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
when returned by an [IRIP] command.

In addition to those defined in [ITIP], [IRIP] defines the following
error codes:

Courtemanche/Mansour/O'Leary     15                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

REPLY
CODE   DESCRIPTION             MEANING
------ ----------------------  --------------------------------------
2.0    STATOK                  Operation was successfully performed.

2.0.1  START-ICALDATA          Start ICAL input; end with
                               <CRLF>.<CRLF>

2.0.2  REPLY-PENDING           A timeout has occurred. The server is
                               still working on the reply. Use
                               CONTINUE to continue waiting for the
                               reply or ABORT to terminate the
                               command.

2.0.3 ABORTED                  In response to the client issuing an
                               ABORT command, this reply code
                               indicates that any command currently
                               underway was successsfully aborted.

2.0.4 WILL-ATTEMPT             The specified Calendar is not here
                               but An attempt will be made to deliver
                               the request or reply to the Calendar
                               anyway. There is a trust relationship
                               between this IRIP server and the
                               IRIP server for the target calendar.

2.0.5  TRUSTED-WILL-QUEUE      The specified Calendar cannot be
                               contacted directly and a trust
                               relationship exists between this server
                               and the server on which the Calendar
                               exists. 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.

2.0.6  WILL-ATTEMPT            The specified Calendar is not here
                               but an attempt will be made to deliver
                               the request or reply to the Calendar
                               anyway. The 

2.0.7  QUEUED                  The message has been queued for
                               delivery.

2.0.8  QUEUE-EMPTY             There are no more queued messages.

8.0    GENERAL FAILURE         A failure has occurred in the Receiver
                               that prevents the operation from
                               succeeding.

8.1    SERVER TOO BUSY         Sent when a session cannot be
                               established because the [IRIP]
                               Receiver is too busy.

8.2    ICAL OBJECT TOO BIG     Used to signal that an ICAL object has
                               exceeded the server's size limit.

8.3    DATE TOO LARGE          A DATETIME value was too large to be

Courtemanche/Mansour/O'Leary     16                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

                               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.
                               The RECIPIENT specified should be
                               contacted at the given alternate
                               address. The referral address MUST
                               follow the reply code.

10.2   SERVER SHUT DOWN        The server is shutting down.

10.4   EXCEEDED QUOTAS         The operation has not be performed
                               because it would cause the resources
                               (memory, disk, CPU, etc) to exceed the
                               allocated quota

10.5   QUEUED TOO LONG         The ITIP message has been queued too
                               too long. Delivery has been aborted.

4 Implementation Considerations

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.

5 Security Considerations

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.

In addition to the security risks detailed in [ITIP], the following
sections discuss security risks in using [IRIP] as the transport
binding.

5.1 Spoofing

The [ITIP] paradigm allows any modifications to data by its Organizer,
which maps to the [SASL] authorization identity.  This means that
authorizing with appropriate identities over [IRIP] will allow read and
write access to any item in the Receiver's database.  There are several
ways to limit this security risk.

The choice of accepted authentication mechanisms can reduce the
security risk. The ANONYMOUS mechanism allows a greater level of

Courtemanche/Mansour/O'Leary     17                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

interoperability, in that any Sender can connect anonymously, but
greatly increases the security risk for the same reason.

The method in which authorizations are accepted can also be modified to
improve security.  Some hosts may be trusted to authorize as any
caladdress, while others may be only be trusted to authorize as users
in their domain.

[ITIP] data is transmitted in MIME containers, which provide a facility
for digitally signing their data.  A sender may use this scheme in
order to provide a final security fallback.

Finally, some implementations may decide to queue incoming [IRIP]
commands for approval by the owner of the calendar, although this is
certainly the least reliable of these security mechanisms.

5.2 Eavesdropping

The use of SASL in [IRIP] allows the negotiation of an encrypted
security layer, which greatly reduces the chances that a connection
will be subject to eavesdropping.

However, if another [IRIP] server is being used to relay [IRIP] data
this relay server is privy to whatever information is being
transmitted. For this reason it may be desirable to use MIME's
encryption facility to protect the data.

5.3 Connection Flooding

Servers should be configurable to timeout unused connections.

6 Examples

6.1 Unauthenticated Freebusy Request

This examples shows an anonymous request for the freebusy time of
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>
S: <establish a TCP connection to cal.example.com port 5228>
R: 2.0 
S: AUTHENTICATE ANONYMOUS xyz
R: 2.0
S: RECIPIENT:irip://b.foo.bar/sman
R: 2.0 
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

Courtemanche/Mansour/O'Leary     18                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

S: BEGIN:VFREEBUSY
S: ORGANIZER: irip://b.foo.bar/xyz
S: ATTENDEE: irip://b.foo.bar/sman
S: DTSTAMP:19971113T190000Z
S: DTSTART:19971115T160000Z
S: DTEND:19971116T040000Z
S: UID:[email-masked]
S: END:VFREEBUSY
S: END:VCALENDAR
S: .

<server looks up the freebusy time and builds a reply>

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://cal.example.com/xyz
R: ATTENDEE:irip://cal.example.com/sman
R: DTSTAMP:19971113T190005Z
R: DTSTART:19971115T160000Z
R: DTEND:19971116T040000Z
R: UID:[email-masked]
R: FREEBUSY:19971113T230000Z/PT1H,19971114T210000Z/PT30M
R: END:VFREEBUSY
R: END:VCALENDAR
R: .
R: 2.0 sman
R: .
S: DISCONNECT
R: 2.0
R: <disconnect>
S: <disconnect>

6.1.1 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

Courtemanche/Mansour/O'Leary     19                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

<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:[email-masked]
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

Courtemanche/Mansour/O'Leary     20                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

R: UID:[email-masked]
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:[email-masked]
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:[email-masked]
R: FREEBUSY:19971115T230000Z/PT1H,19971116T210000Z/PT30M
R: END:VFREEBUSY
R: END:VCALENDAR
R:
R:----FEE3790DC7E35189CA67CE2C
R: .
R: 2.0 irip://B.foo.com/bill 
R: 2.0 irip://C.foobar.com/cathy 
R: 2.0 irip://E.barfoo.com/eddie 
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.2 Using Switch

Courtemanche/Mansour/O'Leary     21                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

This session demonstrates how a poll can be accomplished using the
SWITCH command.  In this case, the sender (S) becomes the receiver (R)
after issuing the switch command.

R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228>
R: 2.0
S: AUTHENTICATE KERBEROS_V4
R: + AmFYig==
S: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
R: + or//EoAADZI=
S: DiAF5A4gA+oOIALuBkAAmw==
R: 2.0
S: SWITCH
R: 2.0
<sender now becomes the receiver>
S: 2.0
R: AUTHENTICATE KERBEROS_V4  27367ao986pq8u98u9e8w0-0--0--0werg
S: 2.0
<receiver can now authenticate and send anything pending for the sender>

6.3 Fanout Requests

6.3.1 Successful Fanout Request

In the diagram below, sender has authenticated to the IRIP server
B.foo.com and is attempting to deliver a request to calendars on
B.foo.com and C.foobar.com.  The IRIP server on B.foo.com supports
fanout. It verifies remote calendars during the RECIPIENT negotiation
with sender.

                 +-----------+         +-----------+
 sender ---------| B.foo.com |---------| D.bar.com |
                 +-----------+         +-----------+

Connection between S and B.foo.com     Connection B.foo.com to D.bar.com
S = sender                             S = B.foo.com
R = B.foo.com                          R = D.bar.com
-----------------------------------    ----------------------------------
R: <listen on TCP port 5228>           R: <listen on TCP port 5228>
S: < connect 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://D.bar.com/david    S: <connect to D.bar.com port 5228>
                                       R: 2.0
                                       S: <authenticates as irip server
                                           B.foo.com>
                                       R: 2.0
                                       S: RECIPIENT:irip://D.bar.com/david
                                       R: 2.0
R: 2.0
S: ICALDATA
R: 2.0.1

Courtemanche/Mansour/O'Leary     22                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

S: <sends icaldata>
S: .                                   S: ICALDATA
                                       R: 2.0.1
                                       S: <sends icaldata>
                                       S: .
                                       R: .
                                       R: 2.0 irip://D.bar.com/david
R: .
R: 2.0 irip://B.foo.com/bill
R: 2.0 irip://D.bar.com/david
S: DISCONNECT
R: 2.0

6.3.2 Referral On Fanout

This example is just like the one above except that in this case the
remote calendar no longer exists and a referral is returned. The sender
cancels the transaction in the RECIPIENT phase (using ABORT) and starts
a new transaction that uses the referral address.

                 +-----------+         +-----------+
 sender ---------| B.foo.com |----+----| D.bar.com |
                 +-----------+    |    +-----------+
                                  |
                                  |    +-----------+
                                  +----| E.xyz.com |
                                       +-----------+

Connection between S and B.foo.com     Connection B.foo.com to D.bar.com
S = sender                             S = B.foo.com
R = B.foo.com                          R = D.bar.com
====================================   ===================================
R: <listen on TCP port 5228>           R: <listen on TCP port 5228>
S: < connect 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://D.bar.com/david    S: <connect to D.bar.com port 5228>
                                       R: 2.0
                                       S: <authenticates as irip server
                                           B.foo.com>
                                       R: 2.0
                                       S: RECIPIENT:irip://D.bar.com/david
                                       R: 10.1 irip://E.xyz.com/david99
R: 10.1 irip://E.xyz.com/david99
S: ABORT
R: 2.0.3
S: RECIPIENT:irip://B.foo.com/bill
R: 2.0
S: RECIPIENT irip://E.xyz.com/david99  Connection B.foo.com to E.xyz.com
                                       S = B.foo.com
                                       R = E.xyz.com
                                       ===================================
                                       S: <connect to D.bar.com port 5228>

Courtemanche/Mansour/O'Leary     23                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

                                       R: 2.0
                                       S: <authenticates as irip server
                                           B.foo.com>
                                       R: 2.0
                                       S: RECIPIENT irip://E.xyz.com/david99
                                       R: 2.0
R: 2.0
R: ICALDATA
S: <sends icaldata>
S: .                                   S: ICALDATA
                                       R: 2.0.1
                                       S: <sends icaldata>
                                       S: .
                                       R: .
                                       R: 2.0 irip://E.xyz.com/david99
R: .
R: 2.0 irip://B.foo.com/bill
R: 2.0 irip://E.xyz.com/david99
S: DISCONNECT
R: 2.0

6.4 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.4.1 Meeting Invitation

In this example, S sends an event request to the IRIP server on B for
calendars on B, C, D, E, and F.  Note that C's address moved from
foo.com to foobar.com and is reported to the sender during the
RECIPIENT negotiation. Also note that F's address is no longer valid at
foo.com and that no referral is returned.

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.foo.com/cathy
R: 10.1 irip://C.foobar.com/cathy

Courtemanche/Mansour/O'Leary     24                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

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: RECIPIENT:irip://F.foo.com/fred
R: 5.3
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:[email-masked]
S: SEQUENCE:0
S: STATUS:CONFIRMED
S: END:VEVENT
S: END:VCALENDAR
S: .
R: .
R: 2.0 irip://B.foo.com/bill 
R: 2.0 irip://C.foobar.com/cathy 
R: 2.0.7 irip://D.bar.com/david 
R: 2.0 irip://E.barfoo.com/eddie 
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.

6.5 Resource Scheduling

R: <listen on TCP port 5228>

Courtemanche/Mansour/O'Leary     25                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

S: <connect to port 5228>
R: 2.0 
S: AUTHENTICATE KERBEROS_V4 7SF8S3&#
<more authentication information>
R: 2.0
S: RECIPIENT irip://b.foo.bar/Large_Conference_Room
R: 2.0
S: RECIPIENT irip://b.foo.bar/Overhead_Projector_1
R: 2.0
S: ICALDATA: 10
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Inlet MIMEDIR//EN
S: VERSION:2.0
S: METHOD:REQUEST
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: DTEND:19980706T203000Z
S: LOCATION:Large Conference Room
S: DESCRIPTION:Big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR
S: .
R: <looks up availability in database>
R: .
R: 2.0 irip://b.foo.bar/Overhead_Projector_1
R: 2.0 irip://b.foo.bar/Large_Conference_Room
S: RECIPIENT Large_Conference_Room
R: 2.0
S: RECIPIENT Overhead_Projector_1
R: 2.0
S: ICALDATA: 10
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
S: VERSION:2.0
S: METHOD:REQUEST
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: DTEND:19980708T230000Z
S: LOCATION:Large Conference Room
S: DESCRIPTION:Another big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR
S: .

Courtemanche/Mansour/O'Leary     26                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

R: <looks up availability in database>
R: .
< Large_Conference_Room not available, thus the response code is...>
R: 4.0 irip://cal.example.com/Large_Conference_Room
R: 2.0.9 irip://cal.example.com/Overhead_Projector_1
S: RECIPIENT Large_Conference_Room
R: 2.0
S: RECIPIENT Overhead_Projector_1
R: 2.0
S: ICALDATA: 10
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
S: VERSION:2.0
S: METHOD:REQUEST
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: DTEND:19980708T170000Z
S: LOCATION:Large Conference Room
S: DESCRIPTION:Another big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR
S: .
R: <looks up availability in database>
<10 seconds pass>
R: .
<Database too busy, thus the response code is...>
R: 2.0.2 irip://cal.example.com/Large_Conference_Room
R: 2.0.2 irip://cal.example.com/ Overhead_Projector_1
S: ABORT
R: 2.0
S: DISCONNECT
R: 2.0
R: <drops TCP connection>

7 Acknowledgments

The following have participated in the drafting and discussion of this
memo:

Bruce Kahn, Doug Royer, Mugino Saeki

8 Bibliography

[ICAL] F. Dawson, D. Stenerson, "Internet Calendaring and Scheduling
Core Object Specification - iCalendar", ", RFC-2445, November 1998,
http://www.imc.org/rfc2445.

[ITIP] S. Silverberg, S. Mansour, F. Dawson, R. Hopson, "iCalendar
Transport-Independent Interoperability Protocol (iTIP) : Scheduling

Courtemanche/Mansour/O'Leary     27                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

Events, Busy Time, To-dos and Journal Entries", RFC-2446, November
1998, http://www.imc.org/rfc2446.

[IMIP] F. Dawson, S. Mansour, S. Silverberg, "iCalendar Message-based
Interoperability Protocol (iMIP), ", RFC-2447, November 1998,
http://www.imc.org/rfc2447.

[ID-UTF8] [AC3]"UTF-8, a transformation format of ISO 10646. F.
Yergeau.", RFC 2299, January 1998

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

[RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC
1847, October 1995.

[RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC
2112, March 1997.

[RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP),"
RFC 2015, October 1996.

[RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
2045, November 1996.

[RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.

[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.

[RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048,
January 1997.

[RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
9 Open Issues

Registration of the [SASL] profile for [IRIP] with the IANA.
Port Number registration

10 Author's Address

The following address information is provided in a vCard v2.1,
Electronic Business Card, format.

BEGIN:VCARD
FN:Andre Courtemanche
ORG:CS&T
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 3L5;Canada
TEL;WORK;MSG:+1-514-733-8500
TEL;WORK;FAX:+1-514-733-8788
EMAIL;INTERNET:[email-masked]
END:VCARD

Courtemanche/Mansour/O'Leary     28                  Expires August 1999

Internet Draft                  IRIP                   February 25, 1999 

BEGIN:VCARD
VERSION:2.1
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain 
  View;CA;94043;USA
TEL;WORK;MSG:+1-650-937-2378
TEL;WORK;FAX:+1-650-937-2103
EMAIL;INTERNET:[email-masked]
END:VCARD

BEGIN:VCARD
FN:Pete O'Leary
ORG:Amplitude
ADR;WORK;POSTAL;PARCEL:;;
TEL;WORK;MSG:+1-415-659-3511
TEL;WORK;FAX:+1-415-659-0006
EMAIL;INTERNET:[email-masked]
END:VCARD

11 Full Copyright Statement

Copyright (C) The Internet Society, January 2, 1999.  All Rights
Reserved.

This document and translations of it MAY be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation MAY be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself MAY NOT be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process MUST be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.