draft-ietf-calsch-irip-00.txt   draft-ietf-calsch-irip-01.txt 
Network Working Group Andre Courtemanche/CS&T Network Working Group Andre Courtemanche/CS&T
Internet Draft Steve Mansour/Netscape Internet Draft Steve Mansour/Netscape
<draft-ietf-calsch-irip-00.txt> Pete O'Leary/Amplitude <draft-ietf-calsch-irip-01.txt> Pete O'Leary/Amplitude
Expires six months after November 21, 1997 Expires six months after August 3, 1998
iCalendar Real-time Interoperability Protocol (iRIP) ICalendar Real-time Interoperability Protocol (IRIP)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
andits working groups. Note that other groups may also distribute andits working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or made obsolete by other Internet-Drafts may be updated, replaced, or made obsolete by other
documents at any time. It is not appropriate to use Internet-Drafts as documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress". "work in progress".
skipping to change at line 21 skipping to change at line 22
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
andits working groups. Note that other groups may also distribute andits working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or made obsolete by other Internet-Drafts may be updated, replaced, or made obsolete by other
documents at any time. It is not appropriate to use Internet-Drafts as documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or reference material or to cite them other than as a "working draft" or
"work in progress". "work in progress".
To learn the current status of any Internet-Draft, please check the 1id- To learn the current status of any Internet-Draft, please check the
abstracts.txt listing contained in the Internet-Drafts Shadow 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
This document specifies a binding from the iCalendar Transport-
independent Interoperability Protocol [ITIP] to a real-time transport. This document specifies a binding from the iCalendar
Calendaring entries defined by the iCalendar Object Model [ICAL] are Transport-independent Interoperability Protocol [ITIP] to a real-time
composed using constructs from [RFC-2045], [RFC-2046], [RFC-2047], [RFC- transport. Calendaring entries defined by the iCalendar Object Model
2048] and [RFC-2049]. [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 This document is based on the calendaring and scheduling model defined
by [ICMS]. by [ICMS].
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 access references within this document for further information on how to
these various documents. access these various documents.
Distribution of this document is unlimited. Comments and suggestions for Distribution of this document is unlimited. Comments and suggestions
improvement should be sent to the authors. for improvement should be sent to the authors.
Courtemanche/Mansour/O'Leary 1 Expires February 1998
1. Introduction 1. Introduction
This binding document provides the transport specific information This binding document provides the transport specific information
necessary convey iCalendar Transport-independent Interoperability necessary convey iCalendar Transport-independent Interoperability
Protocol [ITIP] over a real-time transport. Protocol [ITIP] over a real-time transport.
Courtemanche/Mansour/O'Leary 1 Expires May 1998
1.1 Related Memos 1.1 Related Memos
Implementors will need to be familar with several other memos that, Implementors will need to be familar with several other memos that,
along with this memo, form a framework for Internet calendaring and along with this memo, form a framework for Internet calendaring and
scheduling standards. scheduling standards.
This document - specifies an Internet email binding for [ITIP]. This document - specifies an Internet email binding for [ITIP].
[ICMS] - specifies a common terminology and abstract; [ICMS] - specifies a common terminology and abstract;
[ICAL] - specifies a core specification of objects, data types, [ICAL] - specifies a core specification of objects, data types,
properties and property parameters; properties and property parameters;
[ITIP] - specifies an interoperability protocol for scheduling between [ITIP] - specifies an interoperability protocol for scheduling
different implementations; between different implementations;
[IMIP] - specifies a messaging-based protocol binding for [ITIP]. [IMIP] - specifies a messaging-based protocol binding for [ITIP].
This memo does not attempt to repeat the specification of concepts or This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are made definitions from these other memos. Where possible, references are made
to the memo that provides for the specification of these concepts or to the memo that provides for the specification of these concepts or
definitions. definitions.
1.2 Formatting Conventions 1.2 Formatting Conventions
skipping to change at line 104 skipping to change at line 105
"V". For example, "VEVENT" refers to the event calendar component, "V". For example, "VEVENT" refers to the event calendar component,
"VTODO" refers to the to-do calendar component and "VJOURNAL" refers to "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to
the daily journal calendar component. the daily journal calendar component.
Scheduling methods defined by [ITIP] are referred to with capitalized, Scheduling methods defined by [ITIP] are referred to with capitalized,
quoted-strings of text. For example, "REQUEST" refers to the method for quoted-strings of text. For example, "REQUEST" refers to the method for
requesting a scheduling calendar component be created or modified, requesting a scheduling calendar component be created or modified,
"REPLY" refers to the method a recipient of a request uses to update "REPLY" refers to the method a recipient of a request uses to update
their status with the "Organizer" of the calendar component. their status with the "Organizer" of the calendar component.
Properties defined by [ICAL] are referred to with capitalized, quoted- Properties defined by [ICAL] are referred to with capitalized,
strings of text, followed by the word "property". For example, quoted-strings of text, followed by the word "property". For example,
"ATTENDEE" property refers to the iCalendar property used to convey the "ATTENDEE" property refers to the iCalendar property used to convey the
calendar address of a calendar user. calendar address of a calendar user.
Courtemanche/Mansour/O'Leary 2 Expires May 1998
Property parameters defined by [ICAL] are referred to with lower case, Property parameters defined by [ICAL] are referred to with lower case,
Courtemanche/Mansour/O'Leary 2 Expires February 1998
quoted-strings of text, followed by the word "parameter". For example, quoted-strings of text, followed by the word "parameter". For example,
"VALUE" parameter refers to the iCalendar property parameter used to "VALUE" parameter refers to the iCalendar property parameter used to
override the default data type for a property value. override the default data type for a property value.
2. Architecture 2. Architecture
The goal of iRIP is to enable real-time interoperability between iRIP enables real-time interoperability between scheduling systems
scheduling systems using the iCalendar [ICAL] format for information using the iCalendar [ICAL] format for information exchange. iRIP is
exchange. iRIP is designed primarily to allow Calendar Services (CS) as designed primarily to allow Calendar Services (CS) as defined in [ICSM]
defined in [ICSM] to forward real-time requests on behalf of Calendar to forward real-time requests on behalf of Calendar User Agents (CUA).
User Agents (CUA). The goal of iRIP is to allow two or more CS's to The goal of iRIP is to allow two or more CS's to establish connections
establish connections between them and operate as a single Calendar between them and operate as a single Calendar Domain.
Domain.
iRIP allows a CS to initiate a session and perform operations on behalf iRIP allows a CS to initiate a session and perform operations on behalf
of multiple CUA's without the need to reauthenticate the session for of multiple CUA's without the need to reauthenticate the session for
each CUA. each CUA.
The design of iRIP does not preclude its use from CUA directly to CS, The design of iRIP does not preclude its use from a CUA directly to
however. iRIP does not support client access functions such as calendar a CS. iRIP does not support client access functions such as calendar
browsing, retrieval and search. These requirements will be addressed by browsing, retrieval, and search.
the Calendar Access Protocol (CAP).
Terms used in the following discussion include: Terms used in the following discussion include:
. the User, the CU that initiates a request. User - the CU that initiates a request.
. the Sender, the agent used to contact a receiving device, send Sender - the agent used to contact a receiving device, send
commands, and receive replies, and commands, and receive replies
. the 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 CUA and CS as
described in [ICMS]. described in [ICMS]. iRIP allows two CS's to establish different
levels of trust so that scheduling operations can be performed as
iRIP allows two CS's to establish different levels of trust so that efficiently as possible. When an iRIP connection is first established,
scheduling operations can be performed as efficiently as possible. When both parties to the connection authenticate one another using the
an iRIP connection is first established, both parties to the connection AUTHENTICATE command. The Sender can then initiate commands which the
authenticate one another using the AUTHENTICATE command. The Sender can Receiver MUST interpret relative to the Sender's access control. The
then initiate commands which the Receiver MUST interpret relative to the AUTHENTICATE command supports proxy operations via [SASL].
Sender's access control. If proxy operations are required, then an
authentication that supports both the authorization user id and
authentication user id must be used.
2.1 State Diagram 2.1 State Diagram
An iRIP session begins when a TCP/IP connection is made on port 5228. An iRIP session begins when a TCP/IP connection is made on port 5228.
The protocol begins in the Connected state. The AUTHENTICATE command, The protocol begins in the Connected state. The AUTHENTICATE command,
when successful, begins the Authenticated state. From the Authenticated when successful, begins the Authenticated state. From the Authenticated
state, the sender can initiate a request using the RECIPIENT command. state, the sender can initiate a request using the RECIPIENT command.
The Sender can then issues as many RECIPIENT commands as the operation The Sender can then issues as many RECIPIENT commands as the operation
in progress requires until sending an ICALDATA command. After issuing in progress requires until sending an ICALDATA command. After
completing the ICALDATA command, the Sender must wait for a response
Courtemanche/Mansour/O'Leary 3 Expires May 1998 from the receiver. The Receiver can respond that the request has been
completed or that the request could not be completed in the time
the ICALDATA command, the Sender must wait for a response from the specified by the Sender. When the Receive has ended, the Sender returns
receiver. The Receiver can respond that the request has been completed to the Authenticated state where another request can be initiated.
or that the request could not be completed in the time specified by the Implementations should be prepared to handle a DISCONNECT at any point
Sender. When the Receive has ended, the Sender returns to the in this state diagram.
Authenticated state where another request can be initiated.
>From the Authenticated state, the Sender can issue a PROXY command to
indicate that the following command is being performed on behalf of
another party. After the PROXY command succeeds and the send and receive
are accomplished, the PROXY information is cleared and the Sender
returns to the Authenticated state.
+------------------+ Courtemanche/Mansour/O'Leary 3 Expires February 1998
| | +----------SWITCH------------+ +---------------+
V | | | | |
V | V |
+------------+ +---------------+ | +------------+ +---------------+ |
| Connected |--AUTHENTICATE-->| Authenticated |-----+ | | Connected |--AUTHENTICATE-->| Authenticated |-----+ |
+------------+ +---------------+ | | +------------+ +---->| (Proxy) | | |
| | | +---------------+ | |
+-----------------RECIPIENT-----------------------+ | +--RECIPIENT---+ | | | |
| | | | | +----------+ | |
V | | | | | |
+------+ +------------+ | | +----------+ V | |
| Send |<----RECIPIENT-----| Auth/Proxy |<---PROXY---+ | | Send |<---------------RECIPIENT----------------+ |
+------+ +------------+ | +----------+ |
| | | |
ICALDATA ABORT/Complete
| | | |
| +---------+ +--------+ | | +---------+ +--------+ |
+--| Receive |--(Response from Server)-->| Idle |---+ +->| Receive |--(Response from Server)-->| Idle |---+
+---------+ +--------+ +---------+ +--------+
A | A |
| | | |
+--------------CONTINUE---------------+ +--------------CONTINUE---------------+
2.2 Bounded Latency 2.2 Calendar Address
Calendar addresses are URIs. IRIP uses the following forms of URI.
[protocol:]//host.domain[:port]/CSID
mailto:CSID@host.domain
where:
CSID is an identifier that uniquely identifies the calendar store.
There is no implied structure in a CSID, it is an arbitrary string of
characters. It may refer to the calendar of a user or of a resource
such as a conference room.
protocol is optional. Its default value is "IRIP".
port is optional. Its default value is 5228.
Examples:
mailto:user1@example.com
irip://calendar.example.com/user1
irip://calendar.example.com/conferenceRoomA
irip://calendar.example.com/89798-098-zytytasd
2.3 Bounded Latency
iRIP is designed so that the Sender can either obtain an immediate iRIP is designed so that the Sender can either obtain an immediate
response from a request or discover within a known amount of time that response from a request or discover within a known amount of time that
the request cannot be completed. When the Sender initiates a command the request cannot be completed. When the Sender initiates a command
that the Receiver cannot complete within a given amount of time, the that the Receiver cannot complete within a given amount of time, the
Receiver can return an error code to the Sender indicating this Receiver can return an error code to the Sender indicating this
condition. The Sender then issues either a CONTINUE or ABORT command. condition. The Sender then issues either a CONTINUE or ABORT command.
The ABORT command immediately terminates the command in progress. The The ABORT command immediately terminates the command in progress. The
CONTINUE command instructs the Receiver to continue processing the CONTINUE command instructs the Receiver to continue processing the
Courtemanche/Mansour/O'Leary 4 Expires February 1998
command. The ABORT command causes the Receiver to discard the current command. The ABORT command causes the Receiver to discard the current
command and return to the Authenticated state. command and return to the Authenticated state.
3. Commands 3. Commands
In the examples below, lines preceded with "S:" refer to the Sender and In the examples below, lines preceded with "S:" refer to the Sender and
lines preceded with "R:" refer to the Receiver. lines preceded with "R:" refer to the Receiver.
Courtemanche/Mansour/O'Leary 4 Expires May 1998 Reply codes MAY be followed by arbitrary text. The length of the reply
code, any subsequent text, and the terminating <CRLF> MUST be l024
characters or less.
3.1 ABORT 3.1 ABORT
The ABORT command is issued by the Sender to stop an ICALDATA request The ABORT command is issued by the Sender to stop an ICALDATA request
from being processed further. When the latency time is specified on the from being processed further. When the latency time is specified on the
ICALDATA command, the Receiver must issue a reply to the Sender within ICALDATA command, the Receiver must issue a reply to the Sender within
the specified time. The reply may be a reply code indicating that the the specified time. The reply may be a reply code indicating that the
server has not yet processed the request. The Sender must then tell the server has not yet processed the request. The Sender must then tell
server whether to continue or abort. the server whether to continue or abort.
The ABORT command can also be issued at any time by the Sender after
the ICALDATA command has been completed but before the Sender receives
a reply.
Example: Example:
... ...
S: ICALDATA:10 S: ICALDATA:10
R: 3.5.4 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF>
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: .
<after 10 seconds...> <10 seconds elapse...>
R: . R: .
R: 3.5.0 Reply Pending R: 7.0 TIMEOUT
S: ABORT S: ABORT
R: 2.5 OK R: 2.0 OK
S: <sender can now begin another command or it can disconnect>
3.2 AUTHENTICATE 3.2 AUTHENTICATE
The authentication mechanism used in iRIP is based on [SASL]. This The authentication mechanism used in iRIP is based on [SASL]. This
allows the iRIP senders and receivers to dynamically negotiate allows the iRIP senders and receivers to dynamically negotiate
authentication and encryption mechanisms. SASL defines authentication authentication and encryption mechanisms. SASL defines authentication
methods such as ANONYMOUS and encapsulates concepts of PROXY used in methods such as ANONYMOUS and encapsulates concepts of PROXY used in
iRIP. iRIP.
The AUTHENTICATE command is used by the client to identify itself to the The AUTHENTICATE command is used by the client to identify itself to
server. Authenticate is required before any other command can be used the server. Authenticate is required before any other command can be
and must be the first one sent following the server's welcome message. used and must be the first one sent following the server's welcome
The format of the command is of the following: message. The format of the command is of the following:
AUTHENTICATE <mechanism> <initial data> AUTHENTICATE <mechanism> <initial data>
Courtemanche/Mansour/O'Leary 5 Expires February 1998
from which the standard SASL interchange will take place as defined in from which the standard SASL interchange will take place as defined in
the SASL profile. the SASL profile.
Example of an authentication session: Example of an authentication session with kerberose version 4:
R: Welcome IRIP Server R: 2.0 Welcome IRIP Server
S: AUTHENTICATE KERBEROS_V4 744RTU3r# S: AUTHENTICATE KERBEROS_V4 744RTU3r#
S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf
S: slkfjgsdlfjg;dslfjgdsfg S: slkfjgsdlfjg;dslfjgdsfg
S: ;lasfgsdfg 45243 z!$14325dc S: ;lasfgsdfg 45243 z!$14325dc
R: OK Kerberos V4 authentication successful R: 2.0 OK Kerberos V4 authentication successful
Courtemanche/Mansour/O'Leary 5 Expires May 1998
3.2.1 Authentication with Proxy Access 3.2.1 Authentication with Proxy Access
The proxy mechanism is the ability to have data posted from through an The proxy mechanism is the ability to have data posted from through an
indirect source. To handle this requirement, SASL mechanisms have a indirect source. To handle this requirement, SASL mechanisms have a
separate _Authentication_ and _authorization_ identity. Thus, server A separate "Authentication" and "authorization" identity. Thus, server A
could authenticate to server B using server A's credentials with the could authenticate to server B using server A's credentials with the
authorization identity of user X. This effectively allows PROXY authorization identity of user X. This effectively allows PROXY
operations between servers. Some older SASL mechanisms do not support operations between servers. Some older SASL mechanisms do not support
both authentication and authorization and therefore can't be used when both authentication and authorization and therefore can't be used when
PROXY operations are required. As per the SASL profile, the PROXY operations are required. As per the SASL profile, the
authorization identity is the one used to determine if the operation authorization identity is the one used to determine if the operation
should be allowed or not. The authentication identity ensures the should be allowed or not. The authentication identity ensures the
transaction is originating from a trusted sender. transaction is originating from a trusted sender.
3.2.2 Authentication for Anonymous Access 3.2.2 Authentication for Anonymous Access
SASL defines an ANONYMOUS authentication mechanism that must be used if SASL defines an ANONYMOUS authentication mechanism that must be used if
anonymous access is to be implemented by an iRIP capable server. This is anonymous access is to be implemented by an iRIP capable server. This
done by using the standard SASL authentication method and requesting the is done by using the standard SASL authentication method and requesting
ANONYMOUS mechanism. The mechanism consists of a single message from the the ANONYMOUS mechanism. The mechanism consists of a single message
client to the server. The client sends optional trace information in the from the client to the server. The client sends optional trace
for of a human readable string. It is recommended that the trace information in the for of a human readable string. It is recommended
information take one of three forms: An [RFC-822] Internet e-mail that the trace information take one of three forms: An [RFC-822]
address, an opaque ASCII string wich does not contain the _@_ character Internet e-mail address, an opaque ASCII string wich does not contain
and can be interpreted by the system administrator of the client's the "@" character and can be interpreted by the system administrator of
domain or nothing. the client's domain or nothing.
The following is an example of anonymous access using an opaque ASCII The following is an example of anonymous access using an opaque ASCII
string: string:
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228> S: <establish a connection to TCP port 5228>
R: 2.2 AboutTime iRIPServer@xyx.com Ready R: 2.0 AboutTime iRIPServer@xyx.com Ready
S: AUTHENTICATE ANONYMOUS S: AUTHENTICATE ANONYMOUS
R: + R: +
S: c21yaGM S: c21yaGM
R: 2.2 Welcome anonymous R: 2.0 Welcome anonymous
An iRIP capable server permitting anonymous access will permit 3.2.3 Authentication whit plain text password: An example
operations, usually restricted to limited and non-destructive commands.
To properly implement the ANONYMOUS authentication, refer to [ANON- SASL allows for a server implementation to support simultaniousely many
SASL]. different authentication mechanism, one of them being the well known
plain text password. Altough plain text password is a very vulnerable
authentication mechanism, it may be adequate for some applications and
is illustrated here because it is well known and understood. To
properly implement the PLAIN authentication mechanism, refer to
[PLAINTRAN-SASL] as listed in the bibliography section of this
3.3 CAPABILITY Courtemanche/Mansour/O'Leary 6 Expires February 1998
The CAPABILITY command tells the server to return a list of capabilities document.
it supports. The server must return a CAPABILITY response with
"IRIPrev1" as one of the listed capabilities. The CAPBILITY command can
be issued in any connection state and the reply is not dependent upon
the connection state.
Courtemanche/Mansour/O'Leary 6 Expires May 1998 R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228>
R: 2.0 AboutTime iRIPServer@xyx.com Ready
S: AUTHENTICATE PLAIN johndoe@xyz.com \0 open-sesame
R: 2.0 Welcome johndoe@xyz.com
3.3 CAPABILITY
The CAPABILITY command tells the server to return a list of
capabilities it supports. The server must return a CAPABILITY response
with "IRIPrev1" as one of the listed capabilities. The CAPBILITY
command can be issued in any connection state and the reply is not
dependent upon the connection state.
A capability name which begins with "AUTH=" indicates that the server A capability name which begins with "AUTH=" indicates that the server
supports that particular authentication mechanism. supports that particular authentication mechanism.
Example: Example:
S: CAPABILITY S: CAPABILITY
R: CAPABILITY IRIPrev1 AUTH=KERBEROS_V4 R: CAPABILITY IRIPrev1 AUTH=KERBEROS_V4 AUTH=PLAIN
R: 2.0 OK R: 2.0 OK
3.4 CONTINUE 3.4 CONTINUE
The CONTINUE command is issued by the Sender to allow an ICALDATA The CONTINUE command is issued by the Sender to allow an ICALDATA
request to continue being processed. When the latency time is specified request to continue being processed. When the latency time is specified
on the ICALDATA command, the Receiver must issue a reply to the Sender on the ICALDATA command, the Receiver must issue a reply to the Sender
within the specified time. The reply may be a reply code indicating within the specified time. The reply may be a reply code indicating
that the server has not yet processed the request. The Sender must then that the server has not yet processed the request. The Sender must
tell the server whether to continue or abort. then tell the server whether to continue or abort.
Example: The CONTINUE has the following form:
CONTINUE[:latencyTime]
If the optional latencyTime is present, it specifies the maximum number
of seconds the client will wait for the next response.
In this example, the Sender requests some sort of response from the
server every 10 seconds.
... ...
S: ICALDATA:10 S: ICALDATA:10
R: 354 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF>
S: BEGIN:VCALENDAR S: BEGIN:VCALENDAR
... <etc>
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
<after 10 seconds...> <after 10 seconds...>
R: . R: .
R: 3.5.0 Reply Pending R: 2.0.2 Reply Pending
S: CONTINUE S: CONTINUE:10
R: BEGIN:VCALENDAR R: BEGIN:VCALENDAR
... <etc>
R: END:VCALENDAR R: END:VCALENDAR
R: . R: .
Courtemanche/Mansour/O'Leary 7 Expires February 1998
R: 2.0 OK R: 2.0 OK
3.5 DISCONNECT 3.5 DISCONNECT
The DISCONNECT command signals the end of communication between the The DISCONNECT command signals the end of communication between the
Sender and Receiver. Sender and Receiver.
Example: Example:
S: DISCONNECT S: DISCONNECT
R: 2.1 EXAMPLE.COM IRIP Service closing transmission channel R: 2.1 EXAMPLE.COM IRIP Service closing transmission channel
3.6 ICALDATA 3.6 ICALDATA
The ICALDATA is used specify the iCalendar Object that is to be The ICALDATA is used specify the iCalendar Object that is to be
delivered to one or more recipients specified in the RECIPIENT command. delivered to one or more recipients specified in the RECIPIENT
The format of the command is: command. The format of the command is:
Courtemanche/Mansour/O'Leary 7 Expires May 1998
S: ICALDATA[:latencyTime] S: ICALDATA[:latencyTime]
S: <MIME encapsulated iCalendar Object> S: <MIME encapsulated iCalendar Object>
S: <CRLF>.<CRLF> S: <CRLF>.<CRLF>
R: <MIME encapsulated iCalendar Object > R: <MIME encapsulated iCalendar Object >
R: <CRLF>.<CRLF> R: <CRLF>.<CRLF>
R: <reply code> R: <reply code>
An optional argument to ICALDATA specifies the maximum amount of time The optional latencyTime value specifies the maximum number of seconds
the Sender can wait for a reply. This is followed by iCalendar Object the Sender can wait for a reply. If it is not present, the client
data. The data is terminated by the special sequence <CRLF>.<CRLF>. The places no time limit on the server for a reply. Following the ICALDATA
server reply may optionally contain an iCalendar Object, the special keyword is the iCalendar Object data. The data is terminated by the
sequence <CRLF>.<CRLF> followed by a reply code. special sequence <CRLF>.<CRLF>. The server reply may optionally contain
an iCalendar Object, the special sequence <CRLF>.<CRLF> followed by a
reply code.
S: ICALDATA S: ICALDATA
R: 3.5.4 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF>
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: etc., etc. <etc.>
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: . R: .
R: 2.0 OK R: 2.0 OK
3.7 RECIPIENT 3.7 RECIPIENT
The RECIPIENT command is used to identify a recipient of the iCalendar The RECIPIENT command is used to identify a recipient of the iCalendar
Object. Use multiple RECIPIENT commands to specify multiple recipients. Object. Use multiple RECIPIENT commands to specify multiple
The command format is recipients. The command format is:
RECIPIENT rfc822address <or something ...> RECIPIENT <calendar address>
3.8 SWITCH 3.8 SWITCH
The SWITCH command is used to allow the Sender and Receiver to change The SWITCH command is used to allow the Sender and Receiver to change
roles. Its format is: roles. Its format is:
SWITCH SWITCH
Courtemanche/Mansour/O'Leary 8 Expires February 1998
The SWITCH command is useful in environments where the firewall of a The SWITCH command is useful in environments where the firewall of a
Sender would not allow the Receiver to initiate a connection. The SWITCH Sender would not allow the Receiver to initiate a connection. The
command is issued by the Sender to give the Receiver the opportunity to SWITCH command is issued by the Sender to give the Receiver the
take the role of the Sender. opportunity to take the role of the Sender. The Sender must be in the
authenticated state before the SWITCH command can be used.
The Receiver must respond in one of the following fashions: The Receiver must respond in one of the following fashions:
. send an OK reply and take on the role of Sender a) send an OK reply and take on the role of Sender
. send a error reply indicating refusal and retain the role of Receiver b) send a error reply indicating refusal and retain the role of
Receiver
Courtemanche/Mansour/O'Leary 8 Expires May 1998
If program-A is currently the Sender and sends the SWITCH command and If program-A is currently the Sender and sends the SWITCH command and
receives an OK reply then program-A becomes the Receiver. Program-A is receives an OK reply then program-A becomes the Receiver. Program-A is
then in its initial state and sends a service ready greeting message. then in its initial state and sends a service ready greeting message.
If program-B is currently the Receiver and sends an OK reply in response If program-B is currently the Receiver and sends an OK reply in
to a SWITCH command then program-B becomes the Sender. Program-B is response to a SWITCH command then program-B becomes the Sender.
then in the initial state as if the transmission channel just opened, Program-B is then in the initial state as if the transmission channel
and expects to receive a service ready greeting. just opened, and expects to receive a service ready greeting.
3.9 Error Codes 3.9 Error Codes
iRIP error codes follow the format defined for Status Replies in [ITIP]. iRIP error codes follow the format defined for Status Replies in
All Status Replies as defined in [ITIP] are valid error codes when [ITIP]. All Status Replies as defined in [ITIP] are valid error codes
returned by an iRIP command. when returned by an iRIP command.
In addition to those defined in [ITIP], iRIP defines the following error In addition to those defined in [ITIP], iRIP defines the following
codes: error codes:
2.0.1 START-ICALDATA Start ICAL input; end with <CRLF>.<CRLF>
2.0.2 REPLY-PENDING A timeout has occurred. The server is
still working on the reply. Use CONTINUE
to continue waiting for the reply or
ABORT to terminate the command.
6.0 AUTHORIZATION FAILED General authorization failure 6.0 AUTHORIZATION FAILED General authorization failure
6.1 TRANSITION-NEEDED Indicates the transition from 6.1 TRANSITION-NEEDED Indicates the transition from
a legacy database to a more a legacy database to a more
secure password mechanism, and secure password mechanism, and
reports that the new mechanism reports that the new mechanism
is not usable until "AUTHENTICATE is not usable until "AUTHENTICATE
PLAIN" or a login procedure is used. PLAIN" or a login procedure is used.
skipping to change at line 475 skipping to change at line 534
there is no practical way to transition there is no practical way to transition
every remote service. So, the mechanism every remote service. So, the mechanism
must not allow users to have different must not allow users to have different
passwords for different services. The passwords for different services. The
error code reports that no new plaintext error code reports that no new plaintext
passwords will be accepted from the user passwords will be accepted from the user
at a later date. It could also indicate at a later date. It could also indicate
that the requested mechanism is not that the requested mechanism is not
available. available.
Courtemanche/Mansour/O'Leary 9 Expires February 1998
6.3 ENCRYPT-NEEDED Indicates that the requested mechanism 6.3 ENCRYPT-NEEDED Indicates that the requested mechanism
it to be used in conjunction with a it to be used in conjunction with a
strong external encryption layer. strong external encryption layer.
7.0 TIMEOUT The requested operation could not be 7.0 TIMEOUT The requested operation could not be
completed in the time allotted. completed in the time allotted.
Command execution is suspended pending
a reply to continue or abort.
8.0 GENERAL FAILURE A failure has occurred in the Receiver 8.0 GENERAL FAILURE A failure has occurred in the Receiver
that prevents the operation from that prevents the operation from
succeeding. succeeding.
8.1 SERVER TOO BUSY Sent when a connection cannot be 8.1 SERVER TOO BUSY Sent when a connection cannot be
established because the iRIP Receiver established because the iRIP Receiver
is too busy. is too busy.
Courtemanche/Mansour/O'Leary 9 Expires May 1998
9.0 INVALID IRIP COMMAND An unrecongnized command was received. 9.0 INVALID IRIP COMMAND An unrecongnized command was received.
10.0 NOT HERE The Receiver does not know how to 10.0 NOT HERE The Receiver does not know how to
contact the Calendar Store for the contact the Calendar Store for the
specified RECIPIENT. specified RECIPIENT.
10.1 REFERRAL Accompanied by an alternate address. 10.1 REFERRAL Accompanied by an alternate address.
The RECIPIENT specified should be The RECIPIENT specified should be
contacted at the given alternate contacted at the given alternate
address. address.
4. Security Considerations 4. 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 iRIP transactions are subject to eavesdropping and the integrity of
transactions may be compromised. Since iRIP is designed specifically for iRIP transactions may be compromised. Since iRIP is designed
real time Internet transactions, it is recommended that implementations specifically for real time Internet transactions, it is recommended
use the highest degree of authentication and transmission security that implementations use the highest degree of authentication and
possible. transmission security possible.
Authentication is fundamental to iRIP. It is the basis for granting and Authentication is fundamental to iRIP. It is the basis for granting and
denying access. Without a robust security layer iRIP will be subject to denying access. Without a robust security layer iRIP will be subject to
many possible attacks and the full contents of the server itself may be many possible attacks and the full contents of the server itself may be
at risk. at risk.
4.1 SASL ANONYMOUS Mechanism 4.1 SASL ANONYMOUS Mechanism
Implementing support for the Anonymous SASL significantly increases the Implementing support for the Anonymous SASL significantly increases the
vulnerability of the calendar server and its data. Refer to [ANON-SASL] vulnerability of the calendar server and its data. Refer to [ANON-SASL]
for further information on many threats specific to Anonymous SASL for further information on many threats specific to Anonymous SASL
access. access.
4.2 SASL Profile Definition 4.2 SASL Profile Definition for the protocol
(Need to complete with full details)
The implementation of SASL in iRIP requires the server and client to The implementation of SASL in iRIP requires the server and client to
comply to the following profile extension: comply to the following profile extension:
AUTHENTICATE command. AUTHENTICATE command. Full description of the challenge/response
definition. Starting octet. Interpretation of the authorization
Full description of the challenge/response definition. identity passed should be interpreted.
Starting octet.
Interpretation of the authorization identity passed should be
interpreted.
Courtemanche/Mansour/O'Leary 10 Expires May 1998 Courtemanche/Mansour/O'Leary 10 Expires February 1998
4.3 ITIP Threats 4.3 ITIP Threats
Threat: Spoofing the organizer or attendee. Threat: Spoofing the organizer or attendee.
Solution: The entire protection for spoofing attendees or organizer of a Solution: The entire protection for spoofing attendees or organizer of
meeting resides in the fact that the connection needs to be a meeting resides in the fact that the connection needs to be
authenticated. Spoofing would be possible in the absence of authenticated. Spoofing would be possible in the absence of
authentication. authentication.
Threat: Eavesdropping on the traffic. Threat: Eavesdropping on the traffic.
Solution: If SASL is used to negotiate with the server a security layer, Solution: If SASL is used to negotiate with the server a security
then traffic is no longer in the clear and eavesdropping will not be layer, then traffic is no longer in the clear and eavesdropping will
restricted. not be restricted.
Threat: Flooding of a calendar Threat: Flooding of a calendar
Solution: Implementation of iRIP should limit the size and traffic of Solution: Implementation of iRIP should limit the size and traffic of
transaction from a given source. transaction from a given source.
Threat: Procedural Alarms Threat: Procedural Alarms
Solution: Implementation of iRIP should remove or disallow procedural Solution: Implementation of iRIP should remove or disallow procedural
alarms before delivery. alarms before delivery.
4.4 IRIP-Specific Threats 4.4 IRIP-Specific Threats
Threat: Flooding of connections Threat: Flooding of connections
Solution: Connections that have not been authenticated within 3 seconds Solution: Connections that have not been authenticated within 3 seconds
should be disconnected. Peter/Steve, this looks very arbitrary. Is there should be disconnected.
a better way of doing this ?
5. Examples 5. Examples
5.1 Unathenticated Freebusy Request 5.1 Unathenticated Freebusy Request
This examples shows an anonymous request for the freebusy time of This examples shows an anonymous request for the freebusy time of
sman@example.com sman@example.com.
R: <listen on TCP port 5228> R: <listen on TCP port 5228>
S: <establish a connection to TCP port 5228> S: <establish a connection to TCP port 5228>
R: 2.2 BIG-Time iRIPServer@example.com Ready R: 2.0 BIG-Time iRIPServer@example.com Ready
S: AUTHENTICATE LOGIN anonymous xyz.unknown.com S: AUTHENTICATE ANONYMOUS xyz@unknown.com
R: 2.2 Welcome anonymous R: 2.0 Welcome xyz@example.com
S: RECIPIENT:sman S: RECIPIENT:sman
R: 2.0 OK R: 2.0 OK
S: ICALDATA S: ICALDATA
R: 3.5.4 Start ICAL input; end with <CRLF>.<CRLF> R: 2.0.1 Start ICAL input; end with <CRLF>.<CRLF>
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
Courtemanche/Mansour/O'Leary 11 Expires May 1998
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: ATTENDEE;ROLE=OWNER:A@acme.com S: ORGANIZER:mailto:xyz@unknown.com
S: ATTENDEE:sman@acme.com S: ATTENDEE:mailto:sman@example.com
S: DTSTAMP:19971113T190000-0800 S: DTSTAMP:19971113T190000Z
S: DTSTART:19971115T080000-0800
S: DTEND:19971115T200000-0800 Courtemanche/Mansour/O'Leary 11 Expires February 1998
S: UID:www.acme.com-873970198738777@host.com
S: DTSTART:19971115T160000Z
S: DTEND:19971116T040000Z
S: UID:www.example.com-873970198738777@host.com
S: END:VFREEBUSY S: END:VFREEBUSY
S: END:VCALENDAR S: END:VCALENDAR
S: . S: .
R: Content-Type:text/calendar; method=REQUEST; 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:-//ACME/DesktopCalendar//EN R: PRODID:-//EXAMPLE/DesktopCalendar//EN
R: METHOD:REPLY R: METHOD:REPLY
R: VERSION:2.0 R: VERSION:2.0
R: BEGIN:VFREEBUSY R: BEGIN:VFREEBUSY
R: ATTENDEE:sman@example.com R: ATTENDEE:mailto:sman@example.com
R: DTSTAMP:19971113T190005-0800 R: DTSTAMP:19971113T190005Z
R: DTSTART:19971115T080000-0800 R: DTSTART:19971115T160000Z
R: DTEND:19971115T200000-0800 R: DTEND:19971116T040000Z
R: UID:www.acme.com-873970198738777@host.com R: UID:www.example.com-873970198738777@host.com
R: FREEBUSY:19970701T090000-0700/PT1H,19970701T140000-0700/PT30H R: FREEBUSY:19971113T230000Z/PT1H,19971114T210000Z/PT30M
R: END:VFREEBUSY R: END:VFREEBUSY
R: END:VCALENDAR R: END:VCALENDAR
R: . R: .
R: 2.5 OK R: 2.0 OK
S: DISCONNECT S: DISCONNECT
R: OK R: 2.0 OK
R: <disconnect> R: <disconnect>
S: <disconnect> S: <disconnect>
5.2 Using Switch
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 BIG-Time iRIPServer@example.com Ready
S: AUTHENTICATE KERBEROS_V4 93407205
S: <more authentication information>
R: 2.0 OK
S: SWITCH
R: 2.0 OK
<sender now becomes the receiver ...>
S: 2.0 Other-BIG-Time iRIPServer@example2.com Ready
R: AUTHENTICATE KERBEROS_V4 273678199dao986pq8u98u9e8w0-0--0--0werg
S: 2.0 Welcome
<receiver can now authenticate and send anything pending for the sender>
5.3 Resource Scheduling
R: <listen on TCP port 5228>
S: <connect to port 5228>
R: 2.0 Welcome
S: AUTHENTICATE KERBEROS_V4 7SF8S3&#
S: <more authentication information>
R: 2.0 OK, you're in like Flynn
S: RECIPIENT Large_Conference_Room
R: 2.0 OK
Courtemanche/Mansour/O'Leary 12 Expires February 1998
S: RECIPIENT Overhead_Projector_1
R: 2.0 OK
S: ICALDATA: 10
S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Inlet MIMEDIR//EN
S: VERSION:2.0
S: BEGIN:VEVENT
S: DTSTART:19980706T190000Z
S: DTEND:19980706T203000Z
S: LOCATION:Large Conference Room
S: DESCRIPTION:Big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR
S: .
R: <looks up availability in database>
R: .
R: 2.0 OK
S: RECIPIENT Large_Conference_Room
R: 2.0 OK
S: RECIPIENT Overhead_Projector_1
R: 2.0 OK
S: ICALDATA: 10
S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
S: VERSION:2.0
S: BEGIN:VEVENT
S: DTSTART:19980708T220000Z
S: DTEND:19980708T230000Z
S: LOCATION:Large Conference Room
S: DESCRIPTION:Another big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR
S: .
R: <looks up availability in database>
R: .
R: 4.0 No, Large_Conference_Room not available at that time.
S: RECIPIENT Large_Conference_Room
R: 2.0 OK
S: RECIPIENT Overhead_Projector_1
R: 2.0 OK
S: ICALDATA: 10
S: BEGIN:VCALENDAR
S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
S: VERSION:2.0
S: BEGIN:VEVENT
S: DTSTART:19980708T160000Z
S: DTEND:19980708T170000Z
S: LOCATION:Large Conference Room
S: DESCRIPTION:Another big customer meeting in Large Conference room.
S: SUMMARY:Customer meeting
S: PRIORITY:1
S: END:VEVENT
S: END:VCALENDAR
S: .
R: <looks up availability in database>
Courtemanche/Mansour/O'Leary 13 Expires February 1998
R: <10 seconds pass>
R: .
R: 7.0 Database too busy, try again later
S: DISCONNECT
R: 2.0 OK
R: <drops TCP connection>
6. Acknowledgments 6. 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:
Mugino Saeki Doug Royer, Mugino Saeki
7. Bibliography 7. Bibliography
[ANON-SASL] "Anonymous SASL mechanism", draft-newman-sasl-anon-00.txt [ANON-SASL] "Anonymous SASL mechanism", draft-newman-sasl-anon-00.txt
[ICAL] "Internet Calendaring and Scheduling Core Object Specification - [PLAINTRAN-SASL] "Plain text password SASL mechanism",
iCalendar", Internet-Draft, July 1997, ftp://ftp.ietf.org/internet- draft-newman-sasl-plaintrans-03.txt
drafts/draft-ietf-calsch-ical-02.txt.
Courtemanche/Mansour/O'Leary 12 Expires May 1998 [ICAL] "Internet Calendaring and Scheduling Core Object Specification -
iCalendar", Internet-Draft, July 1997,
ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-02.txt.
[ICMS] "Internet Calendaring Model Specification", Internet-Draft, July [ICMS] "Internet Calendaring Model Specification", Internet-Draft, July
1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt. 1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt.
[ITIP] "iCalendar Transport-Independent Interoperability Protocol (iTIP) [ITIP] "iCalendar Transport-Independent Interoperability Protocol
: Scheduling Events, Busy Time, To-dos and Journal Entries ", Internet- (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ",
Draft, October 1997, http://www.imc.org/draft-ietf-calsch-itip-01.txt. Internet-Draft, October 1997,
http://www.imc.org/draft-ietf-calsch-itip-01.txt.
[IMIP] "iCalendar Message-based Interoperability Protocol (iMIP), [IMIP] "iCalendar Message-based Interoperability Protocol (iMIP),
Internet-Draft, October 1997, http://www.imc.org/draft-ietf-calsch-imip- Internet-Draft, October 1997,
02.txt. http://www.imc.org/draft-ietf-calsch-imip-02.txt.
[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646", [ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
Internet-Draft, July,1996, ftp://ftp.ietf.org/internet-drafts/draft- Internet-Draft, July,1996,
yergeau-utf8-01.txt. ftp://ftp.ietf.org/internet-drafts/draft-yergeau-utf8-01.txt.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982. Messages", STD 11, RFC 822, August 1982.
[RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security [RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC
1847, October 1995. 1847, October 1995.
[RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC [RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type," RFC
2112, March 1997. 2112, March 1997.
[RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)," [RFC-2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP),"
RFC 2015, October 1996. RFC 2015, October 1996.
[RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail [RFC-2045] Freed, N., Borenstein, N., " Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
2045, November 1996. 2045, November 1996.
[RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail [RFC-2046] Freed, N., Borenstein, N., " Multipurpose Internet Mail
Courtemanche/Mansour/O'Leary 14 Expires February 1998
Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996. November 1996.
[RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet Mail [RFC-2048] Freed, N., J. Klensin, J. Postel, "Multipurpose Internet
Extensions (MIME) - Part Four: Registration Procedures", RFC 2048, Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048,
January 1997. January 1997.
[RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)", [RFC-2222] J. Meyers, Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. RFC 2222, October 1997.
8. Open Issues. 8. Open Issues
Anonymous access _ Mugino,
Proxy Access via SASL _ Mugino, how does the proxy capability of SASL
maches iRIP's requirement for PROXY capability ?
Courtemanche/Mansour/O'Leary 13 Expires May 1998
Registration of the SASL profile for iRIP with the IANA. Registration of the SASL profile for iRIP with the IANA.
Calendar addressing
Port Number registration
9. Author's Address 9. Author's Address
The following address information is provided in a vCard v2.1, The following address information is provided in a vCard v2.1,
Electronic Business Card, format. Electronic Business Card, format.
BEGIN:VCARD BEGIN:VCARD
FN:Andre Courtemanche FN:Andre Courtemanche
ORG:CS&T ORG:CS&T
ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R 3L5;Canada
3L5;Canada
TEL;WORK;MSG:+1-514-733-8500 TEL;WORK;MSG:+1-514-733-8500
TEL;WORK;FAX:+1-514-733-8788 TEL;WORK;FAX:+1-514-733-8788
EMAIL;INTERNET:andre@cst.ca EMAIL;INTERNET:andre@cst.ca
END:VCARD END:VCARD
BEGIN:VCARD BEGIN:VCARD
VERSION:2.1
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-415-937-2378 TEL;WORK;MSG:+1-650-937-2378
TEL;WORK;FAX:+1-415-428-4059 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:Peter O'Leary FN:Pete O'Leary
ORG:Amplitude Software Corp. ORG:Amplitude
ADR;WORK;POSTAL;PARCEL:;;185 Berry St. Suite 4700; San Francisco;CA; ADR;WORK;POSTAL;PARCEL:;;
94107;USA
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
EMAIL;INTERNET:poleary@amplitude.com EMAIL;INTERNET:pete@amplitude.com
END:VCARD END:VCARD
Courtemanche/Mansour/O'Leary 14 Expires May 1998 The iCalendar object is a result of the work of the Internet
Engineering Task Force Calendaring and scheduling Working Group. The
chairman of that working group is:
BEGIN:VCARD
FN:Anik Ganguly
Courtemanche/Mansour/O'Leary 15 Expires February 1998
ORG:Open Text Inc.
ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road;Suite 101
Livonia;MI;USA
TEL;WORK;MSG:+1-734-542-5955
EMAIL;INTERNET:ganguly@acm.com
END:VCARD
10. Full Copyright Statement 10. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it MAY be copied and furnished to This document and translations of it MAY be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation MAY be prepared, copied, published and assist in its implmentation MAY be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are
on all such copies and derivative works. However, this document itself included on all such copies and derivative works. However, this
MAY NOT be modified in any way, such as by removing the copyright notice document itself MAY NOT be modified in any way, such as by removing the
or references to the Internet Society or other Internet organizations, copyright notice or references to the Internet Society or other
except as needed for the purpose of developing Internet standards in Internet organizations, except as needed for the purpose of developing
which case the procedures for copyrights defined in the Internet Internet standards in which case the procedures for copyrights defined
Standards process MUST be followed, or as required to translate it into in the Internet Standards process MUST be followed, or as required to
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 "AS This document and the information contained herein is provided on an
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Courtemanche/Mansour/O'Leary 15 Expires May 1998
 End of changes. 105 change blocks. 
251 lines changed or deleted 419 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/