idnits 2.17.1 

draft-ietf-calsch-irip-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents. 

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     current Internet-Drafts. 

  ** The document seems to lack a 1id_guidelines paragraph about the list of
     Shadow Directories. 

  ** The document is more than 15 pages and seems to lack a Table of Contents.

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == The page length should not exceed 58 lines per page, but there was 1
     longer page, the longest (page 1) being 1430 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 23 instances of too long lines in the document, the longest
     one being 2 characters in excess of 72.

  ** There are 5 instances of lines with control characters in the document.

  ** The abstract seems to contain references ([ICAL], [ICMS], [RFC-2045],
     [RFC-2046], [RFC-2047], [RFC-2048], [RFC-2049], [ITIP]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
     document.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 143: '...hat the Receiver MUST interpret relati...'
     RFC 2119 keyword, line 232: '...Reply codes MAY be followed by arbitra...'
     RFC 2119 keyword, line 233: '...nd the terminating <CRLF> MUST be 1024...'
     RFC 2119 keyword, line 235: '...rminating <CRLF> MUST be l024 characte...'
     RFC 2119 keyword, line 652: '...    address. The referral address MUST...'
     (4 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The exact meaning of the all-uppercase expression 'MAY NOT' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  == The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).
     
     Found 'MAY NOT' in this paragraph:
     
    This document and translations of it MAY be copied and furnished to
     others, and derivative works that comment on or otherwise explain it or
     assist in its implmentation MAY be prepared, copied, published and
     distributed, in whole or in part, without restriction of any kind,
     provided that the above copyright notice and this paragraph are included
     on all such copies and derivative works.  However, this document itself
     MAY NOT be modified in any way, such as by removing the copyright notice
     or references to the Internet Society or other Internet organizations,
     except as needed for the purpose of developing Internet standards in
     which case the procedures for copyrights defined in the Internet
     Standards process MUST be followed, or as required to translate it into
     languages other than English.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (November 19, 1998) is 9291 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? 'ITIP' on line 1170 looks like a reference

  -- Missing reference section? 'ICAL' on line 288 looks like a reference

  -- Missing reference section? 'RFC-2045' on line 1198 looks like a reference

  -- Missing reference section? 'RFC-2046' on line 1202 looks like a reference

  -- Missing reference section? 'RFC-2047' on line 1205 looks like a reference

  -- Missing reference section? 'RFC-2048' on line 1209 looks like a reference

  -- Missing reference section? 'RFC-2049' on line 34 looks like a reference

  -- Missing reference section? 'ICMS' on line 1167 looks like a reference

  -- Missing reference section? 'IMIP' on line 1175 looks like a reference

  -- Missing reference section? 'IRIP' on line 1218 looks like a reference

  -- Missing reference section? 'ICSM' on line 118 looks like a reference

  -- Missing reference section? 'SASL' on line 1218 looks like a reference

  -- Missing reference section? 'RFC-822' on line 1183 looks like a reference

  -- Missing reference section? 'ANON-SASL' on line 694 looks like a reference

  -- Missing reference section? 'ID-UTF8' on line 1179 looks like a reference

  -- Missing reference section? 'RFC-1847' on line 1186 looks like a reference

  -- Missing reference section? 'RFC-2112' on line 1192 looks like a reference

  -- Missing reference section? 'RFC-2015' on line 1195 looks like a reference

  -- Missing reference section? 'RFC-2222' on line 1213 looks like a reference


     Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 22 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group		                    Andre Coutemanche/CS&T
3	Internet Draft		                            Steve Mansour/Netscape
4	<draft-ietf-calsch-irip-02.txt	                    Pete O'Leary/Amplitude
5	Expires six months from:		                 November 19, 1998

7	         ICalendar Real-time Interoperability Protocol (IRIP)

9	Status of this Memo

11	This document is an Internet-Draft.  Internet-Drafts are working
12	documents of the Internet Engineering Task Force (IETF), its areas, and
13	its working groups. Note that other groups may also distribute working
14	documents as Internet-Drafts.

16	Internet-Drafts are draft documents valid for a maximum of six months.
17	Internet-Drafts may be updated, replaced, or made obsolete by other
18	documents at any time.  It is not appropriate to use Internet-Drafts as
19	reference material or to cite them other than as a "working draft" or
20	"work in progress".

22	To learn the current status of any Internet-Draft, please check the
23	1id-abstracts.txt listing contained in the Internet-Drafts Shadow
24	Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
25	ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
26	Distribution of this document is unlimited.

28	Abstract

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

36	This document is based on the calendaring and scheduling model defined
37	by [ICMS].

39	This document is based on discussions within the Internet Engineering
40	Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
41	More information about the IETF CALSCH working group activities can be
42	found on the IMC website at http://www.imc.org, the IETF website at
43	http://www.ietf.org/html.charters/calsch-charter.html. Refer to the
44	references within this document for further information on how to
45	access these various documents.

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

50	Courtemanche/Mansour/O'Leary        1                    Expires: May 1999
51	1 Introduction

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

57	1.1 Related Memos

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

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

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

68	-  [ITIP] specifies an interoperability protocol for scheduling between
69	   different implementations;

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

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

78	1.2 Formatting Conventions

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

85	Calendaring and scheduling roles defined by [ICMS] are referred to in
86	quoted-strings of text with the first character of each word in upper
87	case. For example, "Organizer" refers to a role of a "Calendar User"
88	within the scheduling protocol defined by [ITIP].

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

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

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

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

110	Courtemanche/Mansour/O'Leary        2                    Expires: May 1999
111	"VALUE" parameter refers to the iCalendar property parameter used to
112	override the default data type for a property value.

114	2 Architecture

116	[IRIP] enables real-time interoperability between scheduling systems
117	using the iCalendar [ICAL] format for information exchange. [IRIP] is
118	designed primarily to allow Calendar Services (CS) as defined in [ICSM]
119	to forward real-time requests on behalf of Calendar User Agents (CUA)
120	and receive real-time responses. The goal of [IRIP] is to allow two or
121	more CS's to establish connections with each other. However, the design
122	of [IRIP] does not preclude its use from CUA directly to CS. [IRIP]
123	allows a CS to initiate a session and perform operations on behalf of
124	multiple CUA's without the need to reauthenticate the session for each
125	CUA.

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

131	user - the CU that initiates a request.
132	sender - the agent used to contact a receiving device, send commands,
133	and receive replies.

135	receiver - the agent that accepts commands and sends replies.

137	The sender and receiver can take on varying roles of CUA and CS as
138	described in [ICMS].

140	[IRIP] allows two CS's to establish different levels of trust. When an
141	[IRIP] connection is first established, both parties to the connection
142	authenticate one another using the AUTHENTICATE command. The Sender can
143	then initiate commands that the Receiver MUST interpret relative to the
144	Sender's access control. The AUTHENTICATE command supports proxy
145	operations via [SASL].

147	1.3 State Diagram

149	An [IRIP] session begins when a TCP/IP connection is made on port 5228.
150	The protocol begins in the Connected state. The AUTHENTICATE command,
151	when successful, begins the Authenticated state. From the Authenticated
152	state, the sender can initiate a request using the RECIPIENT command.
153	The Sender can then issues as many RECIPIENT commands as the operation
154	in progress requires until sending an ICALDATA command. After
155	completing the ICALDATA command, the Sender must wait for a response
156	from the receiver. The Receiver's response can indicate that the
157	request has been completed or that the request could not be completed
158	in the time specified by the Sender. When the response has ended, the
159	Sender returns to the Authenticated state where another request can be
160	initiated.  Implementations should be prepared to handle a DISCONNECT
161	at any point in this state diagram.

163	Courtemanche/Mansour/O'Leary        3                    Expires: May 1999
164	      +---------SWITCH-----------+                +------------+
165	      |                          |  +-DISCONNECT->| TERMINATED |
166	      |                          |  |             +------------+
167	      V                          |  |                      A
168	+------------+                 +---------------+           |
169	| Connected  |--AUTHENTICATE-->| Authenticated |----ERROR--+
170	+------------+                 |               |<--------+
171	 +--------------ABORT--------->|   (Proxy)     |         |
172	 |                       +---->|               |<---+    |
173	 |                       |     +---------------+    |    |
174	 |  +--RECIPIENT--+      |                |  |      |    |
175	 |  |             |      +--AUTHENTICATE--+  |      |    |
176	+----------+      V                          |      | COMPLETE
177	|   Send   |<---------------RECIPIENT--------+      |   or
178	+----------+                                        |  ABORT
179	   |         +--------COMPLETE or ERROR-------------+    |
180	ICALDATA     |                                           |
181	   |         |                                           |
182	   |  +---------+                           +--------+   |
183	   +->| Receive |--(Response from Server)-->|  Idle  |---+
184	      +---------+                           +--------+
185	           A                                     |
186	           |                                     |
187	           +--------------CONTINUE---------------+

189	1.4 Calendar Address

191	Calendar addresses are URIs. IRIP uses the following forms of URI.

193	irip://<host>:<port>/<relativeCALID>

195	where:

197	    <host> is address of the computer on which the IRIP server is
198	           running

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

202	<relativeCALID> is an identifier that uniquely identifies the calendar.
203	There is no implied structure in a relativeCALID, it is an arbitrary
204	string of characters. It may refer to the calendar of a user or of a
205	resource such as a conference room.

207	Examples:

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

213	1.5 Bounded Latency

215	[IRIP] is designed so that the Sender can either obtain an immediate
216	response from a request or discover within a known amount of time that
217	the request cannot be completed. When the Sender initiates a command
218	that the Receiver cannot complete within a given amount of time, the
219	Receiver can return an error code to the Sender indicating this
220	condition. The Sender then issues either a CONTINUE or ABORT command.

222	Courtemanche/Mansour/O'Leary        4                    Expires: May 1999
223	The ABORT command immediately terminates the command in progress. The
224	CONTINUE command instructs the Receiver to continue processing the
225	command. The ABORT command causes the Receiver to discard the current
226	command and return to the Authenticated state.

228	3 Protocol

230	3.1 Commands

232	Reply codes MAY be followed by arbitrary text. The length of the reply
233	code, any subsequent text, and the terminating <CRLF> MUST be 1024
234	characters or less. The length of a RECIPIENT command and its single
235	argument, and the terminating <CRLF> MUST be l024 characters or less.
236	Implementations may truncate RECIPIENT lines or reply code lines that
237	exceed 1024 characters.

239	In the examples below, lines preceded with "S:" refer to the Sender and
240	lines preceded with "R:" refer to the Receiver.

242	3.1.1 ABORT

244	The ABORT command is issued by the Sender to stop an ICALDATA request
245	from being processed further. When the latency time is specified on the
246	ICALDATA command, the Receiver must issue a reply to the Sender within
247	the specified time.  The reply may be a reply code indicating that the
248	server has not yet processed the request.  The Sender must then tell
249	the server whether to continue or abort.

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

254	Example:

256	...
257	S: ICALDATA:10
258	R: 2.0.1
259	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
260	S: Content-Transfer-Encoding: quoted-printable
261	S:
262	S: BEGIN:VCALENDAR
263	S: ...
264	S: END:VCALENDAR
265	S: .
266	<10 seconds elapse...>
267	R: .
268	R: 2.0.2
269	S: ABORT
270	R: 2.0.3
271	S: <sender can now begin another command or it can disconnect>

273	The Receiver will issue the 8.2 reply code if it receives an ABORT when
274	the ICALDATA command is not in progress. This could happen if the
275	Sender issues an ABORT command at a point in time after the Receiver
276	has completed the operation and issued the reply code but before the
277	Sender has actually received the reply code. For example:

279	S: ICALDATA:10
280	S: <an ICAL object>
281	S: .

283	Courtemanche/Mansour/O'Leary        5                    Expires: May 1999
284	<10 seconds elapse...>
285	S: ABORT
286	R: 2.0
287	R: 8.2
288	In this case, the reply code 2.0 is in response to the [ICAL] object
289	and the reply code 8.2 is in response to the ABORT command.

291	3.1.2 AUTHENTICATE

293	The authentication mechanism used in [IRIP] is based on [SASL]. This
294	allows the [IRIP] senders and receivers to dynamically negotiate
295	authentication and encryption mechanisms. [SASL] defines authentication
296	methods such as ANONYMOUS and encapsulates concepts of PROXY used in
297	[IRIP].

299	The AUTHENTICATE command is used by the client to identify itself to
300	the server. Authentication is required before the following commands
301	can be issued:

303	ABORT
304	AUTHENTICATE
305	CONTINUE
306	DISCONNECT
307	ICALDATA
308	RECIPIENT
309	SWITCH

311	The format of the command is of the following:

313	AUTHENTICATE <mechanism> <initial data>

315	from which the standard [SASL] interchange will take place as defined
316	in the [SASL] profile. Authentication mechanisms will differ from one
317	server to the other, from one version to another. The CAPABILITY
318	command must be used by the sender to determine the best authentication
319	mechanism to use.

321	Example of an authentication session with kerberose version 4:

323	R: 2.0 Welcome IRIP Server
324	S: AUTHENTICATE KERBEROS_V4 744RTU3r#
325	S: sfdkjgs;lfdjg s;ldfkj gslkfdjgwrt949jsl4ns.dlngsdf
326	S: slkfjgsdlfjg;dslfjgdsfg
327	S: ;lasfgsdfg  45243 z!$14325dc
328	R: 2.0

330	3.1.2.1 Authentication with Proxy Access

332	The proxy mechanism is the ability to have data posted by an indirect
333	source. To handle this requirement, [SASL] mechanisms have a separate
334	"Authentication" and "authorization" identity. Thus, server A could
335	authenticate to server B using server A's credentials with the
336	authorization identity of user X. This effectively allows PROXY
337	operations between servers.  Some older [SASL] mechanisms do not
338	support both authentication and authorization and therefore cannot be
339	used when PROXY operations are required.  As per the [SASL] profile,
340	the authorization identity is the one used to determine if the
341	operation should be allowed or not. The authentication identity ensures
342	the transaction is originating from a trusted sender.

344	Courtemanche/Mansour/O'Leary        6                    Expires: May 1999
345	3.1.2.2 Authentication for Anonymous Access

347	SASL defines an ANONYMOUS authentication mechanism that must be used if
348	anonymous access is to be implemented by an [IRIP] capable server. This
349	is done by using the standard [SASL] authentication method and
350	requesting the ANONYMOUS mechanism. The mechanism consists of a single
351	message from the client to the server. The client sends optional trace
352	information in the form of a human readable string. It is recommended
353	that the trace information take one of three forms: An [RFC-822]
354	Internet e-mail address, an opaque ASCII string which does not contain
355	the "@" character and can be interpreted by the system administrator of
356	the client's domain or nothing. Anonymous authentication is further
357	described in [ANON-SASL].

359	The following is an example of anonymous access using an opaque ASCII
360	string:

362	R: <listen on TCP port 5228>
363	S: <establish a connection to TCP port 5228>
364	R: 2.0
365	S: AUTHENTICATE ANONYMOUS
366	R: +
367	S: c21yaGM
368	R: 2.0

370	3.1.3 CAPABILITY

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

379	The format of the capabilities response is a series of lines with the
380	form <name>[=<value>]. Each name-value pair is delimited by a <CRLF>
381	character sequence. The sequence <CRLF>.<CRLF> followed by a reply code
382	terminates the response.

384	Example:

386	S: CAPABILITY
387	R: CAPABILITY IRIPrev1
388	R: AUTH=KERBEROS_V4
389	R: AUTH=PLAIN
390	R: .
391	R: 2.0

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

396	Capability            Occurs  Description
397	--------------------- ------- ----------------------------------
398	IRIPrev1                  1   Revision of IRIP, must be
399	                              "IRIPrev1"

401	AUTH                      0+  Authentication mechanism(s)
402	                              supported

404	Courtemanche/Mansour/O'Leary        7                    Expires: May 1999
405	MAXICALOBJECTSIZE     0 or 1  An integer value that specifies
406	                              The largest ICAL object the server
407	                              will accept. Objects larger than
408	                              this will be rejected.

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

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

416	3.1.4 CONTINUE

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

426	The CONTINUE has the following form:

428		CONTINUE[:latencyTime]

430	If the optional latencyTime is present, it is a positive integer that
431	specifies the maximum number of seconds the client will wait for the
432	next response. If it is omitted, the receiver waits an indefinite
433	period of time for the response.

435	In this example, the Sender requests some sort of response from the
436	server every 10 seconds.

438	...
439	S: ICALDATA:10
440	R: 2.0.1
441	S: BEGIN:VCALENDAR
442	<etc>
443	S: END:VCALENDAR
444	S: .
445	<after 10 seconds...>
446	R: .
447	R: 2.0.2  Reply Pending
448	S: CONTINUE:10
449	R: BEGIN:VCALENDAR
450	<etc>
451	R: END:VCALENDAR
452	R: .
453	R: 2.0
454	3.1.5 DISCONNECT

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

459	Example:

461	S: DISCONNECT
462	R: 2.0

464	Courtemanche/Mansour/O'Leary        8                    Expires: May 1999
465	3.1.6 ICALDATA

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

471	S: ICALDATA[:latencyTime]
472	R: 2.0.1
473	S: <MIME encapsulated ITIP Message>
474	S: .
475	R: <MIME encapsulated ITIP Message>
476	R: .
477	R: <reply code>

479	The optional latencyTime value specifies the maximum number of seconds
480	the Sender can wait for a reply.  If it is not present, the client
481	places no time limit on the server for a reply. A reply code of 2.0.1
482	indicates that the [ITIP] message data can be sent.  When the entire
483	message has been sent, the sender terminates sending data with the
484	special sequence <CRLF>.<CRLF>. The receiver reply may optionally
485	contain an ITIP message followed by the special sequence <CRLF>.<CRLF>
486	followed by a reply code. Only the [ITIP] message is optional in the
487	reply, the <CRLF>.<CRLF> sequence must be present.

489	S: ICALDATA
490	R: 2.0.1
491	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
492	S: Content-Transfer-Encoding: 7bit
493	S:
494	S: BEGIN:VCALENDAR
495	<etc.>
496	S: END:VCALENDAR
497	S: .
498	R: .
499	R: 2.0

501	3.1.7 RECIPIENT

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

507	RECIPIENT <calendar address>

509	A response code of 2.0 indicates that the calendar address is available
510	for [ITIP] messages. If the receiver does not accept [ITIP] messages
511	for the specified calendar address, it may respond with [ITIP] reply
512	code 5.3 to indicate that the calendar address is unknown or the IRIP
513	referral reply code, 10.1, and supply the new calendar address. In
514	either case, the IRIP server does not deliver the [ITIP] message when
515	the reply code is 5.3 or 10.1.

517	3.1.8 SWITCH

519	The SWITCH command is used to allow the Sender and Receiver to change
520	roles.  Its format is:

522	Courtemanche/Mansour/O'Leary        9                    Expires: May 1999
523	    SWITCH

525	The SWITCH command is useful in environments where the firewall of a
526	Sender would not allow the Receiver to initiate a connection. The
527	SWITCH command is issued by the Sender to give the Receiver the
528	opportunity to take the role of the Sender.  The Sender must be in the
529	authenticated state before the SWITCH command can be used.

531	The Receiver must respond in one of the following fashions:

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

536	If program-A is currently the Sender and sends the SWITCH command and
537	receives an OK reply then program-A becomes the Receiver.  Program-A is
538	then in its initial state and sends a service ready greeting message.

540	If program-B is currently the Receiver and sends an OK reply in
541	response to a SWITCH command then program-B becomes the Sender.
542	Program-B is then in the initial state (connected) as if the
543	transmission channel just opened, and expects to receive a service
544	ready greeting.

546	3.2 Fanout and Queued Transactions

548	An IRIP server must be able to fanout requests targeted at other IRIP
549	servers. An IRIP server may queue information targeted at other IRIP
550	servers. There are several reasons for queing requests. One reason is
551	that firewall issues may prevent one server from contacting another.
552	IRIP provides a SWITCH command described later in this document to help
553	address this situation.

555	IRIP servers can establish trust relationships between each other. A
556	trusted relationship means:

558	-  one server must authenticate with the other
559	-  authenticated calendars on one server are trusted and treated as
560	   authenticated on the other.

562	The trusted relationship need not be bi-directional. That is, the fact
563	that IRIP server A trusts IRIP server B does not necessarily mean that
564	B trusts A.

566	A trusted relationship between two IRIP servers means that one server
567	can queue transactions for the other server and deliver them some time
568	later. If IRIP server B trusts A, then A can queue requests for B. If A
569	does not trust B then B cannot accumulate requests for A.

571	Certain requests may need to be delivered and replied to in real-time.
572	In fact, a requester may wish to cancel the request if the reply cannot
573	be delivered in real-time. In IRIP it is possible to detect whether or
574	not a reply will be made in real-time and cancel the request if
575	necessary.

577	3.3 Reply Codes

579	[IRIP] error codes follow the format defined for Status Replies in
580	[ITIP]. All Status Replies as defined in [ITIP] are valid error codes

582	Courtemanche/Mansour/O'Leary       10                    Expires: May 1999
583	when returned by an [IRIP] command.

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

588	REPLY
589	CODE   DESCRIPTOR              MEANING
590	------ ----------------------  --------------------------------------
591	2.0.1  START-ICALDATA          Start ICAL input; end with
592	                               <CRLF>.<CRLF>

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

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

605	2.0.4  TRUSTED-WILL-ATTEMPT    The specified Calendar is not here
606	                               but a trust relationship exists
607	                               between this server and the server
608	                               on which the Calendar exists. An
609	                               attempt will be made to deliver the
610	                               request or reply to the Calendar
611	                               anyway.

613	2.0.5  TRUSTED-WILL-QUEUE      The specified Calendar cannot be
614	                               contacted directly. The request or
615	                               reply will be queued and delivered to
616	                               the target calendar when its IRIP
617	                               server contacts this server and issues
618	                               the SWITCH command.

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

625	2.0.7  QUEUED                  The request or reply has been queued
626	                               for delivery.

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

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

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

639	8.3    DATE TOO LARGE          A DATETIME value was too large to be
640	                               represented on this Calendar.

642	Courtemanche/Mansour/O'Leary       11                    Expires: May 1999
643	8.4    DATE TOO SMALL          A DATETIME value was too far in the
644	                               past to be represented on this
645	                               Calendar.

647	9.0    INVALID IRIP COMMAND    An unrecongnized command was received.

649	10.1   REFERRAL                Accompanied by an alternate address.
650	                               The RECIPIENT specified should be
651	                               contacted at the given alternate
652	                               address. The referral address MUST
653	                               follow the reply code.

655	10.2   SERVER SHUT DOWN        The server is shutting down.

657	10.3   SERVER STOPPING FLOOD

659	10.4   EXCEEDED QUOTAS

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

664	4 Implementation Considerations

666	It is strongly recommended that when an IRIP implementation encounters
667	an error requiring the communication channel between the Sender and
668	Receiver to be dropped that the DISCONNECT command be issued rather
669	than simply breaking the communication channel.

671	[Editors note: What is the expectation for calstore recipients that
672	don't exist on this server?]

674	5 Security Considerations

676	The security of [IRIP] with [SASL] support is highly dependent on the
677	mechanism used to authenticate the client and whether or not the
678	security layer is further negotiated. Without a robust security layer,
679	[IRIP] transactions are subject to eavesdropping and the integrity of
680	[IRIP] transactions may be compromised. Since [IRIP] is designed
681	specifically for real time Internet transactions, it is recommended
682	that implementations use the highest degree of authentication and
683	transmission security possible.

685	Authentication is fundamental to [IRIP]. It is the basis for granting
686	and denying access. Without a robust security layer [IRIP] will be
687	subject to many possible attacks and the full contents of the server
688	itself may be at risk.

690	5.1 SASL ANONYMOUS Mechanism

692	Implementing support for the Anonymous [SASL] significantly increases
693	the vulnerability of the calendar server and its data. Refer to
694	[ANON-SASL] for further information on many threats specific to
695	Anonymous [SASL] access.

697	5.2 SASL Profile Definition for the protocol

699	The implementation of [SASL] in [IRIP] requires the server and client

701	Courtemanche/Mansour/O'Leary       12                    Expires: May 1999
702	to comply with the following profile extension:

704	-  AUTHENTICATE command.
705	-  Full description of the challenge/response definition.
706	-  Starting octet.
707	-  Authorization identity supplied by the sender must the one used to
708	   grant or denied the requested operation.

710	5.3 Security Threats

712	5.3.1 Eavesdropping

714	If [SASL] is used to negotiate a security layer with the server, then
715	traffic is no longer in the clear and eavesdropping will not be
716	restricted.

718	5.3.2 Connection Flooding

720	Connections that have not been authenticated within a configurable
721	number of seconds should be disconnected.

723	5.3.3 Denial of Service Attacks

725	[Editors note: need explanation and recommendation: ???]

727	6 Examples

729	6.1 Unauthenticated Freebusy Request

731	This examples shows an anonymous request for the freebusy time of
732	irip://cal.example.com/sman.  Note that once xyz is authenticated on
733	the irip server either the fully qualified IRIP CALID or the relative
734	CALID can be used to reference a Calendar.  That is,
735	"irip://cal.example.com/xyz" and "xyz" refer to the same calendar and
736	can be used interchangeably.

738	R: <listen on TCP port 5228>
739	S: <establish a TCP connection to cal.example.com port 5228>
740	R: 2.0
741	S: AUTHENTICATE ANONYMOUS xyz
742	R: 2.0
743	S: RECIPIENT:sman
744	R: 2.0
745	S: ICALDATA
746	R: 2.0.1
747	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
748	S: Content-Transfer-Encoding: 7bit
749	S:
750	S: BEGIN:VCALENDAR
751	S: PRODID:-//ACME/DesktopCalendar//EN
752	S: METHOD:REQUEST
753	S: VERSION:2.0
754	S: BEGIN:VFREEBUSY
755	S: ORGANIZER:xyz
756	S: ATTENDEE:sman
757	S: DTSTAMP:19971113T190000Z
758	S: DTSTART:19971115T160000Z
759	S: DTEND:19971116T040000Z
760	S: UID:www.example.com-873970198738777@host.com

762	Courtemanche/Mansour/O'Leary       13                    Expires: May 1999
763	S: END:VFREEBUSY
764	S: END:VCALENDAR
765	S: .

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

769	R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
770	R: Content-Transfer-Encoding: 7bit
771	R:
772	R: BEGIN:VCALENDAR
773	R: PRODID:-//EXAMPLE/DesktopCalendar//EN
774	R: METHOD:REPLY
775	R: VERSION:2.0
776	R: BEGIN:VFREEBUSY
777	S: ORGANIZER:irip://cal.example.com/xyz
778	R: ATTENDEE:irip://cal.example.com/sman
779	R: DTSTAMP:19971113T190005Z
780	R: DTSTART:19971115T160000Z
781	R: DTEND:19971116T040000Z
782	R: UID:www.example.com-873970198738777@host.com
783	R: FREEBUSY:19971113T230000Z/PT1H,19971114T210000Z/PT30M
784	R: END:VFREEBUSY
785	R: END:VCALENDAR
786	R: .
787	R: sman 2.0
788	R: .
789	S: DISCONNECT
790	R: 2.0
791	R: <disconnect>
792	S: <disconnect>

794	6.2 Using Switch

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

800	R: <listen on TCP port 5228>
801	S: <establish a connection to TCP port 5228>
802	R: 2.0
803	S: AUTHENTICATE KERBEROS_V4 93407205
804	S: <more authentication information>
805	R: 2.0
806	S: SWITCH
807	R: 2.0
808	<sender now becomes the receiver>
809	S: 2.0
810	R: AUTHENTICATE KERBEROS_V4  27367ao986pq8u98u9e8w0-0--0--0werg
811	S: 2.0
812	<receiver can now authenticate and send anything pending for the
813	sender>

815	6.3 Queued Requests

817	In the diagram below, sender S has authenticated to the IRIP server
818	B.foo.com.  C.foobar.com, D.bar.com, and E.barfoo.com all have IRIP
819	servers. B has a trusted relationship with both C and D. A firewall is
820	in place that prohibits B from initiating a connection to D. However, D

822	Courtemanche/Mansour/O'Leary       14                    Expires: May 1999
823	can connect to B.

825	                                  +--------------+
826	                           +------| C.foobar.com |
827	                           |      +--------------+
828	                           |
829	            +-----------+  |      +-----------+
830	 S ---------| B.foo.com |------#--| D.bar.com |
831	            +-----------+  |      +-----------+
832	                           |
833	                           |      +--------------+
834	                           +------| E.barfoo.com |
835	                                  +--------------+
836	6.3.1 Meeting Invitation

838	In this example, S sends an event request to the IRIP server on B for
839	calendars on B, C, D, and E.

841	R: <listen on TCP port 5228>
842	S: <establish a TCP connection to b.foo.com port 5228>
843	R: 2.0
844	S: AUTHENTICATE KERBEROS_V4 93407205
845	S: <more authentication information>
846	R: 2.0
847	S: RECIPIENT:irip://B.foo.com/bill
848	R: 2.0
849	S: RECIPIENT:irip://C.foobar.com/cathy
850	R: 2.0.4
851	S: RECIPIENT:irip://D.bar.com/david
852	R: 2.0.5
853	S: RECIPIENT:irip://E.barfoo.com/eddie
854	R: 2.0.6
855	S: ICALDATA: 16
856	R: 2.0.1
857	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
858	S: Content-Transfer-Encoding: 7bit
859	S:
860	S: BEGIN:VCALENDAR
861	S: PRODID:-//ACME/DesktopCalendar//EN
862	S: METHOD:REQUEST
863	S: VERSION:2.0
864	S: BEGIN:VEVENT
865	S: ORGANIZER:irip://B.foo.com/bill
866	S: ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:irip://B.foo.com/bill
867	S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://C.foobar.com/cathy
868	S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://D.bar.com/david
869	S: ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:irip://E.barfoo.com/eddie
870	S: DTSTAMP:19981011T190000Z
871	S: DTSTART:19981101T200000Z
872	S: DTEND:19981101T2100000Z
873	S: SUMMARY:Conference
874	S: UID:calsrv.example.com-873970198738777@example.com
875	S: SEQUENCE:0
876	S: STATUS:CONFIRMED
877	S: END:VEVENT
878	S: END:VCALENDAR
879	S: .
880	R: .
881	R: irip://B.foo.com/bill 2.0

883	Courtemanche/Mansour/O'Leary       15                    Expires: May 1999
884	R: irip://C.foobar.com/cathy 2.0
885	R: irip://D.bar.com/david 2.0.7
886	R: irip://E.barfoo.com/eddie 2.0
887	S: DISCONNECT
888	R: 2.0
889	R: <disconnect>
890	S: <disconnect>

892	The invitation is written to the calendar B.foo.com/bill. IRIP server
893	B.foo.com authenticates to C.foobar.com and sends the event request,
894	which is successfully written to C.foobar.com/cathy. The IRIP server on
895	B.foo.com cannot contact D.bar.com, but a trust relationship exists
896	between them and the request is queued for delivery. This request will
897	be delivered the next time the IRIP server on D.bar.com connects to the
898	IRIP server on B.foo.com and issues a SWITCH command. The IRIP server
899	on B.foo.com connects to the IRIP server on E.barfoo.com and
900	authenticates as anonymous since it has no trust relationship with
901	E.barfoo.com. If the anonymous authentication is successful, the event
902	request is delivered to E.barfoo.com/eddie.

904	[Editors note: in the case of the anonymous authentication, B could
905	also provide E with the same credentials as S provided to B]

907	6.3.2 Busy Time Request

909	In this example, the sender S sends a Freebusy request to B for
910	calendars on B, C, D, and E. S needs the information immediately and
911	will abort any attempt to queue requests.

913	R: <listen on TCP port 5228>
914	S: <establish a TCP connection to cal.example.com port 5228>
915	R: 2.0
916	S: AUTHENTICATE KERBEROS_V4 93407205
917	S: <more authentication information>
918	R: 2.0
919	S: RECIPIENT:irip://B.foo.com/bill
920	R: 2.0
921	S: RECIPIENT:irip://C.foobar.com/cathy
922	R: 2.0.4
923	S: RECIPIENT:irip://D.bar.com/david
924	R: 2.0.5
925	S: RECIPIENT:irip://E.barfoo.com/eddie
926	R: 2.0.6

928	<the sender cannot accept a queued request and response. The
929	 current operation will be canceled. The operation will be tried
930	 again with all attendees that have requests queued dropped from the
931	 RECIPIENT list...>

933	S: ABORT
934	R: 2.0.3
935	S: RECIPIENT:irip://B.foo.com/bill
936	R: 2.0
937	S: RECIPIENT:irip://C.foobar.com/cathy
938	R: 2.0.4
939	S: RECIPIENT:irip://E.barfoo.com/eddie
940	R: 2.0.6
941	S: ICALDATA
942	R: 2.0.1

944	Courtemanche/Mansour/O'Leary       16                    Expires: May 1999
945	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
946	S: Content-Transfer-Encoding: 7bit
947	S:
948	S: BEGIN:VCALENDAR
949	S: PRODID:-//ACME/DesktopCalendar//EN
950	S: METHOD:REQUEST
951	S: VERSION:2.0
952	S: BEGIN:VFREEBUSY
953	S: ORGANIZER:irip://B.foo.com/bill
954	S: ATTENDEE:irip://B.foo.com/bill
955	S: ATTENDEE:irip://C.foobar.com/cathy
956	S: ATTENDEE:irip://D.bar.com/david
957	S: ATTENDEE:irip://E.barfoo.com/eddie
958	S: DTSTAMP:19971113T190000Z
959	S: DTSTART:19971115T160000Z
960	S: DTEND:19971116T040000Z
961	S: UID:www.example.com-873970198738777@host.com
962	S: END:VFREEBUSY
963	S: END:VCALENDAR
964	S: .

966	<server looks up the freebusy time for B.foo.com/bill,
967	 requests and receives the freebusy time for
968	 irip://C.foobar.com/cathy and irip://E.barfoo.com/eddie. Then it
969	 builds a reply>

971	R: Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"
972	R:
973	R: This is a multi-part message in MIME format.
974	R:
975	R:----FEE3790DC7E35189CA67CE2C
976	R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
977	R: Content-Transfer-Encoding: 7bit
978	R:
979	R: BEGIN:VCALENDAR
980	R: PRODID:-//EXAMPLE/DesktopCalendar//EN
981	R: METHOD:REPLY
982	R: VERSION:2.0
983	R: BEGIN:VFREEBUSY
984	S: ORGANIZER:irip://B.foo.com/bill
985	R: ATTENDEE:irip://B.foo.com/bill
986	R: DTSTAMP:19971113T190005Z
987	R: DTSTART:19971115T160000Z
988	R: DTEND:19971116T040000Z
989	R: UID:www.example.com-873970198738777@host.com
990	R: FREEBUSY:19971115T200000Z/PT1H,19971116T170000Z/PT30M
991	R: END:VFREEBUSY
992	R: END:VCALENDAR
993	R:
994	R:----FEE3790DC7E35189CA67CE2C
995	R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
996	R: Content-Transfer-Encoding: 7bit
997	R:
998	R: BEGIN:VCALENDAR
999	R: PRODID:-//EXAMPLE/DesktopCalendar//EN
1000	R: METHOD:REPLY
1001	R: VERSION:2.0
1002	R: BEGIN:VFREEBUSY
1003	S: ORGANIZER:irip://B.foo.com/bill

1005	Courtemanche/Mansour/O'Leary       17                    Expires: May 1999
1006	R: ATTENDEE:irip://C.foobar.com/cathy
1007	R: DTSTAMP:19971113T190005Z
1008	R: DTSTART:19971115T160000Z
1009	R: DTEND:19971116T040000Z
1010	R: UID:www.example.com-873970198738777@host.com
1011	R: FREEBUSY:19971115T230000Z/PT1H,19971116T210000Z/PT30M
1012	R: END:VFREEBUSY
1013	R: END:VCALENDAR
1014	R:
1015	R:----FEE3790DC7E35189CA67CE2C
1016	R: Content-Type:text/calendar; method=REPLY; charset=US-ASCII
1017	R: Content-Transfer-Encoding: 7bit
1018	R:
1019	R: BEGIN:VCALENDAR
1020	R: PRODID:-//EXAMPLE/DesktopCalendar//EN
1021	R: METHOD:REPLY
1022	R: VERSION:2.0
1023	R: BEGIN:VFREEBUSY
1024	S: ORGANIZER:irip://B.foo.com/bill
1025	R: ATTENDEE:irip://E.barfoo.com/eddie
1026	R: DTSTAMP:19971113T190005Z
1027	R: DTSTART:19971115T160000Z
1028	R: DTEND:19971116T040000Z
1029	R: UID:www.example.com-873970198738777@host.com
1030	R: FREEBUSY:19971115T230000Z/PT1H,19971116T210000Z/PT30M
1031	R: END:VFREEBUSY
1032	R: END:VCALENDAR
1033	R:
1034	R:----FEE3790DC7E35189CA67CE2C
1035	R: .
1036	R: irip://B.foo.com/bill 2.0
1037	R: irip://C.foobar.com/cathy 2.0
1038	R: irip://E.barfoo.com/eddie 2.0
1039	S: DISCONNECT
1040	R: 2.0
1041	R: <disconnect>
1042	S: <disconnect>

1044	Since each reply is delivered immediately, the reply is sent as a
1045	Multipart/Mixed. Transport reply codes for each recipient are returned
1046	after the Multipart/Mixed data.

1048	6.4 Resource Scheduling

1050	R: <listen on TCP port 5228>
1051	S: <connect to port 5228>
1052	R: 2.0
1053	S: AUTHENTICATE KERBEROS_V4 7SF8S3&#
1054	S: <more authentication information>
1055	R: 2.0
1056	S: RECIPIENT Large_Conference_Room
1057	R: 2.0
1058	S: RECIPIENT Overhead_Projector_1
1059	R: 2.0
1060	S: ICALDATA: 10
1061	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
1062	S: Content-Transfer-Encoding: 7bit
1063	S:
1064	S: BEGIN:VCALENDAR

1066	Courtemanche/Mansour/O'Leary       18                    Expires: May 1999
1067	S: PRODID:-//Foo Corporation//Inlet MIMEDIR//EN
1068	S: VERSION:2.0
1069	S: METHOD:REQUEST
1070	S: BEGIN:VEVENT
1071	S: ORGANIZER:irip://cal.example.com/xyz
1072	S: ATTENDEE:irip://cal.example.com/Large_Conference_Room
1073	S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1
1074	S: DTSTART:19980706T190000Z
1075	S: DTEND:19980706T203000Z
1076	S: LOCATION:Large Conference Room
1077	S: DESCRIPTION:Big customer meeting in Large Conference room.
1078	S: SUMMARY:Customer meeting
1079	S: PRIORITY:1
1080	S: END:VEVENT
1081	S: END:VCALENDAR
1082	S: .
1083	R: <looks up availability in database>
1084	R: .
1085	R: 2.0 Large_Conference_Room
1086	R: 2.0 Overhead_Projector_1
1087	S: RECIPIENT Large_Conference_Room
1088	R: 2.0
1089	S: RECIPIENT Overhead_Projector_1
1090	R: 2.0
1091	S: ICALDATA: 10
1092	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
1093	S: Content-Transfer-Encoding: 7bit
1094	S:
1095	S: BEGIN:VCALENDAR
1096	S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN
1097	S: VERSION:2.0
1098	S: METHOD:REQUEST
1099	S: BEGIN:VEVENT
1100	S: ORGANIZER:irip://cal.example.com/xyz
1101	S: ATTENDEE:irip://cal.example.com/Large_Conference_Room
1102	S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1
1103	S: DTSTART:19980708T220000Z
1104	S: DTEND:19980708T230000Z
1105	S: LOCATION:Large Conference Room
1106	S: DESCRIPTION:Another big customer meeting in Large Conference room.
1107	S: SUMMARY:Customer meeting
1108	S: PRIORITY:1
1109	S: END:VEVENT
1110	S: END:VCALENDAR
1111	S: .
1112	R: <looks up availability in database>
1113	R: .
1114	< Large_Conference_Room not available, thus the response code is...>
1115	R: 4.0
1116	S: RECIPIENT Large_Conference_Room
1117	R: 2.0
1118	S: RECIPIENT Overhead_Projector_1
1119	R: 2.0
1120	S: ICALDATA: 10
1121	S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
1122	S: Content-Transfer-Encoding: 7bit
1123	S:
1124	S: BEGIN:VCALENDAR
1125	S: PRODID:-//Foo Corporation//Insight MIMEDIR//EN

1127	Courtemanche/Mansour/O'Leary       19                    Expires: May 1999
1128	S: VERSION:2.0
1129	S: METHOD:REQUEST
1130	S: BEGIN:VEVENT
1131	S: ORGANIZER:irip://cal.example.com/xyz
1132	S: ATTENDEE:irip://cal.example.com/Large_Conference_Room
1133	S: ATTENDEE:irip://cal.example.com/Overhead_Projector_1
1134	S: DTSTART:19980708T160000Z
1135	S: DTEND:19980708T170000Z
1136	S: LOCATION:Large Conference Room
1137	S: DESCRIPTION:Another big customer meeting in Large Conference room.
1138	S: SUMMARY:Customer meeting
1139	S: PRIORITY:1
1140	S: END:VEVENT
1141	S: END:VCALENDAR
1142	S: .
1143	R: <looks up availability in database>
1144	<10 seconds pass>
1145	R: .
1146	<Database too busy, thus the response code is...>
1147	R: 2.0.2
1148	S: ABORT
1149	R: 2.0
1150	S: DISCONNECT
1151	R: 2.0
1152	R: <drops TCP connection>

1154	7 Acknowledgments

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

1159	Bruce Kahn, Doug Royer, Mugino Saeki

1161	8 Bibliography

1163	[ ICAL] "Internet Calendaring and Scheduling Core Object Specification
1164	- iCalendar", Internet-Draft, July 1997,
1165	ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-10.txt.

1167	[ICMS] "Internet Calendaring Model Specification", Internet-Draft, July
1168	1997, ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-mod-00.txt.

1170	[ITIP] "iCalendar Transport-Independent Interoperability Protocol
1171	(iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries ",
1172	Internet-Draft, October 1997,
1173	http://www.imc.org/draft-ietf-calsch-itip-06.txt.

1175	[IMIP] "iCalendar Message-based Interoperability Protocol (iMIP),
1176	Internet-Draft, October 1997,
1177	http://www.imc.org/draft-ietf-calsch-imip-05.txt.

1179	[ID-UTF8] "UTF-8, a transformation format of Unicode and ISO 10646",
1180	Internet-Draft, July,1996,
1181	ftp://ftp.ietf.org/internet-drafts/draft-yergeau-utf8-01.txt.

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

1186	[RFC-1847]. J. Galvin, S. Murphy, S. Crocker & N. Freed, "Security

1188	Courtemanche/Mansour/O'Leary       20                    Expires: May 1999
1189	Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC
1190	1847, October 1995.

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

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

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

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

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

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

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

1216	9 Open Issues

1218	Registration of the [SASL] profile for [IRIP] with the IANA.
1219	Port Number registration
1220	10 Author's Address

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

1225	BEGIN:VCARD
1226	FN:Andre Courtemanche
1227	ORG:CS&T
1228	ADR;WORK;POSTAL;PARCEL:;;3333 Graham Boulevard;Montreal;QC;H3R
1229	3L5;Canada

1231	TEL;WORK;MSG:+1-514-733-8500
1232	TEL;WORK;FAX:+1-514-733-8788
1233	EMAIL;INTERNET:andre@cst.ca
1234	END:VCARD

1236	BEGIN:VCARD
1237	VERSION:2.1
1238	FN:Steve Mansour
1239	ORG:Netscape Communications Corporation
1240	ADR;WORK;POSTAL;PARCEL:;;501 East Middlefield Road;Mountain
1241	  View;CA;94043;USA
1242	TEL;WORK;MSG:+1-650-937-2378
1243	TEL;WORK;FAX:+1-650-937-2103
1244	EMAIL;INTERNET:sman@netscape.com
1245	END:VCARD

1247	Courtemanche/Mansour/O'Leary       21                    Expires: May 1999
1248	BEGIN:VCARD
1249	FN:Pete O'Leary
1250	ORG:Amplitude
1251	ADR;WORK;POSTAL;PARCEL:;;
1252	TEL;WORK;MSG:+1-415-659-3511
1253	TEL;WORK;FAX:+1-415-659-0006
1254	EMAIL;INTERNET:pete@amplitude.com
1255	END:VCARD

1257	The iCalendar object is a result of the work of the Internet
1258	Engineering Task Force Calendaring and scheduling Working Group. The
1259	chairman of that working group is:

1261	BEGIN:VCARD
1262	FN:Anik Ganguly
1263	ORG:Open Text, Inc.
1264	ADR;WORK;POSTAL;PARCEL:;;38777 West Six Mile Road Suite 101;
1265	    Livonia;MI;48152;USA
1266	TEL;WORK;MSG:+1-734-542-5955
1267	EMAIL;INTERNET:ganguly@acm.org
1268	END:VCARD

1270	The co-chairman of that working group is:

1272	BEGIN:VCARD
1273	VERSION:2.1
1274	FN:Robert Moskowitz
1275	EMAIL;INTERNET: rgm-ietf@htt-consult.com
1276	END:VCARD

1278	11 Full Copyright Statement

1280	"Copyright (C) The Internet Society (date).  All Rights Reserved.

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

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

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

1305	Courtemanche/Mansour/O'Leary       22                    Expires: May 1999