ENUM Working Group R. Shockey-editor INTERNET-DRAFT NeuStar Intended Status : Standards Track September 22, 2008 Expires: February 2009 IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata' draft-ietf-enum-cnam-08.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 February 22, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). R. Shockey - editor Expires February 2009 [Page 1] Internet-Draft CNAM Enumservice August 2008 Abstract This document registers the Enumservice 'pstndata' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new URI type 'pstndata:'. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future. Table of Contents 1. Introduction ........................................ 3 2. Protocol Design Considerations. ..................... 4 3. Definition of PSTN CNAM Data ........................ 4 4. The PSTNDATA URI .................................... 4 5. Enumservice Privacy Responses and Parameters ........ 5 6. Distribution of CNAM Data ........................... 6 7. Enumservice CNAM Response Examples .................. 6 8. Usage Considerations ................................ 7 9. Privacy Considerations .............................. 7 10. Security Considerations ............................ 8 11. IANA Considerations ................................ 9 11.1 IANA Enumservice Registration for "pstndata" with subtype "cnam"........................................ 9 11.2 IANA Registration Template for URI "pstndata:".. 10 11.3 Datatype Token Registry......................... 13 11.4 IANA Registration Template for datatype Token "cnam"............................................... 13 12. Normative References .............................. 14 13. Informative References ............................ 15 14. Acknowledgements .................................. 16 15. Author's Address .................................. 16 16. Full Copyright Statement .......................... 17 Requirements notation R. Shockey - editor Expires February 2009 [Page 2] Internet-Draft CNAM Enumservice August 2008 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [16]. 1. Introduction RFC 3761 (ENUM) [1] is a system that transforms E.164 numbers (The International Public Telecommunication Number Plan, ITU-T Recommendation E.164) [2] into domain names and then uses the Domain Name System (DNS), RFC 1034 [3] and Naming Authority Pointer Records (NAPTR) records in the Dynamic Delegation Discovery System (DDDS) RFC 3403 [4]) to query the services that are available for a specific domain name. This document registers an Enumservice 'cnam' according to the guidelines given in RFC 3761 [1], to be used for provisioning a NAPTR [4] resource record to indicate a type of functionality associated with an end point and/or telephone number. The registration is defined within the DDDS (Dynamic Delegation Discovery System [4][5][6][7][8]) hierarchy, for use with the "E2U" DDDS Application defined in RFC 3761. This document also registers an IANA URI type 'pstndata' per the requirements of RFC 4395[15]. The purpose of this Enumservice is to enable service providers to place Calling Name Delivery information (CNAM) into ENUM databases or to send ENUM queries to a protocol converter that would have access to the Signaling System 7 (SS7) Network. This, in turn, could enable such parties to offer Calling Name Delivery services using the technology provided by RFC 3761 [1]. The service parameters defined in RFC 3761 [1] dictate that a 'type' and one or more 'subtype' should be specified. Within this set of specifications the convention is assumed that the 'type' (being the more generic term) defines the service and at least one of the 'subtype' may indicate the URI scheme. In this document, one type is specified, 'pstndata' and one subtype 'cnam' with the URI scheme specified, 'pstndata:'. R. Shockey - editor Expires February 2009 [Page 3] Internet-Draft CNAM Enumservice August 2008 2. Protocol Design Considerations. The design of this protocol was influenced by several factors. RFC 3761 [1] has become the defacto query-response protocol of choice for a variety of data types associated with E.164 numbering and addressing including data not necessarily associated with a SIP [18] or other communications session. RFC 3761 [1] is already being used by service providers to query for data that has significant privacy or security issues associated with it. RFC 4769 [17], for instance, describes an Enumservice that associates an E.164 number with a PSTN Local Routing Number. An Enumservice for CNAM data has similar design requirements of being used in private and closed systems. Communications service providers are concerned with the impact of call setup up times on the overall user experience. There is a strong desire to maintain a single query mechanism for data involving E.164 phone numbers and not complicate call processing applications with multiple protocol mechanisms. Were the query for CNAM data to require a secondary protocol mechanism such as LDAP or IRIS to retrieve the data, it could significantly impact call setup times. 3. Definition of PSTN CNAM Data Calling Name data is a string of up to 15 ASCII [9] characters of information associated with a specific calling party number [10] [11][12][13][14]. In the Public Switched Telephone Network (PSTN) this data is sent by the originating network only at the specific request of the terminating network via a SS7 Transaction Capabilities Application Part (TCAP) response message. 4. The PSTNDATA URI This document proposes a new URI scheme 'PSTNDATA:' specifically to carry PSTN data in general and CNAM data specifically. pstndatauri = "pstndata:" datatype ["/" telephone- subscriber ] ";" content R. Shockey - editor Expires February 2009 [Page 4] Internet-Draft CNAM Enumservice August 2008 datatype = "cnam" ; Other datatypes can be defined by adding ; alternative values. content = [ mediatype ] [ ":base64" ] "," data mediatype = [ type "/" subtype ] *( ";" parameter ) data = *urlchar parameter = attribute "=" value ANSI standards specify the use of ASCII [9] in the response to TCAP queries for Calling Name data. This specification does not preclude the use of internationalized characters within the pstn URI, nor does it preclude the use of more than 15 characters. 5. Enumservice Privacy Responses and Parameters The PSTN defines several values for CNAM data in the event that there are privacy restrictions on the access to that data or that the data is unavailable. These are defined as "Reason for Absence of Name" in GR-1188 [13], consequently the following responses to a query are reserved. Within the datatype 'cnam' two special content cases with mediatype parameters and data are defined: Calling Name Privacy Indicator: 'unavailable=p,' This parameter defined as the Calling Name data information may be available but the Calling Party does not wish to have their Calling Name data displayed by Called Party User Agents. In this case, the data element is populated with rather than the Calling Name itself, such as "Private". Usage: pstndata:cnam;;unavailable=p, Calling Name Status Indicator Definition: 'unavailable=u,' R. Shockey - editor Expires February 2009 [Page 5] Internet-Draft CNAM Enumservice August 2008 This parameter is defined as there is no Calling Name data for that E.164 number available. In this case, the data element is populated with rather than the Calling Name itself, such as "Unavailable" or "Out of Area". Usage: pstndata:cnam;;unavailable=u, 6. Distribution of CNAM Data The distribution of CNAM data is often highly restricted. The NAPTR records described herein should not be part of the e164.arpa DNS tree. Distribution of this NAPTR data would be either within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access. If such data was distributed in an open DNS system, a national regulatory body may have jurisdiction, especially since CNAM information may contain Personally Identifying Information. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How Personally Identifying Information is collected, distributed and subsequently regulated is out of the scope of this document 7. Enumservice CNAM Response Examples This section documents several examples of how this protocol is used for illustrative purposes only. $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net. NAPTR 10 100 "u" "E2U+pstndata:cnam" "!^.*$!pstndata:cnam/+15052121111;;charset=us- ascii,Francois%20Audet!". ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net. NAPTR 10 100 "u" "E2U+pstndata:cnam" "!^.*$!pstndata:cnam/+15052121111;;charset=us- ascii,foo=bar,Francois%20Audet!". R. Shockey - editor Expires February 2009 [Page 6] Internet-Draft CNAM Enumservice August 2008 $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net. NAPTR 10 100 "u" "E2U+pstndata:cnam" "!^.*$!pstndata:cnam/+15052121111;;unavailable=u,Out%20of%20A rea!". $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.carrier1.example.net. NAPTR 10 100 "u" "E2U+pstndata:cnam" "!^.*$!pstndata:cnam;;unavailable=p,Private!". $ORIGIN 0.0.1.0.5.5.5.3.0.7.1.e164.carrier1.example.net. NAPTR 10 100 "u" "E2U+pstndata:cnam" "!^.*$!pstndata:cnam/+15052121111;image/gif:base64,R0lGODlhDw APAJEBAAAAAL+/v///AAAAACH5BAEAAAEALAAAAAAPAA8AAAIujA2Zx5EC 4WIgWnnqvQBJLTyhE4khaG5Wqn4tp4ErFnMY+Sll9naUfGpkFL5DAQA7!". 8. Usage Considerations Typically, the Calling Name data in the PSTN is delivered to the called party during the first silent interval after the first ring of the phone. (see GR-1188 requirement R3-341 [13]). If the Called party answers the call before this, Calling Name data may not be delivered. This protocol could be invoked, for example, when a user agent within a service providers network receives an INVITE without a display name present. The exact mechanism or determination of when to issue an ENUM-CNAM request, and the formatting of SIP [18] messages is beyond the scope of this document. 9. Privacy Considerations It is assumed that carriers, service providers, or other organizations that originate Calling Name data will not publish such information in a globally visible DNS tree, such as e164.arpa for reasons of personal privacy protection unless such publication is consistent with national regulatory policy. R. Shockey - editor Expires February 2009 [Page 7] Internet-Draft CNAM Enumservice August 2008 Service providers and other organizations will probably privately exchange and publish this data in their internally cached ENUM databases, which is only able to be queried by trusted elements of their network, such as soft switches and SIP [18] proxy servers. Service providers using this query response technique are advised that many national jurisdictions have strict regulations on the use of Calling Name data and that National Regulatory Authorities may have special regulations that permit subscribers to block the use of such data before call setup. Other jurisdictions have services known as anonymous caller rejection, meaning that calls made from a system where Calling Line Identification and Calling Name data are blocked are prevented from establishing a session. 10. Security Considerations Use of the CNAM Enumservice shall either be within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prevent general public access. It should be noted that this content type is designed to carry potentially personal information and as such, may be subject to restrictions within various national jurisdictions. In many cases, the actual information that needs to be protected is the combination of the Name associated with the Telephone Number or the association of the name with the telephone call. So, it will be necessary to protect the response to the query that provides the association between the two elements. The CNAM Enumservice defined in this document is assumed to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPSec [15] and sometimes by physically protecting the underlying network. In any case, the provider should ensure that measures are taken to prevent both fraud and unauthorized R. Shockey - editor Expires February 2009 [Page 8] Internet-Draft CNAM Enumservice August 2008 disclosure by using a combination of authentication and Encryption. 11. IANA Considerations This document registers the 'cnam' Enumservice using the type 'pstn' and the subtype 'cnam' in the Enumservice registry described in the IANA considerations in RFC 3761 [1]. Details of this registration are provided in sections 13 and 14 of this document. This document also registers with the IANA the URI 'pstndata:' per RFC 4395 [15] 11.1 IANA Enumservice Registration for "pstndata" with subtype "cnam" Enumservice Name: "cnam" Enumservice Type: "pstndata" Enumservice Subtype: "cnam" URI Schemes: "pstndata:" Functional Specification: This Enumservice indicates that a resource record contains Calling Name Delivery Information that can be addressed by the associated 'pstndata:' URI scheme in order to facilitate the display of Calling Party information from a PSTN endpoint to a VoIP Client User Agent or other application. Security Considerations: See Section 9. Intended Usage: COMMON Authors: Richard Shockey and Jason Livingood, et. al. (for author contact detail see Authors' Addresses section) R. Shockey - editor Expires February 2009 [Page 9] Internet-Draft CNAM Enumservice August 2008 11.2 IANA Registration Template for URI "pstndata:" URI scheme name. The name of the URI is "pstndata:". Status. The intended status is Permanent. NOTE: The distribution of CNAM data is often highly restricted. Usage of this URI should either be within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prevent general public access. The records described herein should not be part of the e164.arpa or any other portion of the DNS tree. Other datatypes can be defined by adding alternative values. Tokens are registered with IANA. URI scheme syntax. pstndatauri = "pstndata:" datatype ["/" telephone- subscriber ] ";" content datatype = "cnam" ; Other datatypes can be defined by adding ; alternative values. content = [ mediatype ] [ ":base64" ] "," data mediatype = [ type "/" subtype ] *( ";" parameter ) data = *urlchar parameter = attribute "=" value where "telephone-subscriber" is imported from RFC 3966 [19], "urlchar" is imported from RFC 2396 [20], and "attribute" and "value" are imported from RFC 2045 [21]. URI scheme semantics. The PSTN defines several values for CNAM data in the event that there are privacy restrictions on the access to that data or that the data is unavailable. These are defined as R. Shockey - editor Expires February 2009 [Page 10] Internet-Draft CNAM Enumservice August 2008 "Reason for Absence of Name" in GR-1188 [13], consequently the following responses to a query are reserved. Within the datatype 'cnam' two special content cases with mediatype parameters and data are defined: Calling Name Privacy Indicator: 'unavailable=p,' This parameter defined as the Calling Name data information may be available but the Calling Party does not wish to have their Calling Name data displayed by Called Party User Agents. In this case, the data element is populated with rather than the Calling Name itself, such as "Private". Usage: pstndata:cnam;;unavailable=p, Calling Name Status Indicator Definition: 'unavailable=u,' This parameter is defined as there is no Calling Name data for that E.164 number available. In this case, the data element is populated with rather than the Calling Name itself, such as "Unavailable" or "Out of Area". Usage: pstndata:cnam;;unavailable=u, Encoding considerations. The purpose of this URI is to enable service providers to place Calling Name Delivery information (CNAM) into RFC 3761 [1] databases or to send ENUM queries to a protocol converter that would have access to the Signaling System 7 (SS7) Network. This, in turn, could enable such parties to offer Calling Name Delivery services using the technology provided by RFC 3761[1]. The information stored in these databases can be encoded to facilitate storage and retrieval operations. The type of R. Shockey - editor Expires February 2009 [Page 11] Internet-Draft CNAM Enumservice August 2008 encoding used is identified using appropriate media type parameters. If not otherwise identified, character data is presumed to be encoded using US-ASCII. Applications and/or protocols that use this URI scheme name. This URI scheme is intended for use in ENUM RFC 3761 [1] databases. Interoperability considerations. The URI is designed to be used specifically in conjunction with trusted systems that utilize the RFC 3761 [1] databases. Security considerations: The distribution of CNAM data is often highly restricted. Distribution of this data would typically be either within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access. It should be noted that this content type is designed to carry potentially personal information and as such, may be subject to restrictions within various national jurisdictions. In many cases, the actual information that needs to be protected is the combination of the Name associated with the Telephone Number or the association of the name with the telephone call. So, it will be necessary to protect the response to the query that provides the association between the two elements. The pstn URI defined in this document is assumed to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPSec [15] and sometimes by physically protecting the underlying network. In any case, the provider should ensure that measures are taken to prevent both fraud and unauthorized disclosure by using a combination of authentication and Encryption. R. Shockey - editor Expires February 2009 [Page 12] Internet-Draft CNAM Enumservice August 2008 11.3 Datatype Token Registry IANA is requested to create a registry for datatype tokens described in section 11.2. Values shall be registered using the Standards Action policy described in BCP 26 [22]. Specifications presented to the IESG for standards action MUST include both the requested token and a syntax specification for the token. Registry Name: "pstndata: URI datatype Token Registry" Registration Template: Datatype name: Datatype specification: 11.4 IANA Registration Template for datatype Token "cnam" Datatype name: cnam Datatype specification: Section 11.2 of this document. Contacts. Richard Shockey NeuStar 46000 Center Oak Plaza Sterling, VA 20166 USA Phone: +1-571-434-5651 Email: richard.shockey@neustar.biz Jason Livingood Comcast Cable Communications 1500 Market Street Philadelphia, PA 19102 USA R. Shockey - editor Expires February 2009 [Page 13] Internet-Draft CNAM Enumservice August 2008 Phone: +1-215-981-7813 Email: jason_livingood@cable.comcast.com Author/Change controller. This specification is a work item of the IETF ENUM working group, with the mailing list address enum@ietf.org References. [ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. 12. Normative References [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [2] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997. [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. R. Shockey - editor Expires February 2009 [Page 14] Internet-Draft CNAM Enumservice August 2008 [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002. [15] Hansen, T, et al., "The "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006 [16] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [17] Livingood, J. and Shockey, R. "IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information", RFC 4769, November 2006 [18] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [19] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [20] Berners-Lee, T., et al., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005. [21] Freed, N. and Borenstein, N.S. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [22] Narten, T. and Alvestrand, H. "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, October 1998 13. Informative References [9] American National Standards Institute (ANSI), Coded Character Set - 7-Bit American National Standard Code for Information Interchange, ANSI X3.4, 1986. [10] American National Standards Institute (ANSI), Telecommunications Network-to-Customer Installation R. Shockey - editor Expires February 2009 [Page 15] Internet-Draft CNAM Enumservice August 2008 Interfaces - Analog Voice grade Switched Access Lines with Calling Number Delivery, Calling Name Delivery, or Visual Message-Waiting Indicator Features, ANSI T1.6401.03-1998 [11] American National Standards Institute (ANSI), Telecommunications- Integrated Services Digital Network (ISDN) - Calling Line Identification Presentation and Restriction Supplementary Services, ANSI T1.625-1993 [12] American National Standards Institute ANSI), Telecommunications - Calling Name Identification Presentation, ANSI T1.641-1995 [13] Telcordia Technologies, "CLASS Feature: Calling Name Delivery Generic Requirements", GR-1188-CORE, Issue 2, December 2000 [14] Telcordia Technologies, "CLASS Feature: Calling Number Delivery", GR-31-CORE, Issue 1, June 2000 [15] Kent, S. et al, "Security Architecture for the Internet Protocol", RFC 4301, December 2005 14. Acknowledgements The authors wish to thank Larry Masinter, Paul Kyzivat, Hadriel Kaplan and Don Troshynski for invaluable input to this document. 15. Author's Address Richard Shockey - editor NeuStar 46000 Center Oak Plaza Sterling, VA 20166 USA Phone: +1-571-434-5651 Email: richard.shockey@neustar.biz Jason Livingood Comcast Cable Communications R. Shockey - editor Expires February 2009 [Page 16] Internet-Draft CNAM Enumservice August 2008 1500 Market Street Philadelphia, PA 19102 USA Phone: +1-215-981-7813 Email: jason_livingood@cable.comcast.com Kevin McCandless Verisign 7400 West 129th Street Overland Park, KS 66213 USA Phone : +1 913-814-6397 Email : KMcCandless@verisign.com Manjul Maharishi Verisign 21345 Ridgetop Circle Dulles VA 20166 Phone :+1 703-948-3255 Email : mmaharishi@verisign.com Scott Hollenbeck Verisign 21345 Ridgetop Circle Dulles VA 20166 Phone : +1 703-948-3257 Email : shollenbeck@verisign.com 16. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE PRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE R. Shockey - editor Expires February 2009 [Page 17] Internet-Draft CNAM Enumservice August 2008 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). R. Shockey - editor Expires February 2009 [Page 18]