Network Working Group M. Rose Internet-Draft Dover Beach Consulting, Inc. Expires: June 23, 2002 December 23, 2001 IM Simple Exchange (IMSX) draft-mrose-simple-exchange-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 23, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The Common Presence and Instant Messaging profile (CPIM) is a set of syntax and semantics for instant messaging (IM) and online presence services, independent of the underlying transfer infrastructure. The Session Initiation Protocol (SIP) negotiates session information for media streams. This memo defines a BEEP profile, IMSX, for exchanging CPIM messages after SIP has performed signalling. Rose Expires June 23, 2002 [Page 1] Internet-Draft IM Simple Exchange (IMSX) December 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IM Simple Exchange . . . . . . . . . . . . . . . . . . . . . 4 2.1 The Session Model . . . . . . . . . . . . . . . . . . . . . 4 2.2 SDP Announcements for IMSX . . . . . . . . . . . . . . . . . 6 2.3 SIP Interactions for IMSX . . . . . . . . . . . . . . . . . 7 2.4 BEEP Interactions for IMSX . . . . . . . . . . . . . . . . . 7 2.5 Putting It All Together . . . . . . . . . . . . . . . . . . 8 3. The IMSX Profile for BEEP . . . . . . . . . . . . . . . . . 13 3.1 Use of XML and MIME . . . . . . . . . . . . . . . . . . . . 13 3.2 Profile Identification and Initialization . . . . . . . . . 14 3.3 Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 Message Semantics . . . . . . . . . . . . . . . . . . . . . 15 3.4.1 The Message Element . . . . . . . . . . . . . . . . . . . . 15 3.4.2 The Response Element . . . . . . . . . . . . . . . . . . . . 16 4. Initial Registrations . . . . . . . . . . . . . . . . . . . 17 4.1 Registration: The IMSX Profile . . . . . . . . . . . . . . . 17 4.2 Registration: The System (Well-Known) TCP port number for IMSX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 Registration: The IMSX/TCP "proto" for SDP . . . . . . . . . 18 4.4 Registration: The tuning "att-field" for SDP . . . . . . . . 18 5. The IMSX DTD . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 26 Full Copyright Statement . . . . . . . . . . . . . . . . . . 27 Rose Expires June 23, 2002 [Page 2] Internet-Draft IM Simple Exchange (IMSX) December 2001 1. Introduction The Common Presence and Instant Messaging profile [1] (CPIM) is a set of syntax and semantics for instant messaging (IM) and online presence services, independent of the underlying transfer infrastructure. CPIM is consistent with the requirements specified in RFC2779 [2], using a minimalist approach to allow the interoperation of a wide range of IM and presence systems. To support a "paging" model for IM, SIMPLE [3] defines an extension to the Session Initiation Protocol [4] (SIP). SIP negotiates session information for media streams. Using the SIMPLE extention, the IM content is piggyback'd in the SIP traffic, thereby eliminating the need for a separate stream for IM traffic. A "session" model for IM is also possible, wherein SIP performs the signalling necessary to negotiate the establishment of a media stream, which is realized by a second protocol. This memo defines an "IM session" protocol for that purpose, termed the IM Simple Exchange (IMSX). IMSX is realized as a BEEP profile [5]. This memo is written with the expectation that the reader is familiar with the concepts presented in the CPIM, SIP, and BEEP specifications. Rose Expires June 23, 2002 [Page 3] Internet-Draft IM Simple Exchange (IMSX) December 2001 2. IM Simple Exchange 2.1 The Session Model In the "session" model, an IM application determines that it wishes to communicate with another IM application. These applications, termed the initiating and responding applications (respectively), are conceptually identified using the IM URI, as specified in Section 5.1 of [1]. The initiating application determines that it will use IMSX to communicate with the responding application, so it uses the SIP URI for this purpose. For example, if the IM application uses IMSX to communicate with an IM application identified as "im:barney@rubble.com" , the URI "sip:barney@rubble.com" is utilized for this purpose. The initiating application ensures that it is running a BEEP entity that implements the IMSX profile, and determines the transport information associated with the BEEP entity (typically IP address and TCP port number). Then it constructs an announcement using the Session Description Protocol [6] (SDP), and sends the announcement in a SIP INVITE. The initiating application then waits for a response. Ultimately, the responding application receives the invitation. The responding application determines if it wishes to communicate with the initiating application. If the invitation is declined, this is indicated a failure response code (from the 4xx, 5xx or 6xx series) and no further actions are taken by the responding application. Otherwise, the responding application ensures that it is running a BEEP entity that implements the IMSX profile, determines the transport information associated with the BEEP entity (typically IP address and TCP port number), and then sends its own announcement with a 200 response code. Ultimately, the initiating application receives the response and acknowledges it with a SIP ACK message. If the response indicates failure, no further actions are taken by the initiating application. Otherwise, the initiating application activates its BEEP entity, and, using the transport information in the response, establishes a BEEP session. If successful, the initiating appliation tunes the session as appropriate, and starts the IMSX profile. As with any model based on dynamic rendezvous, it is critically important that each application faithfully record the appropriate transport information in the corresponding SDP announcement. Rose Expires June 23, 2002 [Page 4] Internet-Draft IM Simple Exchange (IMSX) December 2001 Note that with the introduction of middleboxes [7], such as firewalls and network address translators, it may be necessary for proxies to transparently rewrite the transport information in order to account for administratively-mandated media gateways or address translation. In a phrase, "res ipsa loquitur". Rose Expires June 23, 2002 [Page 5] Internet-Draft IM Simple Exchange (IMSX) December 2001 2.2 SDP Announcements for IMSX Consider this SDP announcement: v=0 o=fred 2890844526 0 IN IP4 1.2.3.4 s=example imsx session c=IN IP4 1.2.3.4 t=0 0 m=message 1024 IMSX/TCP cpim a=tuning:privacy Readers familiar with SDP will note only two new parameters, the use of "IMSX/TCP" as a media protocol, and the use of "tuning" as an attribute. For readers less familiar with SDP, let's examine all the information conveyed by this announcement: v=0 => The announcement conforms to version "0" of SDP. o=fred => The originator of the session. o= ... 2890844526 ... IN IP4 1.2.3.4 => The unique identification of the session. o= ... 0 ... => The instance-identifier for the session. s=example imsx session => The textual name of the session. c=IN IP4 1.2.3.4 / m= ... 1024 .../TCP => The transport information associated with the application's BEEP entity. t=0 0 => The (unbounded) start and stop times of the session. m=message ... cpim => The media type being advertised (in this case "message/cpim" [8]). m=message ... IMSX/TCP ... => The protocol used to realize the media stream (cf., Section 4.3). a=tuning:privacy => The BEEP session must be tuned for privacy before starting the IMSX profile (cf., Section 4.4). Rose Expires June 23, 2002 [Page 6] Internet-Draft IM Simple Exchange (IMSX) December 2001 2.3 SIP Interactions for IMSX The mechanisms defined in [4] are used directly, no changes to the SIP interaction model is required for IMSX. 2.4 BEEP Interactions for IMSX Although the SDP announcement indicates what the desired tuning for the BEEP session, the "greetings" exchanged by the BEEP peers indicate which tuning profiles are available: a=tuning:privacy If tuning for privacy is requested, then the initiating application examines the profiles advertised in the responding application's greeting to see which is most appropriate. This may be either: * a transport security profile; or, * a user authentication profile that also supports transport privacy. a=tuning:integrity If tuning for message integrity is requested, then the initiating application examines the profiles advertised in the responding application's greeting to see which is most appropriate, i.e., a user authentication profile that also supports message integrity. a=tuning:authentication If tuning for user authentication is requested, then the initiating application examines the profiles advertised in the responding application's greeting to see which is most appropriate. a=tuning:all If tuning for user authentication, message integrity, and privacy is requested, then the initiating application examines the profiles advertised in the responding application's greeting to see which are most appropriate. These may be either: * a transport security profile supporting bi-directional certification; * a user authentication profile that also supports transport privacy; or, * a transport security profile followed by a user authentication profile. Rose Expires June 23, 2002 [Page 7] Internet-Draft IM Simple Exchange (IMSX) December 2001 2.5 Putting It All Together The IM application known as "im:fred@example.com" determines that it wishes to communicate with the IM application known as "im:barney@example.com". The initiating application ensures that it is running a BEEP entity that implements the IMSX profile, and determines that its BEEP entity is using IP address "1.2.3.4" and TCP port "1024". It then sends a session invitation to the "sip.rubble.com" proxy. The invitation looks something like this: INVITE sip:barney@rubble.com SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4 From: Fred ;tag=5567 To: Barney Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: 166 v=0 o=fred 2890844526 0 IN IP4 1.2.3.4 s=example imsx session c=IN IP4 1.2.3.4 t=0 0 m=message 1024 IMSX/TCP cpim a=tuning:none The initiating application then waits for a response. Rose Expires June 23, 2002 [Page 8] Internet-Draft IM Simple Exchange (IMSX) December 2001 The "sip.rubble.com" proxy forwards the session invitation to the responding application. The responding application ensures that it is running a BEEP entity that implements the IMSX profile, and determines that its BEEP entity is using IP address "5.6.7.8" and TCP port "65535". It then sends its response, which looks something like this, back to the SIP proxy: SIP/2.0 200 OK Via: SIP/2.0/UDP sip.rubble.com Via: SIP/2.0/UDP 1.2.3.4 From: Fred ;tag=5567 To: Barney ;tag=998a87 Call-ID: 283e0@1.2.3.4 CSeq: 98770 INVITE Content-Type: application/sdp Content-Length: 166 v=0 o=fred 2890844526 0 IN IP4 5.6.7.8 s=example imsx session c=IN IP4 5.6.7.8 t=0 0 m=message 65535 IMSX/TCP cpim a=tuning:privacy The responding appliation then waits for an incoming BEEP session. Ultimately, the initiating application receives the response to the session invitation. The initiating application acknowledges the response, and then establishes a BEEP session using TCP from port "1024" on IP address "1.2.3.4" to port "65535" on IP address "5.6.7.8". Rose Expires June 23, 2002 [Page 9] Internet-Draft IM Simple Exchange (IMSX) December 2001 The BEEP peers begin with the traditional exchange of greetings (in resplendent native costume): L: I: L: RPY 0 0 . 0 285 L: Content-Type: application/beep+xml L: L: L: L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END Rose Expires June 23, 2002 [Page 10] Internet-Draft IM Simple Exchange (IMSX) December 2001 Because the responding application's response indicated that tuning for privacy is necessary, the initiating application starts a transport security profile: I: MSG 0 1 . 52 158 I: Content-Type: application/beep+xml I: I: I: I: ]]> I: I: I: END L: RPY 0 1 . 285 121 L: Content-Type: application/beep+xml L: L: L: ]]> L: L: END ... successful transport security negotiation ... L: RPY 0 0 . 0 238 L: Content-Type: application/beep+xml L: L: L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: I: END Rose Expires June 23, 2002 [Page 11] Internet-Draft IM Simple Exchange (IMSX) December 2001 With the session tuned, the initiating application starts the IMSX profile for BEEP: I: MSG 0 1 . 52 176 I: Content-Type: application/beep+xml I: I: I: I: I: END L: RPY 0 1 . 238 138 L: Content-Type: application/beep+xml L: L: L: END Rose Expires June 23, 2002 [Page 12] Internet-Draft IM Simple Exchange (IMSX) December 2001 3. The IMSX Profile for BEEP Section 4.1 contains the BEEP profile registration for IMSX. 3.1 Use of XML and MIME Each BEEP payload exchanged via IMSX consists of an XML document and possibly an arbitrary MIME content. If only an XML document is sent in the BEEP payload, then the mapping to a BEEP payload is straight-forward, e.g., S: RPY 1 0 . 0 81 S: Content-Type: application/beep+xml S: S: S: END Otherwise, if an arbitrary MIME content is present, it is indicated by a URI-reference [9] in the XML control document. The URI- reference may contain an absolute-URI (and possibly a fragment- identifier), or it may be a relative-URI consisting only of a fragment-identifier. Arbitrary MIME content is included in the BEEP payload by using a "multipart/related" [10], identified using a "cid" URL [11], and the XML control document occurs as the start of the "multipart/related", e.g., C: MSG 1 0 . 0 1234 C: Content-Type: multipart/related; boundary='boundary'; C: start='<1@example.com>'; C: type='application/beep+xml' C: C: --boundary C: Content-Type: application/beep+xml C: Content-ID: <1@example.com> C: C: C: --boundary C: Content-Type: message/cpim C: Content-Transfer-Encoding: binary C: Content-ID: <2@example.com> C: C: ... C: --boundary-- C: END Rose Expires June 23, 2002 [Page 13] Internet-Draft IM Simple Exchange (IMSX) December 2001 Because BEEP provides an 8bit-wide path, a "transformative" Content- Transfer-Encoding (e.g., "base64" or "quoted-printable") should not be used. Further, note that MIME [12] requires that the value of the "Content-ID" header be globally unique. If the arbitrary MIME content is itself an XML document, it may be contained within the control document directly as a "data-content" element, and identified using a URI-reference consisting of only a fragment-identifier, e.g., C: MSG 1 0 . 0 1234 C: Content-Type: application/beep+xml C: C: C: C: ... C: C: C: END 3.2 Profile Identification and Initialization The IMSX is identified as: http://iana.org/beep/transient/simple/imsx in the BEEP "profile" element during channel creation. No elements are required to be exchanged during channel creation; however, the initiator may choose to piggyback its first operation, e.g., ... ]]> Note that Section 2.3.1.2 of [5] limits the amount of piggyback'd data to 4K octets. Rose Expires June 23, 2002 [Page 14] Internet-Draft IM Simple Exchange (IMSX) December 2001 3.3 Message Syntax Sections 6 and 7 of [1] define the abstract syntax for CPIM messaging. Accordingly, Section 5 defines the IMSX payloads that are CPIM-conformant. 3.4 Message Semantics Section 2.4 of [1] defines the abstract semantics for the communications between an application and the IM service. In contrast, IMSX is concerned with the semantics for the communications between two IM applications. Accordingly, the remainder of this section, while similar in nature to CPIM's behavior, deals solely with IM exchanges between end-users. 3.4.1 The Message Element The "message" element has a "source" attribute, a "destination" attribute, a "content" attribute, and, optionally, a "data-content" element: o the "source" attribute refers to the application sending the message, and contains an IM URI; o the "destination" attribute refers to the application receiving the message, and also contains an IM URI; and, o the "content" attribute is a URI-reference that specifies the contents of the data (cf., Section 3.1). Note that the "message" element does not contain SIP URIs -- the messages exchanged are independent of the fact that SIP is used to negotiate the establishment of an IMSX media stream. When an application receives the "message" element: 1. It verifies that it corresponds to the identity specified in the "destination" attribute, if not, it returns a "response" element with the "status" attribute set to "failure", and performs no further processing for that element. 2. Otherwise, it returns a "response" element with the "status" attribute set to "success", and performs any further processing in an application-specific manner. Rose Expires June 23, 2002 [Page 15] Internet-Draft IM Simple Exchange (IMSX) December 2001 3.4.2 The Response Element The "response" element has a "status" attribute, an optional "xml:lang" attribute, and may contain arbitrary textual content: o the "status" element is either "success", "failure", or "indeterminant"; and, o the "xml:lang" attribute, if present, specifies the language that the element's content is written in; and, o the textual content is a diagnostic (possibly multiline) which is meaningful to implementers, perhaps administrators, and possibly even users. Rose Expires June 23, 2002 [Page 16] Internet-Draft IM Simple Exchange (IMSX) December 2001 4. Initial Registrations 4.1 Registration: The IMSX Profile Profile Identification: http://iana.org/beep/transient/simple/imsx Messages exchanged during Channel Creation: message, response Messages starting one-to-one exchanges: message Messages in positive replies: response Messages in negative replies: none Messages in one-to-many exchanges: none Message Syntax: cf., Section 5 Message Semantics: cf., Section 3.4 Contact Information: cf., the "Authors' Addresses" section of this memo 4.2 Registration: The System (Well-Known) TCP port number for IMSX Protocol Number: TCP Message Formats, Types, Opcodes, and Sequences: Section 5 Functions: Section 3.4 Use of Broadcast/Multicast: none Proposed Name: IM Simple Exchange Short name: imsx Contact Information: cf., the "Authors' Addresses" section of this memo Rose Expires June 23, 2002 [Page 17] Internet-Draft IM Simple Exchange (IMSX) December 2001 4.3 Registration: The IMSX/TCP "proto" for SDP SDP Parameter Type: proto Registered Name: IMSX/TCP Long-Form Name: The IMSX profile for BEEP running over TCP Description: cf., this memo Contact Information: cf., the "Authors' Addresses" section of this memo 4.4 Registration: The tuning "att-field" for SDP SDP Parameter Type: att-field Registered Name: tuning Long-Form Name: Tuning parameters for media streams implemented over BEEP Type of Attribute: Media level Possible Values of Attribute: "none", "authentication", "integrity", "privacy", or "all". Description: cf., Section 2.4 Contact Information: cf., the "Authors' Addresses" section of this memo Rose Expires June 23, 2002 [Page 18] Internet-Draft IM Simple Exchange (IMSX) December 2001 5. The IMSX DTD %IMCOMMON; Rose Expires June 23, 2002 [Page 19] Internet-Draft IM Simple Exchange (IMSX) December 2001 Rose Expires June 23, 2002 [Page 20] Internet-Draft IM Simple Exchange (IMSX) December 2001 6. Security Considerations Consult [1]'s Section 4 for a discussion of CPIM-specific security issues. In particular, note that If authentication or confidentiality of individial instant messages is desired, the "message/cpim" format [8] is designed for this purpose. Consult [2]'s Section 5 for a discussion of IM-specific security issues. Consult [4]'s Section 13 for a discussion of SIP-specific security issues. Consult [6]'s Section 7 for a discussion of SDP-specific security issues. Consult [5]'s Section 9 for a discussion of BEEP-specific security issues. Although use of the tuning attribute in the SDP announcement is a policy matter, At a minimum, all IMSX implementations must provide the following tuning profiles: tuning value profile -------------- ------------------------------------ authentication http://iana.org/beep/SASL/DIGEST-MD5 integrity http://iana.org/beep/SASL/DIGEST-MD5 privacy http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher all http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher and client-side certificates Rose Expires June 23, 2002 [Page 21] Internet-Draft IM Simple Exchange (IMSX) December 2001 References [1] Crocker, D., "Common Presence and Instant Messaging (CPIM)", draft-ietf-impp-cpim-02 (work in progress), November 2001. [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [3] Rosenberg, J., "SIP Extensions for Instant Messaging", draft- ietf-simple-im-01 (work in progress), July 2001. [4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [5] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [7] Rosenberg, J., Srisuresh, P., Molitor, A., Rayhan, A. and J. Kuthan, "Middlebox Communication Architecture and framework", draft-ietf-midcom-framework-06 (work in progress), December 2001. [8] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", draft-ietf-impp-cpim-msgfmt-04 (work in progress), November 2001. [9] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [10] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [11] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Rose Expires June 23, 2002 [Page 22] Internet-Draft IM Simple Exchange (IMSX) December 2001 Author's Address Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us Rose Expires June 23, 2002 [Page 23] Internet-Draft IM Simple Exchange (IMSX) December 2001 Appendix A. Acknowledgements The author gratefully acknowledge the contributions of: Jon Peterson. Rose Expires June 23, 2002 [Page 24] Internet-Draft IM Simple Exchange (IMSX) December 2001 Appendix B. IANA Considerations If the IESG approves this memo for publication, then the IANA registers the profile specified in Section 4.1, and selects an IANA- specific URI, e.g., http://iana.org/beep/imsx The IANA registers "imsx" as a TCP port number, as specified in Section 4.2. The IANA registers "IMSX/TCP" as a SDP "proto", as specified in Section 4.3. The IANA registers "tuning" as a SDP "att-field", as specified in Section 4.4. Rose Expires June 23, 2002 [Page 25] Internet-Draft IM Simple Exchange (IMSX) December 2001 Appendix C. Revision History Note to RFC editor: please remove this entire appendix, and the corresponding entries in the table of contents, prior to publication. tbd... Rose Expires June 23, 2002 [Page 26] Internet-Draft IM Simple Exchange (IMSX) December 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rose Expires June 23, 2002 [Page 27]