draft-ietf-calsch-irip-02.txt   draft-ietf-calsch-irip-03.txt 
Network Working Group Andre Coutemanche/CS&T Network Working Group Andre Courtemanche, CS&T
Internet Draft Steve Mansour/Netscape Internet Draft IRIP Steve Mansour, Netscape
<draft-ietf-calsch-irip-02.txt Pete O'Leary/Amplitude <draft-ietf-calsch-irip-03.txt> Pete O'Leary, Amplitude
Expires six months from: November 19, 1998 Expires 6 months after: April 16, 1999
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 and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas, and provisions of Section 10 of RFC2026.
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 are working documents of the Internet Engineering Task
Internet-Drafts may be updated, replaced, or made obsolete by other Force (IETF), its areas, and its working groups. Note that other
documents at any time. It is not appropriate to use Internet-Drafts as groups may also distribute working documents as Internet-Drafts.
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 Internet-Drafts are draft documents valid for a maximum of six months
1id-abstracts.txt listing contained in the Internet-Drafts Shadow and may be updated, replaced, or obsoleted by other documents at any
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), time. It is inappropriate to use Internet-Drafts as reference
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). material or to cite them other than as "work in progress."
Distribution of this document is unlimited.
Abstract The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
This document specifies a binding from the iCalendar The list of Internet-Draft Shadow Directories can be accessed at
Transport-independent Interoperability Protocol [ITIP] to a real-time http://www.ietf.org/shadow.html.
transport. Calendaring entries defined by the iCalendar Object Model
[ICAL] are composed using constructs from [RFC-2045], [RFC-2046],
[RFC-2047], [RFC-2048] and [RFC-2049].
This document is based on the calendaring and scheduling model defined Abstract
by [ICMS].
This document specifies a binding from the iCalendar Transport-
independent Interoperability Protocol [ITIP] to a real-time transport.
Calendaring entries defined by the iCalendar Object Model [ICAL] 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 This document is based on discussions within the Internet Engineering
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.
Mansour/Courtemanche/O'Leary 1 Expires August 1999
Table Of Contents
1 Introduction 3
1.1Related Memos 3
1.2Formatting Conventions 3
2 Architecture 4
2.1Protocol States 5
2.2Calendar Address 6
2.3Bounded Latency 7
3 Protocol 7
3.1Commands 7
3.1.1ABORT 8
3.1.2AUTHENTICATE 9
3.1.3CAPABILITY 12
3.1.4CONTINUE 13
3.1.5DEQUEUE 14
3.1.6DISCONNECT 15
3.1.7RECIPIENT 15
3.1.8SENDATA 17
3.1.9SWITCH 19
3.2Fanout and Queued Transactions 19
3.3Bi-Directional Queue Operation 20
3.4Reply Codes 20
4 Implementation Considerations 23
5 Security Considerations 23
5.1Security Threats and Recommendations 23
5.1.1Authentication Hacking 23
5.1.2Spoofing 23
5.1.3Eavesdropping 24
5.1.4Connection Flooding 24
5.2Security Interoperability Issues 24
6 Examples 24
6.1Unauthenticated Freebusy Request 24
6.2Busy Time Request 25
6.3Using Switch 28
6.4Fanout Requests 29
6.4.1Successful Fanout Request 29
6.4.2Referral On Fanout 30
6.5Queued Requests 31
6.5.1Meeting Invitation 32
7 Acknowledgments 33
8 Bibliography 33
9 Open Issues 34
10 Author's Address 34
11 Full Copyright Statement 36
Mansour/Courtemanche/O'Leary 2 Expires August 1999
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 to convey iCalendar Transport-independent Interoperability
Protocol [ITIP] over a real-time transport. Protocol [ITIP] messages over a real-time transport.
1.1 Related Memos 1.1 Related Memos
Implementers will need to be familiar 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 a real-time binding for [ITIP]. This document specifies a real-time binding for [ITIP].
- [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 document does not attempt to repeat the specification of concepts This document does not attempt to repeat the specification of concepts
or definitions from these other memos. Where possible, references are or definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these concepts made to the memo that provides for the specification of these concepts
or 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
refer to elements of the calendaring and scheduling model, core object to refer to elements of the calendaring and scheduling model, core
or interoperability protocol defined in [ICMS], [ICAL] and [ITIP] some object or interoperability protocol defined in [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 [ITIP] 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
quoted-strings of text. All calendar components start with the letter capitalized, quoted-strings of text. All calendar components start
"V". For example, "VEVENT" refers to the event calendar component, with the letter "V". For example, "VEVENT" refers to the event
"VTODO" refers to the to-do calendar component and "VJOURNAL" refers to calendar component, "VTODO" refers to the to-do calendar component and
the daily journal calendar component. "VJOURNAL" refers to 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
requesting a scheduling calendar component be created or modified, for 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-
quoted-strings of text, followed by the word "property". For example, 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. Mansour/Courtemanche/O'Leary 3 Expires August 1999
"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, Property parameters defined by [ICAL] are referred to with lower case,
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) to forward real-
to forward real-time requests on behalf of Calendar User Agents (CUA) time requests on behalf of Calendar User Agents (CUA) and receive real-
and receive real-time responses. The goal of [IRIP] is to allow two or time responses. The goal of iRIP is to allow two or more CS's to
more CS's to establish connections with each other. However, the design establish connections with each other. However, the design of iRIP
of [IRIP] does not preclude its use from CUA directly to CS. [IRIP] does not preclude its use from CUA directly to CS. iRIP allows a CS to
allows a CS to initiate a session and perform operations on behalf of initiate a session and perform operations on behalf of multiple CUA's
multiple CUA's without the need to reauthenticate the session for each without the need to reauthenticate the session for each CUA.
CUA.
The sections and examples below refer to a "user", a "sender", and a The sections and examples below refer to a "user", a "sender", and a
"receiver". For purposes of this document these terms are defined as "receiver". For purposes of this document these terms are defined as
follows: follows:
user - the CU that initiates a request. user - the Calendar User that initiates a request.
sender - the agent used to contact a receiving device, send commands, sender - the agent used to contact a receiving device, send
and receive replies. commands, and receive replies.
receiver - the agent that accepts commands and sends replies. receiver - the agent that accepts commands and sends replies.
The sender and receiver can take on varying roles of CUA and CS as The sender and receiver can take on varying roles of a Calendar User
described in [ICMS]. Agent (CUA) and Calendar Store (CS).
[IRIP] allows two CS's to establish different levels of trust. When an iRIP allows two CS's to establish different levels of trust. When an
[IRIP] connection is first established, both parties to the connection iRIP connection is first established, the sender CS authenticates as
authenticate one another using the AUTHENTICATE command. The Sender can the iRIP server acting as a proxy for the originator of each ITIP
then initiate commands that the Receiver MUST interpret relative to the message being sent to the receiver.
Sender's access control. The AUTHENTICATE command supports proxy
operations via [SASL].
1.3 State Diagram Mansour/Courtemanche/O'Leary 4 Expires August 1999
An [IRIP] session begins when a TCP/IP connection is made on port 5228. 2.1 Protocol States1
The protocol begins in the Connected state. The AUTHENTICATE command,
when successful, begins the Authenticated state. From the Authenticated
state, the sender can initiate a request using the RECIPIENT command.
The Sender can then issues as many RECIPIENT commands as the operation
in progress requires until sending an ICALDATA command. After
completing the ICALDATA command, the Sender must wait for a response
from the receiver. The Receiver's response can indicate that the
request has been completed or that the request could not be completed
in the time specified by the Sender. When the response has ended, the
Sender returns to the Authenticated state where another request can be
initiated. Implementations should be prepared to handle a DISCONNECT
at any point in this state diagram.
+---------SWITCH-----------+ +------------+ The iRIP state diagram is shown below. The states are shown in the
| | +-DISCONNECT->| TERMINATED | boxes. State names are written with the first letter capitalized. The
| | | +------------+ commands used to switch between states are shown next to an arrow
V | | A connecting the states. The commands are listed in all capital letters.
+------------+ +---------------+ | A condition that causes a state to change is shown in lower case
| Connected |--AUTHENTICATE-->| Authenticated |----ERROR--+ letters.
+------------+ | |<--------+
+--------------ABORT--------->| (Proxy) | |
| +---->| |<---+ |
| | +---------------+ | |
| +--RECIPIENT--+ | | | | |
| | | +--AUTHENTICATE--+ | | |
+----------+ V | | COMPLETE
| Send |<---------------RECIPIENT--------+ | or
+----------+ | ABORT
| +--------COMPLETE or ERROR-------------+ |
ICALDATA | |
| | |
| +---------+ +--------+ |
+->| Receive |--(Response from Server)-->| Idle |---+
+---------+ +--------+
A |
| |
+--------------CONTINUE---------------+
1.4 Calendar Address CAPABILITY
or SWITCH
+----+
V |
+-------------+ DISCONNECT +---------------+
| |---------------->| Terminated |<-----------------+
| Connected | +---------------+ |
| |<---+ A |
+-------------+ | | |
| | | |
|AUTHENTICATE | AUTHENTICATE |DISCONNECT |
| | or CAPABILITY | |
| SWITCH| +----+ | |
| | V | | |
| +----------------------------------+ |
+--->| | ABORT +--------+ A
| Authenticated |<-------| Idle | |
+--->| |<--+ +--------+ |
| +----------------------------------+ | | A |
| | | complete| | | |
|ABORT |RECEIVE DEQUEUE| or| CONT| |latency |
| | | ABORT| INUE| |reply |
| V V | | |from |
+-------------+ +---------------+ | |server |
| | SENDATA | |<----+ | |
| Send |---------------->| Receive | | |
| | | |--------+ |
+-------------+ +---------------+ |
A | | DISCONNECT | DISCONNECT |
+----+ +---------------->-----------+-------------------------+
RECIPIENT
Calendar addresses are URIs. IRIP uses the following forms of URI. 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:
irip://<host>:<port>/<relativeCALID> 1. begin sending an ITIP message to the receiver by issuing the
Mansour/Courtemanche/O'Leary 5 Expires August 1999
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
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 SENDATA 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 Connected states, implementations should be prepared
to handle a DISCONNECT at any point in this state diagram.
2.2 Calendar Address
Calendar addresses, or CALUIDs, are URIs that are modeled after
[RFC2396]. iRIP CALIDs use the following form of URI.
[<scheme>://<host>[:<port>]/]<relativeCALUID>
where: where:
<host> is address of the computer on which the IRIP server is Mansour/Courtemanche/O'Leary 6 Expires August 1999
running <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. <port> is optional. Its default value is 5228.
<relativeCALID> is an identifier that uniquely identifies the calendar. <relativeCALUID> is an identifier that uniquely identifies the
There is no implied structure in a relativeCALID, it is an arbitrary calendar on a particular calendar store. There is no
string of characters. It may refer to the calendar of a user or of a implied structure in a relativeCALUID, it is an arbitrary
resource such as a conference room. string of 7-bit ASCII characters. It may refer to the
calendar of a user or of a resource such as a conference
room. It MUST be unique within the calendar store. It is
recommended that the relativeCALUID be globally unique.
If the CSID is present the CALID is said to be "qualified". Qualified
CALIDs are necessary when the CSID portion of a calendar address is
different from the Calendar Store on which the calendar user is
currently authenticated.
Examples: Examples:
irip://calendar.example.com/user1 irip://calendar.example.com/user1
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
1.5 Bounded Latency For the iRIP server on calendar.example.com, the first two addresses
refer to the same calendar.
[IRIP] is designed so that the Sender can either obtain an immediate 2.3 Bounded Latency
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 iRIP is designed so that the sender can either obtain an immediate
CONTINUE command instructs the Receiver to continue processing the response from a request or discover within a specified amount of time
command. The ABORT command causes the Receiver to discard the current that the request has not yet completed. The sender can initiate
command and return to the Authenticated state. commands with an optional latency time specified. When the sender
specifies the latency time and the receiver cannot complete the
operation within the specified amount of time, the receiver return an
appropriate response code to the sender. 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.
Mansour/Courtemanche/O'Leary 7 Expires August 1999
3 Protocol 3 Protocol
3.1 Commands 3.1 Commands
Reply codes MAY be followed by arbitrary text. The length of the reply iRIP commands are summarized in the table below and described in
code, any subsequent text, and the terminating <CRLF> MUST be 1024 detail in the following sections.
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.
In the examples below, lines preceded with "S:" refer to the Sender and +=================================================+
lines preceded with "R:" refer to the Receiver. | Command Issued from State |
+=================================================+
| ABORT Idle, Send, Receive |
| AUTHENTICATE Connected, Authenticated |
| CAPABILITY Connected, Authenticated, Send |
| CONTINUE Idle |
| DEQUEUE Authenticated |
| DISCONNECT Connected, Authenticated |
| SENDATA Send |
| RECIPIENT Authenticated, Send |
| SWITCH Connected, 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:
[ICAL OBJECT]
.
<reply code> [arguments...]
A response MAY include an [ICAL] object. Whether an [ICAL] object is
present or not, the sequence <CRLF>.<CRLF> followed by a reply code is
mandatory. The reply code may have associated arguments. These
arguments are defined in the command descriptions for each command.
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. Lines in which the
first non-whitespace character is a "#" are editorial comments and are
not part of the protocol.
3.1.1 ABORT 3.1.1 ABORT
The ABORT command is issued by the Sender to stop an ICALDATA request Mansour/Courtemanche/O'Leary 8 Expires August 1999
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 Arguments: none
command has been completed but before the Sender receives a reply.
Data: none
Result: 2.0 - success
2.2 - no command in progress
The ABORT command is issued by the sender to stop a command whose
latency time has been exceeded. When the latency time is specified on
the SENDATA 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 SENDATA
command has been completed but before the sender receives a reply.
Example: Example:
... ...
S: ICALDATA:10 S: RECIPIENT irip://cal.example.com/abc
R: 2.0 irip://cal.example.com/abc
S: RECIPIENT def
R: 2.0
S: SENDATA 10
R: 2.0.1 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: 2.0.2 R: 2.0.2 irip://cal.example.com/abc
R: 2.0.2 irip://cal.example.com/def
S: ABORT S: ABORT
R: 2.0.3 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>
The Receiver will issue the 8.2 reply code if it receives an ABORT when The Receiver will issue the 8.2 reply code if it receives an ABORT
the ICALDATA command is not in progress. This could happen if the when the SENDATA or DEQUEUE command is not in progress. This could
Sender issues an ABORT command at a point in time after the Receiver happen if the Sender issues an ABORT command at a point in time after
has completed the operation and issued the reply code but before the the Receiver has completed the operation and issued the reply code but
Sender has actually received the reply code. For example: before the Sender has actually received the reply code. For example:
S: ICALDATA:10 S: SENDATA 10
S: <an ICAL object> S: <an ICAL object>
S: . S: .
# 10 seconds elapse...
<10 seconds elapse...>
S: ABORT S: ABORT
Mansour/Courtemanche/O'Leary 9 Expires August 1999
R: 2.0 R: 2.0
R: 8.2 R: 8.2
In this case, the reply code 2.0 is in response to the [ICAL] object 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. and the reply code 8.2 is in response to the ABORT command.
3.1.2 AUTHENTICATE 3.1.2 AUTHENTICATE
The authentication mechanism used in [IRIP] is based on [SASL]. This Arguments: <SASL mechanism name> [<initial data>]
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
[IRIP].
The AUTHENTICATE command is used by the client to identify itself to Data: continuation data may be requested
the server. Authentication is required before the following commands
can be issued:
ABORT Result: 2.0 - Authenticate completed, now in authenticated state
AUTHENTICATE 6.0 - Failed authentication
CONTINUE 6.1 - authenticate failure: unsupported authentication
DISCONNECT mechanism, credentials rejected
ICALDATA 6.2 - Sender aborted authentication, authentication
RECIPIENT exchange cancelled
SWITCH 6.3 - Unsupported Authentication Mechanism
9.1 - Unexpected command.
The format of the command is of the following: 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.
AUTHENTICATE <mechanism> <initial data> The AUTHENTICATE command initiates the authentication protocol
exchange.
from which the standard [SASL] interchange will take place as defined <SASL mechanism name> is a registered SASL authentication mechanism.
in the [SASL] profile. Authentication mechanisms will differ from one (Refer to [SASL] for information on obtaining a list of currently
server to the other, from one version to another. The CAPABILITY registered mechanisms.) <initial data> is an optional parameter which
command must be used by the sender to determine the best authentication can be used for mechanisms which require an initial Sender response.
mechanism to use.
Example of an authentication session with kerberose version 4: 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.
R: 2.0 Welcome IRIP Server If the mechanism is supported an authentication protocol exchange
S: AUTHENTICATE KERBEROS_V4 744RTU3r# takes place, in the form of a series of Receiver challenges and Sender
S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf responses. The Receiver terminates the exchange with the
S: slkfjgsdlfjg;dslfjgdsfg <CRLF>.<CRLF> sequence followed by a reply code. Successful
S: ;lasfgsdfg 45243 z!$14325dc 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.
Mansour/Courtemanche/O'Leary 10 Expires August 1999
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 the <CRLF>.<CRLF>
sequence. Upon receipt of such an answer, the Receiver MUST indicate
the end of the exchange the <CRLF>.<CRLF> sequence 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".
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 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
Mansour/Courtemanche/O'Leary 11 Expires August 1999
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 3.1.2.1 Authentication with Proxy Access
The proxy mechanism is the ability to have data posted by an indirect Some [SASL] mechanisms allow the Sender to transmit an authorization
source. To handle this requirement, [SASL] mechanisms have a separate identity which is different from the authentication identity. iRIP
"Authentication" and "authorization" identity. Thus, server A could depends upon this ability in that it is servers who authenticate to
authenticate to server B using server A's credentials with the each other in order to process requests for users. The user which the
authorization identity of user X. This effectively allows PROXY Sender is representing is transmitted as the authorization identity
operations between servers. Some older [SASL] mechanisms do not during the [SASL] exchange. This identity takes the form of a CALID.
support both authentication and authorization and therefore cannot be
used when PROXY operations are required. As per the [SASL] profile,
the authorization identity is the one used to determine if the
operation should be allowed or not. The authentication identity ensures
the transaction is originating from a trusted sender.
3.1.2.2 Authentication for Anonymous Access 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 CALID is the Organizer, RESPONSEs or COUNTERs may
be issued for events which the authorized caladdress is Attending,
etc.
SASL defines an ANONYMOUS authentication mechanism that must be used if 3.1.2.2 Selection of an Authentication Mechanism
anonymous access is to be implemented by an [IRIP] capable server. This
is done by using the standard [SASL] authentication method and
requesting the ANONYMOUS mechanism. The mechanism consists of a single
message from the client to the server. The client sends optional trace
information in the form of a human readable string. It is recommended
that the trace information take one of three forms: An [RFC-822]
Internet e-mail address, an opaque ASCII string which does not contain
the "@" character and can be interpreted by the system administrator of
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 authentication mechanisms which a Receiver supports may be
string: discovered through use of the CAPABILITY. From the supplied list the
Sender may choose its preferred mechanism.
R: <listen on TCP port 5228> Not all mechanisms will be supported on all servers. There is no
S: <establish a connection to TCP port 5228> minimum level of security which an iRIP compliant server is required
R: 2.0 to support. This may result in iRIP servers which are unable to talk
S: AUTHENTICATE ANONYMOUS to each other through lack of a common mechanism. This issue is
R: + covered in more detail in the Security Considerations section of this
S: c21yaGM document.
R: 2.0
3.1.3 CAPABILITY 3.1.3 CAPABILITY
Arguments: none
Data: Server capability information as described below
Result: 2.0 - authenticate completed, now in authenticated state
The CAPABILITY command tells the server to return a list of The CAPABILITY command tells the server to return a list of
capabilities it supports. The server must return a CAPABILITY response capabilities it supports. The server must return a CAPABILITY
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 Mansour/Courtemanche/O'Leary 12 Expires August 1999
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.
Example: 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.
S: CAPABILITY Sender implementations SHOULD NOT require any capability name beyond
R: CAPABILITY IRIPrev1 those defined in this specification, and MUST tolerate any unknown
R: AUTH=KERBEROS_V4 capability names. This command may return different results in the
R: AUTH=PLAIN Connected states versus the Authenticated state. It may also return
R: . different results depending on the authenticated calendar user.
R: 2.0
The table below summarizes the information available response to a 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 command.
Capability Occurs Description Capability Occurs Description
--------------------- ------- ---------------------------------- --------------------- ------- ----------------------------------
IRIPrev1 1 Revision of IRIP, must be iRIPrev1 1 Revision of iRIP, must be
"IRIPrev1" "iRIPrev1"
AUTH 0+ Authentication mechanism(s) AUTH 0+ Authentication mechanism(s)
supported supported
MAXICALOBJECTSIZE 0 or 1 An integer value that specifies MAXICALOBJECTSIZE 0 or 1 An integer value that specifies
The largest ICAL object the server the largest ICAL object (byte count)
will accept. Objects larger than the server will accept. Objects larger
this will be rejected. than this will be rejected.
MAXDATE 0 or 1 The datetime value beyond which MAXDATE 0 or 1 The datetime value beyond which
the server cannot accept. the server cannot accept.
MINDATE 0 or 1 The datetime value prior to which MINDATE 0 or 1 The datetime value prior to which
the server cannot accept. the server cannot accept.
Examples:
When executed from the Connected state the following occur:
S: CAPABILITY
R: iRIPrev1
R: AUTH=KERBEROS_V4
R: AUTH=PLAIN
R: .
R: 2.0
When executed from the Authenticated state the following occur:
Mansour/Courtemanche/O'Leary 13 Expires August 1999
S: CAPABILITY
R: CAPABILITY iRIPrev1
R: AUTH=KERBEROS_V4
R: AUTH=PLAIN
R: MAXICALOBJECTSIZE=50000
R: .
R: 2.0
3.1.4 CONTINUE 3.1.4 CONTINUE
The CONTINUE command is issued by the Sender to allow an ICALDATA Arguments: [latencyTime]
request to continue being processed. When the latency time is specified Data: noneResult: results from the command in progress
on the ICALDATA command, the Receiver must issue a reply to the Sender 2.0.2 reply pending.
within the specified time. The reply could be a reply code indicating 9.1 unexpected command
that the server has not yet processed the request. The Sender must
then tell the server whether to continue or abort the command in The CONTINUE command is issued by the sender to allow an SENDATA
progress. request to continue being processed. When the latency time is
specified on the SENDATA 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: The CONTINUE has the following form:
CONTINUE[:latencyTime] CONTINUE [latencyTime]
If the optional latencyTime is present, it is a positive integer that If the optional latencyTime is present, it is a positive integer that
specifies the maximum number of seconds the client will wait for the specifies the maximum number of seconds the client will wait for the
next response. If it is omitted, the receiver waits an indefinite next response. If it is omitted, the receiver waits an indefinite
period of time for the response. period of time for the response.
In this example, the Sender requests some sort of response from the In this example, the sender requests a response from the server every
server every 10 seconds. 10 seconds.
... ...
S: ICALDATA:10 S: RECIPIENT irip://A.example.com/sman
R: 2.0
S: SENDATA 10
R: 2.0.1 R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
<etc> # etc...
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
<after 10 seconds...>
# after 10 seconds...
Mansour/Courtemanche/O'Leary 14 Expires August 1999
R: . R: .
R: 2.0.2 Reply Pending R: 2.0.2 Reply Pending
S: CONTINUE:10 S: CONTINUE 10
# less than 10 seconds elapse...
R: 2.0.11 irip://A.example.com/sman
R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
R: Content-Transfer-Encoding: 7bit
R:
R: BEGIN:VCALENDAR R: BEGIN:VCALENDAR
<etc> # etc...
R: END:VCALENDAR R: END:VCALENDAR
R: . R: .
R: 2.0
3.1.5 DISCONNECT 3.1.5 DEQUEUE
Arguments: caluid [latencyTime]
Data: a single queued itip message on success.
Result: 2.0 <caluid> success
2.0.2 <caluid> reply pending.
2.0.8 <caluid> no more messages
3.8 <caluid> no authority to perform this operation
9.1 unexpected command
The DEQUEUE command requests the Receiver to send a single queued
message to the Sender. This differs from using the SWITCH command in
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.
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
Mansour/Courtemanche/O'Leary 15 Expires August 1999
R:
R: BEGIN:VCALENDAR
# etc...
R: END:VCALENDAR
R: .
R: 2.0 irip://cal.example.com/sman
S: DEQUEUE irip://cal.example.com/sman
R: .
R: 2.0.8 irip://cal.example.com/sman
3.1.6 DISCONNECT
Arguments: none
Data: none
Result: 2.0 - success
The DISCONNECT command signals the end of communication between the The DISCONNECT command signals the end of communication between the
Sender and Receiver. It can be sent from any state. Sender and Receiver. It SHOULD be issued only from the Authenticated
or Connected states. However, receiver implementations MUST be
prepared to handle a DISCONNECT at any point in this state diagram.
Example: Example:
S: DISCONNECT S: DISCONNECT
R: 2.0 R: 2.0
3.1.6 ICALDATA 3.1.7 RECIPIENT
The ICALDATA command is used specify the iCalendar Object that is to be Arguments: caluid [latencyTime]
delivered to one or more recipients specified in the RECIPIENT
command. The format of the command is:
S: ICALDATA[:latencyTime] Data: none
Result: 2.0 <caluid> - Found the calendar
2.0.4 <caluid> - caluid is not on this irip server but an
attempt will be made to deliver the
request or reply to the Calendar anyway.
A trust relationship exists with IRIP
server for caluid.
2.0.5 <caluid> - just like 2.0.4 except that the message
MUST be queued. That is, it will not be
possible for this request to be
processed in real-time.
2.0.6 <caluid> - The specified <caluid> is not here but
an attempt will be made to deliver the
request or reply to <caluid> anyway.
Mansour/Courtemanche/O'Leary 16 Expires August 1999
There is not a trust relationship
between the IRIP server and the IRIP
server for the target calendar.
3.8 <caluid> - the authenticated iRIP session does not
have authority to perform [iTIP]
activities on <caluid>.
5.3 <caluid> - IRIP services for the specified calid
are not supported.
9.1 - Unexpected command
10.1 <caluid> <newcaluid>
- <caluid> is not supported by this iRIP
service but can be found <newcaluid>.
Note that <newcaluid> need not be of the
IRIP scheme.
The RECIPIENT command is used to identify a recipient of the iCalendar
Object. Use multiple RECIPIENT commands to specify multiple
recipients.
A reply code will be returned for each calendar address supplied. A
response code for each calendar address will also be returned after
the SENDATA 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
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.7.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
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.
Mansour/Courtemanche/O'Leary 17 Expires August 1999
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 collects 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.8 SENDATA
Arguments: [latencyTime]
Data: MIME encapsulated iCalendar object
Result: 2.0.1 - Begin sending the MIME encapsulated iCalendar
Object
9.1 - Unexpected command
After sending the iCalendar object a result is returned for each
recipient. These results can be the following:
2.0 <caluid> - Success. [ITIP] message delivered.
2.0.2 <caluid> - A timeout has occurred.
2.0.3 <caluid> - In response to the client issuing an
ABORT
2.0.7 <caluid> - The message has been queued for
delivery.
2.0.11 <caluid> - Success. [ITIP] message delivered and a
response follows.
8.0 A failure has occurred in the receiver that
prevents the operation from succeeding.
8.1 Sent when a session cannot be established because
the iRIP Receiver is too busy.
8.2 Used to signal that an ICAL object has exceeded the
server's size limit.
Mansour/Courtemanche/O'Leary 18 Expires August 1999
9.0 An unrecongnized command (METHOD) was received.
9.1 A command was issued in a manner inconsistent with
the state diagram. For example, issuing the SENDATA
command without having specified a RECIPIENT will
cause this error.
10.2 The server is shutting down.
10.4 The operation has not be performed because it would
cause the resources (memory, disk, CPU, etc) to
exceed the allocated quota
The SENDATA 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: SENDATA [latencyTime]
R: 2.0.1 R: 2.0.1
S: <MIME encapsulated ITIP Message> S: <MIME encapsulated sender ITIP Message>
S: . S: .
R: <MIME encapsulated ITIP Message> R: <reply code> <caluid>
# if the reply code above is 2.0.11 the following will also be sent:
R: <MIME encapsulated reply ITIP Message.>
R: . R: .
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 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 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. When the entire indicates that the [ITIP] message data can be sent. The data must be
message has been sent, the sender terminates sending data with the broken into lines that are 1024 characters (including the ending
special sequence <CRLF>.<CRLF>. The receiver reply may optionally <CRLF> or less. When the entire message has been sent, the sender
contain an ITIP message followed by the special sequence <CRLF>.<CRLF> terminates sending data with the special sequence <CRLF>.<CRLF>. The
followed by a reply code. Only the [ITIP] message is optional in the receiver reply MAY contain an [ITIP] message. The reply MUST contain
reply, the <CRLF>.<CRLF> sequence must be present. the special sequence <CRLF>.<CRLF> followed by a reply code for each
RECIPIENT.
S: ICALDATA 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: SENDATA
R: 2.0.1 R: 2.0.1
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII # lots of data
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
<etc.>
S: END:VCALENDAR
S: . S: .
R: . R: .
R: 2.0 R: 2.0 irip://cal.example.com/johndoe
3.1.7 RECIPIENT Mansour/Courtemanche/O'Leary 19 Expires August 1999
The RECIPIENT command is used to identify a recipient of the iCalendar R: 2.0.7 irip://cal.othersystem.com/xyz
Object. Use multiple RECIPIENT commands to specify multiple
recipients. The command format is
RECIPIENT <calendar address> If the reply code is 2.0.11, an [ITIP] message reply will follow. This
message will be terminated by the <CRLF>.<CRLF> sequence. iRIP servers
are not required to send [ITIP] messages in the reply to [ITIP]
requests delivered via the SENDATA 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.
A response code of 2.0 indicates that the calendar address is available 3.1.9 SWITCH
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 Arguments: none
The SWITCH command is used to allow the Sender and Receiver to change Data: none
roles. Its format is:
SWITCH Result: 2.0 Sender and receiver have switched roles.
The connection is switched to the
Connected State.
3.14 Unsupported command. That is, the
receiver refuses to switch roles.
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.
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:
* send an OK reply and take on the role of Sender - send an OK reply and take on the role of Sender
* send a error reply indicating refusal and retain the role of Receiver - 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 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. The IRIP
then in its initial state and sends a service ready greeting message. connection returns to the Connected state. Program-A is then in its
initial state and sends a service ready response code of 2.0.
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 (connected) as if the Program-B is then in the initial state (connected) as if it had just
transmission channel just opened, and expects to receive a service connected to Program-A, and expects to receive a response code of 2.0.
ready greeting.
3.2 Fanout and Queued Transactions 3.2 Fanout and Queued Transactions
An IRIP server must be able to fanout requests targeted at other IRIP Mansour/Courtemanche/O'Leary 20 Expires August 1999
servers. An IRIP server may queue information targeted at other IRIP
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 servers. There are several reasons for queing requests. One reason is
that firewall issues may prevent one server from contacting another. 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 iRIP servers can establish trust relationships between each other. A
trusted relationship means: trusted relationship means:
- one server must authenticate with the other - one server must authenticate with the other
- authenticated calendars on one server are trusted and treated as - authenticated calendars on one server are trusted and treated as
authenticated on the other. authenticated on the other.
The trusted relationship need not be bi-directional. That is, the fact 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 that iRIP server A trusts iRIP server B does not necessarily mean that
B trusts A. B trusts A.
A trusted relationship between two IRIP servers means that one server A trusted relationship between two iRIP servers means that one server
can queue transactions for the other server and deliver them some time 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 later. If iRIP server B trusts A, then A can queue requests for B. If
does not trust B then B cannot accumulate requests for A. 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. 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 In fact, a requester may wish to cancel the request if the reply
be delivered in real-time. In IRIP it is possible to detect whether or cannot be delivered in real-time. In iRIP the reply code to the
not a reply will be made in real-time and cancel the request if RECIPIENT command indicates whether or not a reply will be made in
necessary. real-time (barring connection and hardware failures). This allows the
sender to abort the request if necessary.
3.3 Reply Codes 3.3 Bi-Directional Queue Operation
[IRIP] error codes follow the format defined for Status Replies in It is possible that firewall configurations may not allow a connection
[ITIP]. All Status Replies as defined in [ITIP] are valid error codes 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 incoming external connections on the
iRIP server port. However, it allows outbound external connections on
the iRIP server port to happen. Similarly, the firewall in front of
D.bar.com also prevents inbound connections on the iRIP server port,
but allows outbound connections. 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?]
when returned by an [IRIP] command. iRIP +-----------+ +-----------+ iRIP
sender1 --------| B.foo.com |--#--+--#--| D.bar.com |------- sender2
+-----------+ | +-----------+
|
+----------------+
In addition to those defined in [ITIP], [IRIP] defines the following Mansour/Courtemanche/O'Leary 21 Expires August 1999
| 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: error codes:
REPLY REPLY
CODE DESCRIPTOR MEANING CODE DESCRIPTION MEANING
------ ---------------------- -------------------------------------- ------ ---------------------- --------------------------------------
2.0.1 START-ICALDATA Start ICAL input; end with 2.0 STATOK Operation was successfully performed.
2.0.1 START-SENDATA Start ICAL input; end with
<CRLF>.<CRLF>
2.0.11 OK-DATAFOLLOWS The request was processed
successfully. Reply data follows on
the next line and terminates with
<CRLF>.<CRLF> <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 still working on the reply. Use
CONTINUE to continue waiting for the CONTINUE to continue waiting for the
reply or ABORT to terminate the reply or ABORT to terminate the
command. command.
2.0.3 ABORTED In response to the client issuing an 2.0.3 ABORTED In response to the client issuing an
ABORT command, this reply code ABORT command, this reply code
indicates that any command currently indicates that any command currently
underway was successsfully aborted. underway was successsfully aborted.
2.0.4 TRUSTED-WILL-ATTEMPT The specified Calendar is not here 2.0.4 WILL-ATTEMPT The specified Calendar is not here
but a trust relationship exists but an attempt will be made to deliver
between this server and the server the request or reply to the Calendar
on which the Calendar exists. An anyway. There is a trust relationship
attempt will be made to deliver the between this iRIP server and the
request or reply to the Calendar iRIP server for the target calendar.
anyway.
2.0.5 TRUSTED-WILL-QUEUE The specified Calendar cannot be 2.0.5 TRUSTED-WILL-QUEUE The specified Calendar cannot be
contacted directly. The request or contacted directly and a trust
reply will be queued and delivered to relationship exists between this
the target calendar when its IRIP server and the server on which the
server contacts this server and issues Calendar exists. The request or reply
the SWITCH command. will be queued and delivered to the
target calendar when its iRIP server
contacts this server and issues the
SWITCH command.
Mansour/Courtemanche/O'Leary 22 Expires August 1999
2.0.6 WILL-ATTEMPT The specified Calendar is not here 2.0.6 WILL-ATTEMPT The specified Calendar is not here
but an attempt will be made to deliver but an attempt will be made to deliver
the request or reply to the Calendar the request or reply to the Calendar
anyway. anyway. There is not a trust
relationship between the iRIP server
and the iRIP server for the target
calendar.
2.0.7 QUEUED The request or reply has been queued 2.0.7 QUEUED The message has been queued for
for delivery. delivery.
2.0.8 QUEUE-EMPTY There are no more queued messages.
2.2 NO COMMAND IN PROGRESS An ABORT or CONTINUE was received when
no command was in progress
6.1 AUTHENTICATE FAILURE Unsupported authentication mechanism,
credentials rejected
6.2 AUTHENTICATION ABORTED Sender aborted authentication,
authentication exchange cancelled
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 session cannot be 8.1 SERVER TOO BUSY Sent when a session cannot be
established because the [IRIP] established because the iRIP
Receiver is too busy. Receiver is too busy.
8.2 ICAL OBJECT TOO BIG Used to signal that an ICAL object has 8.2 ICAL OBJECT TOO BIG Used to signal that an ICAL object has
exceeded the server's size limit. exceeded the server's size limit.
8.3 DATE TOO LARGE A DATETIME value was too large to be 8.3 DATE TOO LARGE A DATETIME value was too far in the
represented on this Calendar. future to be represented on this
Calendar.
8.4 DATE TOO SMALL A DATETIME value was too far in the 8.4 DATE TOO SMALL A DATETIME value was too far in the
past to be represented on this past to be represented on this
Calendar. Calendar.
9.0 INVALID IRIP COMMAND An unrecongnized command was received. 9.0 INVALID iRIP COMMAND An unrecongnized command was received.
9.1 UNEXPECTED COMMAND A command was issued in a manner
inconsistent with the state diagram.
For example, issuing the SENDATA
command without having specified any
RECIPIENTs will cause this error.
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
Mansour/Courtemanche/O'Leary 23 Expires August 1999
address. The referral address MUST address. The referral address MUST
follow the reply code. follow the reply code.
10.2 SERVER SHUT DOWN The server is shutting down. 10.2 SERVER SHUT DOWN The server is shutting down.
10.3 SERVER STOPPING FLOOD 10.3 SERVER STOPPING FLOOD 2
10.4 EXCEEDED QUOTAS 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 10.5 QUEUED TOO LONG The ITIP message has been queued too
too long. Delivery has been aborted. long. Delivery has been aborted.
4 Implementation Considerations 4 Implementation Considerations
It is strongly recommended that when an IRIP implementation encounters It is strongly recommended that when an iRIP implementation encounters
an error requiring the communication channel between the Sender and an error requiring the communication channel between the Sender and
Receiver to be dropped that the DISCONNECT command be issued rather Receiver to be dropped that the DISCONNECT command be issued rather
than simply breaking the communication channel. than simply breaking the communication channel.
[Editors note: What is the expectation for calstore recipients that
don't exist on this server?]
5 Security Considerations 5 Security Considerations
The security of [IRIP] with [SASL] support is highly dependent on the The security of iRIP with [SASL] support is highly dependent on the
mechanism used to authenticate the client and whether or not the mechanism used to authenticate the client and whether or not the
security layer is further negotiated. Without a robust security layer, security layer is further negotiated. Without a robust security layer,
[IRIP] transactions are subject to eavesdropping and the integrity of iRIP transactions are subject to eavesdropping and the integrity of
[IRIP] transactions may be compromised. Since [IRIP] is designed iRIP transactions may be compromised. Since iRIP is designed
specifically for real time Internet transactions, it is recommended specifically for real time transactions, it is recommended that
that implementations use the highest degree of authentication and implementations use the highest degree of authentication and
transmission security possible. transmission security possible.
Authentication is fundamental to [IRIP]. It is the basis for granting 5.1 Security Threats and Recommendations
and denying access. Without a robust security layer [IRIP] will be In addition to the security risks detailed in [ITIP], the following
subject to many possible attacks and the full contents of the server sections discuss security risks in using iRIP as the transport
itself may be at risk. binding.
5.1 SASL ANONYMOUS Mechanism 5.1.1 Authentication Hacking
Implementing support for the Anonymous [SASL] significantly increases Once authenticated, senders can re-authenticate from the Authenticated
the vulnerability of the calendar server and its data. Refer to state. It is possible that, once authenticated, a sender could take
[ANON-SASL] for further information on many threats specific to advantage of this capability and repeatedly attempt to guess at
Anonymous [SASL] access. calendar user credentials. It is recommended that implementations
disconnect after a failed authentication attempt from the
Authenticated state.
5.2 SASL Profile Definition for the protocol Mansour/Courtemanche/O'Leary 24 Expires August 1999
The implementation of [SASL] in [IRIP] requires the server and client 5.1.2 Spoofing
to comply with the following profile extension: 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.
- AUTHENTICATE command. The choice of accepted authentication mechanisms can reduce the
- Full description of the challenge/response definition. security risk. The ANONYMOUS mechanism allows a greater level of
- Starting octet. interoperability, in that any Sender can connect anonymously, but
- Authorization identity supplied by the sender must the one used to greatly increases the security risk for the same reason.
grant or denied the requested operation.
5.3 Security Threats 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.
5.3.1 Eavesdropping [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.
If [SASL] is used to negotiate a security layer with the server, then Finally, some implementations may decide to queue incoming iRIP
traffic is no longer in the clear and eavesdropping will not be commands for approval by the owner of the calendar, although this is
restricted. certainly the least reliable of these security mechanisms.
5.3.2 Connection Flooding 5.1.3 Eavesdropping
Connections that have not been authenticated within a configurable The use of SASL in iRIP allows the negotiation of an encrypted
number of seconds should be disconnected. security layer, which greatly reduces the chances that a connection
will be subject to eavesdropping.
5.3.3 Denial of Service Attacks 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.
[Editors note: need explanation and recommendation: ???] 5.1.4 Connection Flooding
Servers should be configurable to timeout unused connections.
5.2 Security Interoperability Issues
* minimum SASL mechanism
[ed note: tbd Paul Hill to supply ]
* add a failure case under 6.3
6 Examples 6 Examples
6.1 Unauthenticated Freebusy Request 6.1 Unauthenticated Freebusy Request
Mansour/Courtemanche/O'Leary 25 Expires August 1999
This examples shows an anonymous request for the freebusy time of This examples shows an anonymous request for the freebusy time of
irip://cal.example.com/sman. Note that once xyz is authenticated on irip://cal.example.com/sman. Note that once xyz is authenticated on
the irip server either the fully qualified IRIP CALID or the relative the IRIP server either the fully qualified IRIP CALID or the relative
CALID can be used to reference a Calendar. That is, CALID can be used to reference a Calendar. That is,
"irip://cal.example.com/xyz" and "xyz" refer to the same calendar and "irip://cal.example.com/xyz" and "xyz" refer to the same calendar and
can be used interchangeably. can be used interchangeably.
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a TCP connection to cal.example.com port 5228> S: <establish a TCP connection to cal.example.com port 5228>
R: 2.0 R: 2.0
S: AUTHENTICATE ANONYMOUS xyz S: AUTHENTICATE ANONYMOUS
R: 2.0 R: 2.0
S: RECIPIENT:sman S: RECIPIENT:irip://b.foo.bar/sman
R: 2.0 R: 2.0
S: ICALDATA S: SENDATA
R: 2.0.1 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:xyz S: ORGANIZER: irip://b.foo.bar/xyz
S: ATTENDEE:sman S: ATTENDEE: irip://b.foo.bar/sman
S: DTSTAMP:19971113T190000Z S: DTSTAMP:19971113T190000Z
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> # server looks up the freebusy time and builds a reply>
R: 2.0.11 irip://cal.example.com/sman
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
S: ORGANIZER:irip://cal.example.com/xyz R: ORGANIZER:irip://cal.example.com/xyz
R: ATTENDEE:irip://cal.example.com/sman 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
Mansour/Courtemanche/O'Leary 26 Expires August 1999
R: FREEBUSY:19971115T230000Z/PT1H,19971115T210000Z/PT30M
R: END:VFREEBUSY R: END:VFREEBUSY
R: END:VCALENDAR R: END:VCALENDAR
R: . R: .
R: sman 2.0
R: .
S: DISCONNECT S: DISCONNECT
R: 2.0 R: 2.0
R: <disconnect> R: <disconnect>
S: <disconnect> S: <disconnect>
6.2 Using Switch 6.2 Busy Time Request
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 93407205
S: <more authentication information>
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 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 In this example, the sender sends a Freebusy request to the iRIP
calendars on B, C, D, and E. server at B.foo.com for several calendars. Some of the calendars are
on other calendar stores. The sender needs the information immediately
and will abort any attempt to queue requests.
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a TCP connection to b.foo.com port 5228> S: <establish a TCP connection to B.foo.com port 5228>
R: 2.0 R: 2.0
S: AUTHENTICATE KERBEROS_V4 93407205 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 # more authentication information
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 R: 2.0
S: RECIPIENT:irip://B.foo.com/bill S: RECIPIENT:irip://B.foo.com/bill
R: 2.0 R: 2.0
S: RECIPIENT:irip://C.foobar.com/cathy S: RECIPIENT:irip://C.foobar.com/cathy
R: 2.0.4 R: 2.0.4
S: RECIPIENT:irip://D.bar.com/david S: RECIPIENT:irip://D.bar.com/david
R: 2.0.5 R: 2.0.5
S: RECIPIENT:irip://E.barfoo.com/eddie S: RECIPIENT:irip://E.barfoo.com/eddie
R: 2.0.6 R: 2.0.6
<the sender cannot accept a queued request and response. The # the sender does not want this ITIP message to be queued request.
current operation will be canceled. The operation will be tried # So, the current operation will be canceled. The operation will be
again with all attendees that have requests queued dropped from the # tried again with attendees that can be serviced in real-time.
RECIPIENT list...>
S: ABORT S: ABORT
R: 2.0.3 R: 2.0.3
S: RECIPIENT:irip://B.foo.com/bill S: RECIPIENT:irip://B.foo.com/bill
R: 2.0 R: 2.0
S: RECIPIENT:irip://C.foobar.com/cathy S: RECIPIENT:irip://C.foobar.com/cathy
R: 2.0.4 R: 2.0.4
S: RECIPIENT:irip://E.barfoo.com/eddie S: RECIPIENT:irip://E.barfoo.com/eddie
R: 2.0.6 R: 2.0.6
S: ICALDATA S: SENDATA
R: 2.0.1 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
Mansour/Courtemanche/O'Leary 27 Expires August 1999
S: METHOD:REQUEST S: METHOD:REQUEST
S: VERSION:2.0 S: VERSION:2.0
S: BEGIN:VFREEBUSY S: BEGIN:VFREEBUSY
S: ORGANIZER:irip://B.foo.com/bill S: ORGANIZER:irip://B.foo.com/bill
S: ATTENDEE:irip://B.foo.com/bill S: ATTENDEE:irip://B.foo.com/bill
S: ATTENDEE:irip://C.foobar.com/cathy S: ATTENDEE:irip://C.foobar.com/cathy
S: ATTENDEE:irip://D.bar.com/david S: ATTENDEE:irip://D.bar.com/david
S: ATTENDEE:irip://E.barfoo.com/eddie S: ATTENDEE:irip://E.barfoo.com/eddie
S: DTSTAMP:19971113T190000Z S: DTSTAMP:19971113T190000Z
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 for B.foo.com/bill, # server looks up the freebusy time for irip://B.foo.com/bill,
requests and receives the freebusy time for # requests and receives the freebusy time for
irip://C.foobar.com/cathy and irip://E.barfoo.com/eddie. Then it # irip://C.foobar.com/cathy and irip://E.barfoo.com/eddie. Then it
builds a reply> # builds a reply
R: Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" R: 2.0.11 irip://B.foo.com/bill
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-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
S: ORGANIZER:irip://B.foo.com/bill S: ORGANIZER:irip://B.foo.com/bill
R: ATTENDEE:irip://B.foo.com/bill R: ATTENDEE:irip://B.foo.com/bill
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:19971115T200000Z/PT1H,19971116T170000Z/PT30M R: FREEBUSY:19971115T200000Z/PT1H,19971116T030000Z/PT30M
R: END:VFREEBUSY R: END:VFREEBUSY
R: END:VCALENDAR R: END:VCALENDAR
R: R: .
R:----FEE3790DC7E35189CA67CE2C R: 2.0.11 irip://C.foobar.com/cathy
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
S: ORGANIZER:irip://B.foo.com/bill S: ORGANIZER:irip://B.foo.com/bill
R: ATTENDEE:irip://C.foobar.com/cathy R: ATTENDEE:irip://C.foobar.com/cathy
R: DTSTAMP:19971113T190005Z R: DTSTAMP:19971113T190005Z
Mansour/Courtemanche/O'Leary 28 Expires August 1999
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:19971115T230000Z/PT1H,19971116T210000Z/PT30M R: FREEBUSY:19971115T230000Z/PT1H,19971116T020000Z/PT30M
R: END:VFREEBUSY R: END:VFREEBUSY
R: END:VCALENDAR R: END:VCALENDAR
R: R: .
R:----FEE3790DC7E35189CA67CE2C R: 2.0.11 irip://E.barfoo.com/eddie
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
S: ORGANIZER:irip://B.foo.com/bill S: ORGANIZER:irip://B.foo.com/bill
R: ATTENDEE:irip://E.barfoo.com/eddie R: ATTENDEE:irip://E.barfoo.com/eddie
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:19971115T230000Z/PT1H,19971116T210000Z/PT30M R: FREEBUSY:19971115T230000Z/PT1H,19971116T020000Z/PT30M
R: END:VFREEBUSY R: END:VFREEBUSY
R: END:VCALENDAR R: END:VCALENDAR
R:
R:----FEE3790DC7E35189CA67CE2C
R: . 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 S: DISCONNECT
R: 2.0 R: 2.0
R: <disconnect> R: <disconnect>
S: <disconnect> S: <disconnect>
Since each reply is delivered immediately, the reply is sent as a 6.3 Using Switch
Multipart/Mixed. Transport reply codes for each recipient are returned
after the Multipart/Mixed data.
6.4 Resource Scheduling This session demonstrates how a poll can be accomplished using the
SWITCH command. In this case, the receiver (A.example.com) becomes
the sender after issuing the switch command.
# receiver is currently A.example.com, the sender is B.xyz.com
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <connect to port 5228> S: <establish a connection to TCP port 5228>
R: 2.0 R: 2.0
S: AUTHENTICATE KERBEROS_V4 7SF8S3&# S: AUTHENTICATE KERBEROS_V4
S: <more authentication information> # more authentication...
R: 2.0 R: 2.0
S: RECIPIENT Large_Conference_Room S: SWITCH
R: 2.0 R: 2.0
S: RECIPIENT Overhead_Projector_1
# The connection state has returned to the Connected state.
A.example.com
# must now Authenticate with B.xyz.com
Mansour/Courtemanche/O'Leary 29 Expires August 1999
S: 2.0
R: AUTHENTICATE KERBEROS_V4
# more authentication...
R: 2.0 R: 2.0
S: ICALDATA: 10
# Now that the switch has occurred, A.example.com is the sender and
# B.xyz.com is the receiver. At this point, A.example.com sends all
# queued commands for recipients on B.xyz.com
S: RECIPIENT:irip://B.xyz.com/sman
R: 2.0
S: SENDATA
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:-//Foo Corporation//Inlet MIMEDIR//EN
S: VERSION:2.0
S: METHOD:REQUEST S: METHOD:REQUEST
S: BEGIN:VEVENT S: VERSION:2.0
S: ORGANIZER:irip://cal.example.com/xyz S: BEGIN:VFREEBUSY
S: ATTENDEE:irip://cal.example.com/Large_Conference_Room S: ORGANIZER:irip://A.example.com/billybob
S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1 S: ATTENDEE:irip://B.xyz.com/sman
S: DTSTART:19980706T190000Z S: DTSTAMP:19981113T190000Z
S: DTEND:19980706T203000Z S: DTSTART:19981115T160000Z
S: LOCATION:Large Conference Room S: DTEND:19981116T160000Z
S: DESCRIPTION:Big customer meeting in Large Conference room. S: UID:123456abcdef.1234.2314
S: SUMMARY:Customer meeting S: END:VFREEBUSY
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: <looks up availability in database>
# server looks up the freebusy time and builds a reply
R: 2.0.11 irip://B.xyz.com/sman
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
R: ORGANIZER:irip://cal.example.com/xyz
R: ATTENDEE:irip://cal.example.com/sman
R: DTSTAMP:19981113T190005Z
R: DTSTART:19981115T160000Z
R: DTEND:19981116T160000Z
R: UID:123456abcdef.1234.2314
R: FREEBUSY:19981115T230000Z/PT1H,19981115T210000Z/PT30M
R: END:VFREEBUSY
R: END:VCALENDAR
R: . R: .
R: 2.0 Large_Conference_Room
R: 2.0 Overhead_Projector_1 Mansour/Courtemanche/O'Leary 30 Expires August 1999
S: RECIPIENT Large_Conference_Room
# A.example.com has no more queued ITIP messages for B.xyz.com.
# So, it disconnects...
S: DISCONNECT
R: 2.0 R: 2.0
S: RECIPIENT Overhead_Projector_1 R: <disconnect>
S: <disconnect>
6.4 Fanout Requests
6.4.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
S = sender
R = B.foo.com
-----------------------------------
R: <listen on TCP port 5228>
S: < connect to B.foo.com port 5228>
R: 2.0 R: 2.0
S: ICALDATA: 10 S: AUTHENTICATE KERBEROS_V4 93407205
S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII # more authentication information
S: Content-Transfer-Encoding: 7bit R: 2.0
S: S: RECIPIENT:irip://B.foo.com/bill
S: BEGIN:VCALENDAR R: 2.0
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN S: RECIPIENT:irip://D.bar.com/david
S: VERSION:2.0
S: METHOD:REQUEST Connection B.foo.com to D.bar.com
S: BEGIN:VEVENT
S: ORGANIZER:irip://cal.example.com/xyz S = B.foo.com
S: ATTENDEE:irip://cal.example.com/Large_Conference_Room R = D.bar.com
S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1 ----------------------------------
S: DTSTART:19980708T220000Z R: <listen on TCP port 5228>
S: DTEND:19980708T230000Z S: <connect to D.bar.com>
S: LOCATION:Large Conference Room R: 2.0
S: DESCRIPTION:Another big customer meeting in Large Conference room. S: <authenticate as iRIP
S: SUMMARY:Customer meeting Server B.foo.com>
S: PRIORITY:1 R: 2.0
S: END:VEVENT S: RECIPIENT:irip://D.bar.com/david
S: END:VCALENDAR R: 2.0
R: 2.0
Mansour/Courtemanche/O'Leary 31 Expires August 1999
S: SENDATA
R: 2.0.1
S: <sends icaldata>
S: . S: SENDATA
R: 2.0.1
S: <sends icaldata>
S: . S: .
R: <looks up availability in database>
R: . R: .
< Large_Conference_Room not available, thus the response code is...> R: 2.0 irip://D.bar.com/david
R: 4.0 R: .
S: RECIPIENT Large_Conference_Room R: 2.0 irip://B.foo.com/bill
R: 2.0 irip://D.bar.com/david
S: DISCONNECT
R: 2.0 R: 2.0
S: RECIPIENT Overhead_Projector_1
6.4.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
S = sender
R = B.foo.com
====================================
S: < connect to B.foo.com port 5228>
R: 2.0 R: 2.0
S: ICALDATA: 10 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
Connection B.foo.com to D.bar.com
S = B.foo.com
R = D.bar.com
===================================
R: <listen on TCP port 5228>
Mansour/Courtemanche/O'Leary 32 Expires August 1999
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>
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
S: SENDATA
R: 2.0.1
S: <sends icaldata>
S: . S: SENDATA
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.5 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. The iRIP server on B.foo.com has a trusted relationship with
iRIP servers on both C.foobar.com and D.bar.com. A firewall is in
place that prohibits iRIP server B.foo.com from initiating a
connection to the iRIP server on D.bar.com. However, iRIP server
D.bar.com can connect to iRIP server B.foo.com.
Mansour/Courtemanche/O'Leary 33 Expires August 1999
+--------------+
+------| C.foobar.com |
| +--------------+
|
+-----------+ | +-----------+
S ---------| B.foo.com |------#--| D.bar.com |
+-----------+ | +-----------+
|
| +--------------+
+------| E.barfoo.com |
+--------------+
6.5.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. Note that C's address moved from foo.com
to foobar.com and is reported to the sender during the RECIPIENT
negotiation.
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: 10.1 irip://C.foobar.com/cathy
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: SENDATA 16
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:-//Foo Corporation//Insight MIMEDIR//EN S: PRODID:-//ACME/DesktopCalendar//EN
S: VERSION:2.0
S: METHOD:REQUEST S: METHOD:REQUEST
S: VERSION:2.0
S: BEGIN:VEVENT S: BEGIN:VEVENT
S: ORGANIZER:irip://cal.example.com/xyz S: ORGANIZER:irip://B.foo.com/bill
S: ATTENDEE:irip://cal.example.com/Large_Conference_Room S: ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:irip://B.foo.com/bill
S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1 S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://C.foobar.com/cathy
S: DTSTART:19980708T160000Z S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://D.bar.com/david
S: DTEND:19980708T170000Z S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://E.barfoo.com/eddie
S: LOCATION:Large Conference Room S: DTSTAMP:19981011T190000Z
S: DESCRIPTION:Another big customer meeting in Large Conference room. S: DTSTART:19981101T200000Z
S: SUMMARY:Customer meeting
S: PRIORITY:1 Mansour/Courtemanche/O'Leary 34 Expires August 1999
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:VEVENT
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: <looks up availability in database>
<10 seconds pass>
R: . R: .
<Database too busy, thus the response code is...> R: 2.0 irip://B.foo.com/bill
R: 2.0.2 R: 2.0 irip://C.foobar.com/cathy
S: ABORT R: 2.0.7 irip://D.bar.com/david
R: 2.0 R: 2.0 irip://E.barfoo.com/eddie
S: DISCONNECT S: DISCONNECT
R: 2.0 R: 2.0
R: <drops TCP connection> R: <disconnect>
S: <disconnect>
7 Acknowledgments 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.
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:
Bruce Kahn, Doug Royer, Mugino Saeki Frank Dawson, Bruce Kahn, Doug Royer, Mugino Saeki
8 Bibliography 8 Bibliography
[ICAL] F. Dawson, D. Stenerson, "Internet Calendaring and Scheduling
Core Object Specification - iCalendar", RFC-2445, November 1998,
http://www.imc.org/rfc2445.
[ ICAL] "Internet Calendaring and Scheduling Core Object Specification [ITIP] S. Silverberg, S. Mansour, F. Dawson, R. Hopson, "iCalendar
- iCalendar", Internet-Draft, July 1997, Transport-Independent Interoperability Protocol (iTIP) : Scheduling
ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-10.txt. Events, Busy Time, To-dos and Journal Entries", RFC-2446, November
1998, http://www.imc.org/rfc2446.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft, July
1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt.
[ITIP] "iCalendar Transport-Independent Interoperability Protocol [IMIP] F. Dawson, S. Mansour, S. Silverberg, "iCalendar Message-based
(iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ", Interoperability Protocol (iMIP), ", RFC-2447, November 1998,
Internet-Draft, October 1997, http://www.imc.org/rfc2447.
http://www.imc.org/draft-ietf-calsch-itip-06.txt.
[IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), [ID-UTF8] 3"UTF-8, a transformation format of ISO 10646. F. Yergeau.",
Internet-Draft, October 1997,
http://www.imc.org/draft-ietf-calsch-imip-05.txt.
[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", Mansour/Courtemanche/O'Leary 35 Expires August 1999
Internet-Draft, July,1996,
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,"
2112, March 1997. RFC 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
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
January 1997. 2048, January 1997.
[RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)", [RFC-2222] J. Meyers, Simple Authentication and Security Layer
RFC 2222, October 1997. (SASL)", RFC 2222, October 1997.
[RFC2396] Berners-Lee, Fielding, Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC-2445] Dawson, Stenerson, "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 2445, November 1998
[RFC-2446] Silverberg, Mansour, Dawson, Hopson, "iCalendar Transport-
Independent Interoperability Protocol (iTIP)", RFC 2446, November 1998
[RFC-2447] Dawson, Mansour, Silverberg, "iCalendar Message-Based
Interoperability Protocol (iMIP)", RFC 2445, November 1998
9 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.
Port Number registration Port Number registration
10 Author's Address 10 Author's Address
Mansour/Courtemanche/O'Leary 36 Expires August 1999
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
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:andre@cst.ca
END: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
View;CA;94043;USA View;CA;94043;USA
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: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:andre@cst.ca
END: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-659-0006 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: co-chair of that working group is:
BEGIN:VCARD
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
The co-chairman of that working group is:
BEGIN:VCARD BEGIN:VCARD
VERSION:2.1 FN:Pat Egen
FN:Robert Moskowitz ORG:Egen Consulting
EMAIL;INTERNET: rgm-ietf@htt-consult.com ADR;WORK;POSTAL;PARCEL:;;803 Creek Overlook;Chattanooga;TN;37415
TEL;WORK;MSG:+1-423.875.2652
TEL;WORK;FAX:+1-423.875.2017
EMAIL;INTERNET:pregen@engenconsulting.com
END:VCARD END:VCARD
11 Full Copyright Statement 11 Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society, January 2, 1999. 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
assist in its implmentation MAY be prepared, copied, published and Mansour/Courtemanche/O'Leary 37 Expires August 1999
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, 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
copyright notice or references to the Internet Society or other the 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
Internet standards in which case the procedures for copyrights defined Internet standards in which case the procedures for copyrights defined
in the Internet Standards process MUST be followed, or as required to in the Internet Standards process MUST be followed, or as required to
translate it into languages other than English. translate it into languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 223 change blocks. 
667 lines changed or deleted 1352 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/