[Note: This attachment will not appear ATTACHMENT 2 in the Code of Federal Regulations.] FEDERAL ENERGY REGULATORY COMMISSION ______________________________________________________________ STANDARDS AND COMMUNICATION PROTOCOLS FOR OPEN ACCESS SAME-TIME INFORMATION SYSTEM (OASIS) ______________________________________________________________ Version 1.2 (May 27, 1998) S&CP Phase IA Version 1.2 May 27, 1998 TABLE OF CONTENTS 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 DEFINITION OF TERMS . . . . . . . . . . . . . . . . . . . . 1 2. NETWORK ARCHITECTURE REQUIREMENTS . . . . . . . . . . . . . . . 2 2.1 ARCHITECTURE OF OASIS NODES . . . . . . . . . . . . . . . . 2 2.2 INTERNET-BASED OASIS NETWORK . . . . . . . . . . . . . . . 2 2.3 COMMUNICATION STANDARDS REQUIRED . . . . . . . . . . . . . 3 2.4 INTERNET TOOL REQUIREMENTS . . . . . . . . . . . . . . . . 3 2.5 NAVIGATION AND INTERCONNECTIVITY BETWEEN OASIS NODES . . . 4 3. INFORMATION ACCESS REQUIREMENTS . . . . . . . . . . . . . . . . 4 3.1 REGISTRATION AND LOGIN REQUIREMENTS . . . . . . . . . . . . 4 3.2 SERVICE LEVEL AGREEMENTS . . . . . . . . . . . . . . . . . 5 3.3 ACCESS TO INFORMATION . . . . . . . . . . . . . . . . . . . 5 3.4 PROVIDER UPDATING REQUIREMENTS . . . . . . . . . . . . . . 6 3.5 ACCESS TO CHANGED INFORMATION . . . . . . . . . . . . . . . 7 3.6 USER INTERACTION WITH AN OASIS NODE . . . . . . . . . . . . 7 4. INTERFACE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . 8 4.1 INFORMATION MODEL CONCEPTS . . . . . . . . . . . . . . . . 8 4.2 OASIS NODE CONVENTIONS AND STRUCTURES . . . . . . . . . . . 9 4.2.1 OASIS Node Naming Requirements . . . . . . . . . . . . . 9 4.2.1.1 OASIS Node Names . . . . . . . . . . . . . . . . . 9 4.2.1.2 OASIS Node and Primary Provider Home Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1.3 CGI Script Names . . . . . . . . . . . . . . . . . 9 4.2.2 Data Element Dictionary . . . . . . . . . . . . . . . 10 4.2.3 OASIS Template Constructs . . . . . . . . . . . . . . 10 4.2.3.1 Template Construction . . . . . . . . . . . . . . 10 4.2.3.2 Template Categories . . . . . . . . . . . . . . . 11 4.2.3.3 Template HTML Screens . . . . . . . . . . . . . . 12 4.2.4 Query/Response Template Requirements . . . . . . . . . 12 4.2.4.1 Query Requirements . . . . . . . . . . . . . . . . 12 4.2.4.2 Response Requirements . . . . . . . . . . . . . . 13 4.2.5 Input/Response Template Requirements . . . . . . . . . 14 4.2.5.1 Input Requirements . . . . . . . . . . . . . . . . 14 4.2.5.2 Response to Input . . . . . . . . . . . . . . . . 15 4.2.6 Query Variables . . . . . . . . . . . . . . . . . . . 15 4.2.6.1 General . . . . . . . . . . . . . . . . . . . . . 15 4.2.6.2 Standard Header Query Variables . . . . . . . . . 16 4.2.6.3 Responses to Queries . . . . . . . . . . . . . . . 16 4.2.6.4 Multiple Instances . . . . . . . . . . . . . . . . 16 4.2.6.5 Logical Operations . . . . . . . . . . . . . . . . 17 4.2.6.6 Handling of Time Data Elements . . . . . . . . . . 17 4.2.6.7 Default Values . . . . . . . . . . . . . . . . . . 18 S&CP Phase IA Version 1.2 May 27, 1998 i 4.2.6.8 Limitations on Queries . . . . . . . . . . . . . . 18 4.2.7 CSV Format . . . . . . . . . . . . . . . . . . . . . . 18 4.2.7.1 General Record Format . . . . . . . . . . . . . . 18 4.2.7.2 Input Header Records . . . . . . . . . . . . . . . 19 4.2.7.3 Response Header Records . . . . . . . . . . . . . 19 4.2.7.4 Data Records . . . . . . . . . . . . . . . . . . . 20 4.2.7.5 Continuation Records . . . . . . . . . . . . . . . 21 4.2.7.6 Error Handling in CSV-Formatted Responses . . . . 21 4.2.8 Registration Information . . . . . . . . . . . . . . . 22 4.2.8.1 General . . . . . . . . . . . . . . . . . . . . . 22 4.2.8.2 Company Information . . . . . . . . . . . . . . . 22 4.2.8.3 User Information . . . . . . . . . . . . . . . . 23 4.2.9 Representation of Time . . . . . . . . . . . . . . . . 23 4.2.9.1 General . . . . . . . . . . . . . . . . . . . . . 24 4.2.9.2 Input Time . . . . . . . . . . . . . . . . . . . . 24 4.2.9.3 Output (Response) Time . . . . . . . . . . . . . . 24 4.2.10 Transaction Process . . . . . . . . . . . . . . . . . 25 4.2.10.1 Purchase Transactions . . . . . . . . . . . . . . 25 4.2.10.2 Status Values . . . . . . . . . . . . . . . . . . 26 4.2.10.3 Dynamic Notification . . . . . . . . . . . . . . . 29 4.2.10.3.1 HTTP Notification . . . . . . . . . . . . . . 29 4.2.10.3.2 Email Notification . . . . . . . . . . . . . 31 4.2.11 Reference Identifiers . . . . . . . . . . . . . . . . 31 4.2.12 Linking of Ancillary Services to Transmission Services 32 4.3 TEMPLATE DESCRIPTIONS . . . . . . . . . . . . . . . . . . . 35 4.3.1 Template Summary . . . . . . . . . . . . . . . . . . . 35 4.3.2 Query/Response of Posted Services Being Offered . . . 37 4.3.2.1 Transmission Capacity Offerings Available for Purchase (transoffering) . . . . . . . . . . . . . . . . . . . . . 38 4.3.2.2 Ancillary Services Available for Purchase (ancoffering) . . . . . . . . . . . . . . . . . . . . . . 39 4.3.3 Query/Response of Services Information . . . . . . . . 40 4.3.3.1 Transmission Services (transserv) . . . . . . . . 41 4.3.3.2 Ancillary Services (ancserv) . . . . . . . . . . . 41 4.3.4 Query/Response of Schedules and Curtailments . . . . . 42 4.3.4.1 Hourly Schedule (schedule) . . . . . . . . . . . . 42 4.3.4.2 Curtailment/Interruption (curtail) . . . . . . . 43 4.3.5 Query/Response of Lists of Information . . . . . . . . 44 4.3.5.1 List (list) . . . . . . . . . . . . . . . . . . . 45 4.3.6 Query/Response to Obtain the Audit log . . . . . . . . 45 4.3.6.1 Audit Log Information (auditlog) . . . . . . . . . 45 4.3.7 Purchase Transmission Services . . . . . . . . . . . . 46 4.3.7.1 Customer Capacity Purchase Request (transrequest) 46 4.3.7.2 Status of Customer Purchase Request (transstatus) 48 4.3.7.3 Seller Approval of Purchase (transsell) . . . . . 51 4.3.7.4 Customer Confirmation of Purchase (Input) (transcust) 52 4.3.7.5 Alternate Point of Receipt/Delivery (transalt) . . 53 4.3.7.6 Seller to Reassign Service Rights to Another Customer (transassign) . . . . . . . . . . . . . . . . . . . . . . 55 4.3.8 Seller Posting of Transmission Services . . . . . . . 57 4.3.8.1 Seller Capacity Posting (transpost) . . . . . . . 57 4.3.8.2 Seller Capacity Modify (transupdate) . . . . . . . 59 4.3.9 Purchase of Ancillary Services . . . . . . . . . . . . 60 S&CP Phase IA Version 1.2 May 27, 1998 ii 4.3.9.1 Customer Requests to Purchase Ancillary Services (ancrequest) . . . . . . . . . . . . . . . . . . . . . . 60 4.3.9.2 Ancillary Services Status (ancstatus) . . . . . . 61 4.3.9.3 Seller Approves Ancillary Service (ancsell) . . . 63 4.3.9.4 Customer accepts Ancillary Service (anccust) . . . 63 4.3.10 Seller Posting of Ancillary Services . . . . . . . . . 64 4.3.10.1 Seller Ancillary Services Posting (ancpost) . . . 64 4.3.10.2 Seller Modify Ancillary Services Posting (ancupdate) 65 4.3.11 Informal Messages . . . . . . . . . . . . . . . . . . 66 4.3.11.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.11.2 Message (message) . . . . . . . . . . . . . . . . 67 4.3.11.3 Provider/Sellers Message Delete Request (messagedelete) . . . . . . . . . . . . . . . . . . . . . 68 4.3.11.4 Personnel Transfers (personnel) . . . . . . . . . 68 4.3.11.5 Discretion (discretion) . . . . . . . . . . . . . 69 4.3.11.6 Standards of Conduct (stdconduct) . . . . . . . . 70 4.4 FILE REQUEST AND FILE DOWNLOAD EXAMPLES . . . . . . . . . . 70 4.4.1 File Example for Hourly Offering . . . . . . . . . . . 70 4.4.2 File Example for Hourly Schedule Data . . . . . . . . 72 4.4.3 Customer Posting a Transmission Service Offering . . . 73 4.4.4 Example of Re-aggregating Purchasing Services using Reassignment . . . . . . . . . . . . . . . . . . . . . . . 74 4.4.5 File Examples of the Use of Continuation Records . . 75 4.4.6 Example of Negotiation of Price . . . . . . . . . . . 80 4.4.6.1 Negotiation with Preconfirmation . . . . . . . . . 80 4.4.6.2 Negotiations without Preconfirmation . . . . . . . 81 4.4.6.3 Multiple Step Negotiations . . . . . . . . . . . . 81 4.4.6.4 Negotiations Refused by Seller . . . . . . . . . . 82 4.4.6.5 Negotiations Withdrawn by Customer . . . . . . . . 82 4.5 INFORMATION SUPPORTED BY WEB PAGE . . . . . . . . . . . . . 83 5. PERFORMANCE REQUIREMENTS . . . . . . . . . . . . . . . . . . 83 5.1 SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2 ACCESS PRIVILEGES . . . . . . . . . . . . . . . . . . . . . 85 5.3 OASIS RESPONSE TIME REQUIREMENTS . . . . . . . . . . . . . 85 5.4 OASIS PROVIDER ACCOUNT AVAILABILITY . . . . . . . . . . . . 86 5.5 BACKUP AND RECOVERY . . . . . . . . . . . . . . . . . . . . 87 5.6 TIME SYNCHRONIZATION . . . . . . . . . . . . . . . . . . . 88 5.7 TS INFORMATION TIMING REQUIREMENTS . . . . . . . . . . . . 88 5.8 TS INFORMATION ACCURACY . . . . . . . . . . . . . . . . . . 89 5.9 PERFORMANCE AUDITING . . . . . . . . . . . . . . . . . . . 89 5.10 MIGRATION REQUIREMENTS . . . . . . . . . . . . . . . . . 89 APPENDIX A - DATA ELEMENT DICTIONARY . . . . . . . . . . . . A-1 S&CP Phase IA Version 1.2 May 27, 1998 iii 1. INTRODUCTION 1.1 DEFINITION OF TERMS The following definitions are offered to clarify discussions of the OASIS in this document. a. Transmission Services Information (TS Information) is transmission and ancillary services information that must be made available by public utilities on a non-discriminatory basis to meet the regulatory requirements of transmission open access. b. Open Access Same-Time Information System (OASIS) comprises the computer systems and associated communications facilities that public utilities are required to provide for the purpose of making available to all transmission users comparable interactions with TS Information. c. Open Access Same-Time Information System Node (OASIS Node) is a subsystem of the OASIS. It is one computer system in the (OASIS) that provides access to TS Information to a Transmission Customer. d. Transmission Provider (TP or Primary Provider) is the public utility (or its designated agent) that owns, operates or controls facilities used for the transmission of electric energy in interstate commerce. (This is the same term as is used in Part 35.3). e. Transmission Customer (TC or Customer) is any eligible Customer (or its designated agent) that can or does execute a transmission service agreement or can or does receive transmission service. (This is the same term as is used in Part 35.3). f. Secondary Transmission Provider (ST, Reseller, or Secondary Provider) is any Customer who offers to sell transmission capacity it has purchased. (This is the same as Reseller in Part 37). g. Transmission Services Information Provider (TSIP) is a Transmission Provider or an agent to whom the Transmission Provider has delegated the responsibility of meeting any of the requirements of Part 37. (This is the same as Responsible Party in Part 37). h. Value-Added Transmission Services Information Provider (VTSIP) is an entity who uses TS Information in the same manner as a Customer and provides value-added information services to its Customers. S&CP Phase IA Version 1.2 May 27, 1998 1 S&CP Phase IA Version 1.2 May 27, 1998 2 2. NETWORK ARCHITECTURE REQUIREMENTS 2.1 ARCHITECTURE OF OASIS NODES a. Permit Use of Any OASIS Node Computers: TSIPs shall be permitted to use any computer systems as an OASIS Node, so long as they meet the OASIS requirements. b. Permit Use of Any Customer Computers: OASIS Nodes shall permit the use by Customers of any commonly available computer systems, as long as they support the required communication links to the Internet. c. Permit the Offering of Value-Added Services: TSIPs are required, upon request, to provide their Customers the use of private network connections on a cost recovery basis. Additional services which are beyond the scope of the minimum OASIS requirements are also permitted. When provided, these private connections and additional services shall be offered on a fair and non-discriminatory basis to all Customers who might choose to use these services. d. Permit Use of Existing Communications Facilities: In implementing the OASIS, the use of existing communications facilities shall be permitted. The use of OASIS communication facilities for the exchange of information beyond that required for open transmission access (e.g., transfer of system security or operations data between regional control centers) shall also be permitted, provided that such use does not negatively impact the exchange of open transmission access data and is consistent with the Standards of Conduct in Part 37. e. Single or Multiple Providers per Node: An OASIS Node may support a single individual Primary Provider (plus any Secondary Providers) or may support many Primary Providers. 2.2 INTERNET-BASED OASIS NETWORK a. Internet Compatibility: All OASIS Nodes shall support the use of internet tools, internet directory services, and internet communication protocols necessary to support the Information Access requirements stated in Section 4. b. Connection through the Public Internet: Connection of OASIS Nodes to the public Internet is required so that Users may access them through Internet links. This connection shall be made through a firewall to improve security. S&CP Phase IA Version 1.2 May 27, 1998 3 c. Connection to a Private Internet Network: OASIS Nodes shall support private connections to any OASIS User (User) who requests such a connection. The TSIP is permitted to charge the User, based on cost, for these connections. The same internet tools shall be required for these private networks as are required for the public Internet. Private connections must be provided to all users on a fair and nondiscriminatory basis. d. Internet Communications Channel: The OASIS Nodes shall utilize a communication channel to the Internet which is adequate to support the performance requirements given the number of Users subscribed to the Providers on the Node (see section 5.3). 2.3 COMMUNICATION STANDARDS REQUIRED a. Point-to-Point Protocol (PPP) and Internet Protocol Control Protocol (IPCP) (reference RFCs 1331 and 1332) shall be supported for private internet network dial-up connections. b. Serial Line Internet Protocol (SLIP) (reference RFC 1055) shall be supported for private internet network dial-up connections. c. Transport Control Protocol and Internet Protocol (TCP/IP) shall be the only protocol set used between OASIS Nodes whenever they are directly interconnected, or between OASIS Nodes and Users using private leased line internet network connections. d. Hyper Text Transport Protocol (HTTP), Version 1.0 (RFC 1945), shall be supported by User s web browsers so they can use it to select information for viewing displays and for downloading and uploading files electronically. e. Internet Protocol Address: All OASIS Nodes are required to use an IP address registered with the Internet Network Information Center (InterNIC), even if private connections are used. 2.4 INTERNET TOOL REQUIREMENTS Support for the following specific internet tools is required, both for use over the public Internet as well as for any private connections between Users and OASIS Nodes: a. Hypertext Markup Language (HTML), at least Version 3.2 shall be used by supported by User s browsers as a standard tool for viewing information. S&CP Phase IA Version 1.2 May 27, 1998 4 b. HTML Forms shall be provided by the TSIPs to allow Customers to enter information to the OASIS Node. c. Domain Name Service (DNS) (ref. RFC 1034, 1035) shall be provided as a minimum by the TSIPs (or their Internet Service Provider) for the resolution of IP addresses to allow Users to navigate easily between OASIS Nodes. d. Simple Network Management Protocol (SNMP) is recommended but not required to provide tools for operating and managing the network, if private interconnections between OASIS Nodes are established. e. The Primary Provider shall support Email for exchanges with Customers, including the sending of attachments. The protocols supported shall include, as a minimum, the Simple Messaging Transfer Protocol (SMTP), Post Office Protocol (POP), and Multipurpose Internet Mail Extensions (MIME). 2.5 NAVIGATION AND INTERCONNECTIVITY BETWEEN OASIS NODES a. World Wide Web Browsers: TSIPs shall permit Users to navigate using WWW browsers for accessing different sets of TS Information from one Provider, or for getting to TS Information from different Providers on the same OASIS Node. These navigation methods shall not favor User access to any Provider over another Provider, including Secondary Providers. b. Internet Interconnection across OASIS Nodes: Navigation tools shall not only support navigation within the TSIP's Node, but also across interconnected OASIS Nodes. This navigation capability across interconnected Nodes shall, as a minimum, be possible through the public Internet. 3. INFORMATION ACCESS REQUIREMENTS 3.1 REGISTRATION AND LOGIN REQUIREMENTS a. Location of Providers: To provide Users with the information necessary to access the desired Provider, all Primary Providers shall register their OASIS Node URL address with www.tsin.com. This URL address should include the unique four letter acronym the Primary Provider will use as the PRIMARY_PROVIDER_CODE. b. Initial User Registration: TSIPs shall require Users to register with a Primary Provider before they are permitted to S&CP Phase IA Version 1.2 May 27, 1998 5 access the Provider's TS Information. There must be a reference pointing to registration procedures on each Primary Provider's home page. Registration procedures may vary with the administrative requirements of each Primary Provider. c. Initial Access Privileges: Initial registration shall permit a User only the minimum Access Privileges. A User and a Primary Provider shall mutually determine what access privilege the User is permitted. The TSIP shall set a User's Access Privilege as authorized by the Primary Provider. d. User Login: After registration, Users shall be required to login every time they establish a dial-up connection. If a direct, permanent connection has been established, Users shall be required to login initially or any time the connection is lost. Use of alternative forms of login and authentication using certificates and public key standards is acceptable. e. User Logout: Users shall be automatically logged out any time they are disconnected. Users may logout voluntarily. 3.2 SERVICE LEVEL AGREEMENTS Service Level Agreements: It is recognized that Users will have different requirements for frequency of access, performance, etc., based on their unique business needs. To accommodate these differing requirements, TSIPs shall be required to establish a "Service Level Agreement" with each User which specifies the terms and conditions for access to the information posted by the Providers. The default Service Level Agreement shall be Internet access with the OASIS Node meeting all minimum performance requirements. 3.3 ACCESS TO INFORMATION a. Display: TSIPs shall format all TS Information in HTML format such that it may be viewed and read directly by Users without requiring them to download it. This information shall be in clear English as much as possible, with the definitions of any mnemonics or abbreviations available on-line. The minimum information that is to be displayed is provided in the Templates in Section 4.3. b. Read-Only Access to TS Information: For security reasons, Users shall have read-only access to the TS Information. They shall not be permitted to enter any information except where explicitly allowed, such as HTML transaction request forms or by the Templates in Section 4.3. c. Downloading Capability: Users shall be able to download from an OASIS Node the TS Information in electronic format as a S&CP Phase IA Version 1.2 May 27, 1998 6 file. The rules for formatting of this data are described in Section 4.2. d. On-Line Data Entry on Forms: Customers shall be permitted to fill out on-line the HTML forms supplied by the TSIPs, for requesting the purchase of services and for posting of products for sale (by Customers who are resellers). Customers shall also be permitted to fill-out and post Want-Ads. e. Uploading Capability: Customers shall be able to upload to OASIS Nodes the filled-out forms. TSIPs shall ensure that these uploaded forms are handled identically to forms filled out on- line. TSIPs shall provide forms that support the HTTP input of Comma Separated Variable (CSV) records. This capability shall permit a Customer to upload CSV records using standard Web browsers or additional client software (such as fetch_http) to specify the location of the CSV records stored on the Customer's hard disk. f. Selection of TS Information: Users shall be able to dynamically select the TS Information they want to view and/or download. This selection shall be, as a minimum, through navigation to text displays, the use of pull-down menus to select information for display, data entry into forms for initiating queries, and the selection of files to download via menus. 3.4 PROVIDER UPDATING REQUIREMENTS The following are the Provider update requirements: a. Provider Posting of TS Information: Each Provider (including Secondary Providers and Value-Added Providers) shall be responsible for writing (posting) and updating TS Information on their OASIS node. No User shall be permitted to modify a Provider's Information. b. INFO.HTM: Each Provider shall provide general information on how to use their node and describe all special aspects, such as line losses, congestion charges and assistance. The address for the directory of this information shall be INFO.HTM, an HTML web page, linked to the Provider's registered URL address. c. OASIS Node Space for Secondary Provider: To permit Users to readily find TS Information for the transmission systems that they are interested in, TSIPs shall provide database space on their OASIS Node for all Secondary Providers who have purchased, and who request to resell, transmission access rights for the power systems of the Primary Providers supported by that Node. d. Secondary Provider Posting to Primary Provider Node: The Secondary Providers shall post the relevant TS Information on S&CP Phase IA Version 1.2 May 27, 1998 7 the OASIS Node associated with each Primary Provider from whom the transmission access rights were originally purchased. e. Secondary Provider Posting Capabilities: The TSIPs shall ensure that the Secondary Providers shall be able to post their TS Information to the appropriate OASIS Nodes using the same tools and capabilities as the Customers, meet the same performance criteria as the Primary Providers, and allow users to view these postings on the same display page, using the same tables, as similar capacity being sold by the Primary Providers. f. Free-Form Posting of non-TS Information: The TSIP shall ensure that non-TS Information, such as Want-Ads, may be posted by Providers and Customers, and that this information is easily accessible by all Users. The TSIP shall be allowed to limit the volume and/or to charge for the posting of non-TS Information. g. Time Stamps: All TS Information shall be associated with a time stamp to show when it was posted to the OASIS Node. h. Transaction Tracking by an Assignment Reference Number: All requests for purchase of transmission or ancillary services will be marked by a unique accounting number, called an assignment reference. i. Time-Stamped OASIS Audit Log: All posting of TS Information, all updating of TS Information, all User logins and disconnects, all User download requests, all Service Requests, and all other transactions shall be time stamped and stored in an OASIS Audit Log. This OASIS Audit Log shall be the official record of interactions, and shall be maintained on-line for download for at least 90 days. Changes in the values of posted Capacity (Available Transfer Capability) must be stored in the on-line Audit Log for 20 days. Audit records must be maintained for 3 years off-line and available in electronic form within seven days of a Customer request. j. Studies: A summary description with dates, and programs used of all transmission studies used to prepare data for the Primary Provider's ATC and TTC calculation will be provided along with information as to how to obtain the study data and results. 3.5 ACCESS TO CHANGED INFORMATION a. General Message & Log: TSIPs shall post a general message and log that may be read by Users. The message shall state that the Provider has updated some information, and shall contain (or point to) a reverse chronological log of those changes. This log may be the same as the Audit Log. The User may use the manual capability to see the message. S&CP Phase IA Version 1.2 May 27, 1998 8 b. TSIP Notification Design Responsibilities: The TSIP shall avoid a design that could cause serious performance problems by necessitating frequent requests for information from many Users. 3.6 USER INTERACTION WITH AN OASIS NODE There are three basic types of User interactions which must be supported by the OASIS Node. These interactions are defined in Section 4.3. a. Query/Response: The simplest level of interactions is the query of posted information and the corresponding response. The User may determine the scope of the information queried by specifying values, through an HTML form, a URL string, or an uploaded file, using Query Variables and their associated input values as defined with each Template in Section 4.3. The response will be either an HTML display or a record oriented file, depending on the output format that the User requests. The TSIP may establish procedures to restrict the size of the response, if an overly broad query could result in a response which degrades the overall performance of the OASIS Node for their Users. b. Purchase Request: The second type of Customer interaction is the submittal of a request to purchase a service. The Customer completes an input form, a URL string or uploads a file and submits it to the OASIS Node. The uploaded file can either be a series of query variables or a record oriented file. The request is processed by the Seller of the service, possibly off-line from the OASIS Node, and the status is updated accordingly. If a purchase request is approved by the Seller, then it must be again confirmed by the Customer. Once the Customer confirms an approved purchase, a reservation for those services is considered to exist, unless later the reservation is reassigned, displaced, or annulled. c. Upload and Modify Postings: Customers who wish to resell their rights may upload a form, create the appropriate URL or upload a file to post services for sale. A similar process applies to eligible Third Party Sellers of ancillary services. The products are posted by the TSIP. The seller may monitor the status of the services by requesting status information. Similarly the Seller may modify its posted transmission services by submitting a service modification request through a form, a URL query, or by uploading a file. 4. INTERFACE REQUIREMENTS S&CP Phase IA Version 1.2 May 27, 1998 9 4.1 INFORMATION MODEL CONCEPTS a. ASCII-Based OASIS Templates: For providing information to Users, TSIPs shall use the specified OASIS Templates. These Templates define the information which must be presented to Users, both in the form of graphical displays and as downloaded files. Users shall be able to request Template information using query-response data flows. The OASIS Templates are described in section 4.3. The Data Element Dictionary, which defines the data elements in the OASIS Templates, is provided in Appendix A. Data elements must be used in the exact sequence and number as shown in the Templates when file uploads and downloads are used. Although the contents of the graphical displays are precisely defined as the same information as in the Templates, the actual graphical display formats of the TS information are beyond the scope of the OASIS requirements. Due to the nature of graphical displays, there may be more than one graphical display used to convey the information in a single Template. b. ASCII-Based OASIS File Structures: For uploading requests from and downloading information to Users, TSIPs shall use specific file structures that are defined for OASIS Template information (see section 4.2). These file structures are based on the use of headers which contain the Query Variable information, including the name of the OASIS Template. These headers thus determine the contents and the format of the data that follows. Although headers may not be essential if file transfers contain the exact sequence and number of data elements as the Templates, this feature is being preserved for possible future use when additional flexibility may be allowed. 4.2 OASIS NODE CONVENTIONS AND STRUCTURES 4.2.1 OASIS Node Naming Requirements The following naming conventions shall be used to locate information posted on OASIS. OASIS naming conventions shall conform to standard URL structures. 4.2.1.1 OASIS Node Names In order to provide a consistent method for locating an OASIS Node, the standard Internet naming convention shall be used. All OASIS Node names shall be unique. Each Primary Provider OASIS Node name and home directory shall be registered with the master OASIS S&CP Phase IA Version 1.2 May 27, 1998 10 directory site at http://www.tsin.com. OASIS Node names shall be stored in an Internet DNS name directory. 4.2.1.2 OASIS Node and Primary Provider Home Directory The home directory name on an OASIS Node shall be "OASIS" to identify that the directory is related to the OASIS. The directory of each Primary Provider shall be listed under the "OASIS" directory: http://(OASIS Node name)/OASIS/(PRIMARY_PROVIDER_CODE) Where: (OASIS Node name) is the World Wide Web URL address of the OASIS Information Provider. ((PRIMARY_PROVIDER_CODE) is the 4 character acronym of the primary provider. PRIMARY_PROVIDER_CODEs shall be registered with the master OASIS directory site at http://www.tsin.com. A pointer to user registration information shall be located on the Primary Provider's home page. 4.2.1.3 CGI Script Names Common Gateway Interface (CGI) scripts shall be located in the directory "data" as follows: http://(OASIS Node name)/OASIS/ (PRIMARY_PROVIDER_CODE) /data/(cgi script name)?(query variables) Where: (cgi script name) is the OASIS Template name (see Section 4.3). Other cgi scripts may be defined as required to implement the HTML interface to the documented templates. (query variables) is a list of query variables with their settings formatted as defined by the HTTP protocol (i.e., URL encoded separated by ampersands). Example: To request the hourly schedule Template at Primary Provider WXYZ Co. http://www.wxyz.com/oasis/wxyz/data/schedule ?templ=schedule& ver=1.2& fmt=data & stime=19960412040000PD &sptime=19960412100000PD& pprov=wxyz 4.2.2 Data Element Dictionary S&CP Phase IA Version 1.2 May 27, 1998 11 The following are the requirements for the Data Element Dictionary: a. Definition of OASIS Information Elements: All OASIS Information data elements shall be defined in the Data Element Dictionary which will be stored in the OASIS Node directory: http://(OASISNode Name)/OASIS/(PRIMARY_PROVIDER_CODE)/ (datadic.html | datadict.txt) Where: datadic.html is the HTML version of the data element dictionary datadic.txt is the ASCII text version of the data element dictionary The Data Element Dictionary is defined in Appendix A. b. Provider-specific Data Element Values: The valid values that certain OASIS Information data elements may take on, such as PATH_NAME, etc., are unique to a Primary Provider. Names which must be uniquely identified by Primary Provider shall be listed on-line on the OASIS Node via the LIST Template (see Section 4.3.5). In posting OASIS information associated with data elements which are not free-form text, TSIPs shall use only the accepted data element values listed in the Data Element Dictionary and/or those values posted in the LIST of provider specific names provided on the OASIS. 4.2.3 OASIS Template Constructs 4.2.3.1 Template Construction Section 4.3 lists the set of OASIS Templates that shall be supported by all OASIS nodes. These OASIS Templates are intended to be used precisely as shown for the transfer of data to/from OASIS, and identify, by Data Elements names, the information to be transferred. The construction of the OASIS Templates shall follow the rules described below: a. Unique OASIS Template Name: Each type of OASIS Template shall be identified with a unique name which shall be displayed to the User whenever the OASIS Template is accessed. b. Transfer Protocol: OASIS Templates are transferred using the HTTP protocol. Templates shall support both the "GET" and "POST" methods for transferring "query string" name/value pairs, as well as the OASIS specific "comma separated value" (CSV) format for posting and retrieval of information from OASIS. HTML screens and forms shall be implemented for each OASIS Template. S&CP Phase IA Version 1.2 May 27, 1998 12 c. Source Information: Each OASIS Template shall identify the source of its information by including or linking to the name of the Primary Provider, the Secondary Provider, or the Customer who provided the information. d. Time Of Last Update: Each OASIS Template shall include a time indicating when it was created or whenever the value of any Data Element was changed. e. Data Elements: OASIS Templates shall define the elementary Data Element Dictionary names for the data values to be transferred or displayed for that Template. f. Documentation: OASIS Information shall be in non-cryptic English, with all mnemonics defined in the Data Element Dictionary or a glossary of terms. TSIPs shall provide on-line descriptions and help screens to assist Users understanding the displayed information. Documentation of all formats, contents, and mnemonics shall be available both as displays and as files which can be downloaded electronically. In order to meet the "User-Friendly" goal and permit the flexibility of the OASIS to expand to meet new requirements, the OASIS Templates shall be as self-descriptive as possible. 4.2.3.2 Template Categories OASIS Templates are grouped into the following two major categories: a. Query/Response: These Templates are used to query and display information posted on OASIS. Each query/response Template accepts a set of user specified Query Variables and returns the appropriate information from data posted on OASIS based on those query variables. The valid Query Variables and information to be returned in response are identified by Data Element in Section 4.3. b. Input/Response: These Templates are used to upload/input information on OASIS. The required input information and information to be returned in response are identified by Data Element in Section 4.3, Template Descriptions. 4.2.3.3 Template HTML Screens Though the exact form and content of the HTML screens and forms associated with the OASIS Templates are not dictated by this document, the following guidelines shall be adhered to for all HTML screens and forms implemented on OASIS: a. Data Element Headings: Data displayed in an HTML screen/form shall be labeled such that the associated data S&CP Phase IA Version 1.2 May 27, 1998 13 value(s) is(are) easily and readily identifiable as being associated with a particular OASIS Template Data Element. HTML "Hot-Links" or other pointer mechanisms may be provided for Data Element headings in OASIS Templates which permit the User to access documentation describing the meaning, type, and format of the associated data. b. Display Limitations: HTML screens and forms shall be implemented in such a way to allow the display of all data specified for each OASIS Template. This may take the form of "wrapping" of lines of information on the screen, the use of horizontal and/or vertical scrolling, or the use of "Hot-Links" or other pointer mechanisms. There is not necessarily a one-to- one relationship between OASIS implemented HTML screens and their associated Template. However, all Template data elements shall be viewable through one or more HTML screens. c. Template Navigation: HTML "Hot-Links" or other pointer mechanisms may be provided to assist the navigation between screens/forms associated with related OASIS Templates. 4.2.4 Query/Response Template Requirements Retrieval of information posted on OASIS is supported by the Query/Response Templates. The "query" identifies the OASIS Template and optionally supplies additional Data Elements which may be used to select specific information to be returned in the "response". 4.2.4.1 Query Requirements Query information is transferred to OASIS using the HTTP protocol as a string of Query Variables in the form of name/value pairs. Query Variable name/value pairs are specified as a collection of encoded strings (e.g., blank characters replaced by plus (+) character, etc.) in the form of name=value, with each name/value pair separated by ampersands (&) (see section 4.2.6). OASIS shall support the following methods for Users to input Query information: a. HTML: HTML FORM input and/or hypertext links shall be provided to allow Users to specify OASIS Template Query Variables. This will be the easiest way to obtain information and should be the choice of most casual Users and for simple requests. The exact nature and form of these HTML screens are not specified, and may differ between OASIS nodes. b. GET Method: The HTTP GET method for specifying query information appended to a standard OASIS URL shall be supported. Using this method, the name=value formatted Query Variables preceded by a question mark (?) are appended to the URL. Each "name" in a name/value pair corresponds to a Data Element name associated with that Template. OASIS shall support the S&CP Phase IA Version 1.2 May 27, 1998 14 specification of all Data Elements associated with a Template by both their full name and alias as defined in the Data Dictionary. The "value" in a name/value pair represents the value to be associated with the Data Element being specified in the appropriate format as defined in the Data Dictionary and encoded according to the HTTP protocol. c. POST Method: The HTTP POST method for specifying query information in the message body shall be supported. Using this method, the name=value formatted Query Variables shall be transferred to OASIS using the "Content-length:" HTTP header to define the length in bytes of the encoded query string and the "Content-type: application/x-www-form-urlencoded" HTTP header to identify the data type included in the message body. Each "name" in a name/value pair corresponds to a Data Element name associated with that Template. OASIS shall support the specification of all Data Elements associated with a Template by both their full name and alias as defined in the Data Dictionary. The "value" in a name/value pair represents the value to be associated with the Data Element being specified in the appropriate format as defined in the Data Dictionary and encoded according to the HTTP protocol. User queries using any of the above methods are supported directly by the User's web browser software. More sophisticated data transfer mechanisms, such as the automated querying of information based on Query Variable strings contained in a User data file (i.e., "uploading a file containing a URL string), require appropriate software (e.g., "fetch_http") running on the User's computer system to effect the data transfer. 4.2.4.2 Response Requirements In response to a validly formatted Query for each Query/Response OASIS Template, the OASIS shall return the requested information in one of two forms based on the User specified OUTPUT_FORMAT Query Variable: a. HTML: If the User requests the response to have the format of "HTML" (OUTPUT_FORMAT=HTML) then the response from the OASIS shall be a web page using the HTML format. This shall be the default for all Query/Response Templates. b. CSV Format: Comma Separated Value (CSV) format (OUTPUT_FORMAT=DATA) returns the requested information in the body of the HTTP response message. The "Content-length:" HTTP header shall define the length in bytes of the response, and the "Content-type: text/x-oasis-csv" HTTP header shall be used to identify the data type included in the message body (see CSV File Format). S&CP Phase IA Version 1.2 May 27, 1998 15 4.2.5 Input/Response Template Requirements The posting of information on OASIS, including reservations for transmission/ancillary service, services for sale on the secondary market, etc., is supported by the Input/Response Templates. The "input" identifies the required data associated with an OASIS Template to be posted on OASIS, and the "response" specifies the information returned to the User. 4.2.5.1 Input Requirements Input information is transferred to OASIS using the HTTP protocol as either a string of Query Variables in the form of name/value pairs, or as a Comma Separated Value (CSV) message. Query Variable name/value pairs are specified as a collection of encoded strings (e.g., blank characters replaced by plus (+) character, etc.) in the form of name=value, with each name/value pair separated by ampersands (&). CSV formatted messages are specified in the body of an HTTP message as a series of data records preceded by a fixed set of header records (see section 4.2.7). OASIS shall support the following methods for Users to transfer Input data: a. HTML: HTML FORM input shall be provided to allow Users to specify the necessary Input data associated with each Input/Response OASIS Template. This may be in the form of fill in blanks, buttons, pull-down selections, etc., and may use either the GET or POST methods. The exact nature and form of these HTML screens are not specified, and may differ between OASIS nodes. b. GET Method: The HTTP GET method for specifying Input information in the form of a query string appended to a standard OASIS URL shall be supported. Using this method, the name=value formatted Query Variables preceded by a question mark (?) are appended to the URL. Each "name" in a name/value pair corresponds to a Data Element name associated with that Template. OASIS shall support the specification of all Data Elements associated with a Template by both their full name and alias as defined in the Data Dictionary. The "value" in a name/value pair represents the value to be associated with the Data Element being specified in the appropriate format as defined in the Data Dictionary and encoded according to the HTTP protocol. c. POST Method: The HTTP POST method for specifying Input information in the form of a query string in the message body S&CP Phase IA Version 1.2 May 27, 1998 16 shall be supported. Using this method, the name=value formatted Query Variables shall be transferred to OASIS using the "Content-length:" HTTP header to define the length in bytes of the encoded query string and the "Content-type: application/x- www-form-urlencoded" HTTP header to identify the data type included in the message body. Each "name" in a name/value pair corresponds to a Data Element name associated with that Template. OASIS shall support the specification of all Data Elements associated with a Template by both their full name and alias as defined in the Data Dictionary. The "value" in a name/value pair represents the value to be associated with the Data Element being specified in the appropriate format as defined in the Data Dictionary and encoded according to the HTTP protocol. d. CSV Format: Comma Separated Value (CSV) formatted Input information transferred in the body of a User's HTTP message shall be supported. The "Content-length:" HTTP header shall define the length in bytes of the Input, and the "Content-type: text/x-oasis-csv" HTTP header shall be used to identify the data type included in the message body. 4.2.5.2 Response to Input In response to a validly formatted Input for each Input/Response OASIS Template, the OASIS shall return an indication as to the success/failure of the requested action. The OASIS shall respond to the Input in one of two forms, based on the OUTPUT_FORMAT, which was input by a User either as a Query Variable or in a CSV format Header Record: a. HTML: If the User requests the response to have the format of "HTML" (OUTPUT_FORMAT =HTML) then the response from the OASIS shall be a web page using the HTML format. This shall be the default for all Input/Response Templates invoked using either the FORM, GET or POST methods of input. b. CSV Format: Comma Separated Value (CSV) format (OUTPUT_FORMAT=DATA) returns the response information in the body of the HTTP response message. The "Content-length:" HTTP header shall define the length in bytes of the response, and the "Content-type: text/x-oasis-csv" HTTP header shall be used to identify the data type included in the message body. This shall be the default for all Input/Response Templates invoked using the CSV Format methods of input. 4.2.6 Query Variables S&CP Phase IA Version 1.2 May 27, 1998 17 4.2.6.1 General Both Query/Response and Input/Response OASIS Templates shall support the specification of a query string consisting of Query Variables formatted as name/value pairs. OASIS shall support the specification of Data Element names ("name" portion of name=value pair) in both the full name and alias forms defined in the Data Dictionary. OASIS shall support the specification of Query Variables from the User using either the HTTP GET or POST methods. On input, Data Element names and associated values shall be accepted and processed without regard to case. On output, Data Element names and associated values may not necessarily retain the input case, and could be returned in either upper or lower case. 4.2.6.2 Standard Header Query Variables The following standard Query Variable Data Elements shall be supported for all OASIS Templates and must be entered for each Query by a User: VERSION TEMPLATE OUTPUT_FORMAT PRIMARY_PROVIDER_CODE PRIMARY_PROVIDER_DUNS RETURN_TZ Since these header Query Variables must be supported for all Templates, they are not listed explicitly in the Template descriptions in Section 4.3 All standard header Query Variables with appropriate values must be entered by the User. 4.2.6.3 Responses to Queries Responses to Queries will include the following information as a minimum: TIME_STAMP VERSION TEMPLATE OUTPUT_FORMAT PRIMARY_PROVIDER_CODE PRIMARY_PROVIDER_DUNS RETURN_TZ The additional information shall include: S&CP Phase IA Version 1.2 May 27, 1998 18 a. The requested information as defined by the Template indicated in the Query b. For CSV downloads, the additional header Data Elements required (see section 4.2.7.3) 4.2.6.4 Multiple Instances Certain Query Variables may be repeated in a given Query/Response OASIS Template query string. Where such multiple instances are documented in the Template definitions using an asterix (*) after the query variable. When more than one instance of the Query Variable is specified in the query string, OASIS shall recognize such multiple instances by either the Data Element's full name or alias suffixed with sequential numeric qualifiers starting with the number 1, (e.g., PATH_NAME1=abc&PATH_NAME2=xyz, or PATH1=abc&PATH2=xyz). At least 4 multiple instances will be permitted for each query variable marked with an asterix (*). 4.2.6.5 Logical Operations OASIS shall use the following logical operations when processing Query Variables for Query/Response OASIS Templates. All Query Variables, with the exception of multiple instances of the same Query Variable Data Element, shall be operated on to return information based on the logical-AND of those Query Variables. For example, the query string " SELLER_CODE=abc &PATH=xyz " should return information associated with only those records that are on transmission path "xyz" AND associated with transmission provider "abc." Multiple instances of the same Query Variable shall be operated on as logical- OR. For example, " SELLER_CODE=abc &PATH1=xyz&PATH2=opq " should return information associated with transmission provider "abc" AND either transmission path "xyz" OR transmission path "opq". Some logical operations may exclude all possibilities, such that the responses may not contain any data. 4.2.6.6 Handling of Time Data Elements In cases where a single query variable is provided to select information associated with a single template data element that represents a point in time (e.g., TIME_OF_LAST_UPDATE), OASIS shall return to the User all requested information whose associated data element time value (e.g. TIME_OF_LAST_UPDATE) is equal to or later than the value specified by the query variable. In this case the stop time is implicitly "now". S&CP Phase IA Version 1.2 May 27, 1998 19 A pair of query variables (e.g. START_TIME_QUEUED and STOP_TIME_QUEUED) that represents the start and stop of a time interval but is associated with one single template data element (e.g. TIME_QUEUED) shall be handled by OASIS to return to the User all requested information whose associated data element time value falls within the specified time interval. A pair of query variables (e.g. START_TIME and STOP_TIME query variables) that represents the start and stop of one time interval but is associated with another pair of template data elements (e.g. START_TIME and STOP_TIME of a service offering) that represents a second time interval, shall be handled by OASIS to return to the User all requested information whose associated data element time interval overlaps any portion of the specified time interval. Specifically, the START_TIME query variable selects all information whose STOP_TIME data element value is later than the START_TIME query variable, and the STOP_TIME query variable selects all information whose START_TIME data element value is earlier than the STOP_TIME query variable. For example: The transoffering template query string "START_TIME 970101000000ES&STOP_TIME 970201000000ES" shall select from the OASIS database all associated offerings whose start/stop times overlap any portion of the time from 00:00 January 1, 1997, to 00:00 February 1, 1997. This would include offerings that (1) started prior to Jan. 1 and stopped any time on or after Jan. 1, and (2) started on or after Jan 1 but before Feb 1 For changes to and from daylight savings time, either Universal Time or the correct time and zone must be used, based on whether daylight savings time is in effect. All time values shall be checked upon input to ensure their validity with respect to date, time, time zone, and daylight savings time. 4.2.6.7 Default Values Query Variables that are not specified by the User may take on default values as appropriate for that Query Variable at the discretion of the OASIS TSIP. 4.2.6.8 Limitations on Queries OASIS TSIP may establish validation procedures and/or default values for Query Variables to restrict the size and/or performance impact of overly broad queries. 4.2.7 CSV Format S&CP Phase IA Version 1.2 May 27, 1998 20 4.2.7.1 General Record Format OASIS Users shall be able to upload information associated with Input/Response OASIS Templates and download information associated with all OASIS Templates using a standardized Comma Separated Value (CSV) format. CSV formatted data is transferred to/from OASIS as part of the body of an HTTP message using the "Content-length:" HTTP header to define the length in bytes of the message body, and the "Content-type: text/x-oasis-csv" HTTP header to identify the data type associated with the message body. CSV formatted data consists of a fixed set of header records followed by a variable number of data records. Each record shall be separated by a carriage return plus line feed (denoted by the symbol in all examples). The fields within a record shall be delimited by commas (,). All data within a CSV formatted message shall use printable ASCII characters with no other special embedded codes, with the exception of the special encoding requirements associated with text fields. 4.2.7.2 Input Header Records The following standard header records are required for the uploading of Input data for all Input/Response OASIS Templates: VERSION=nn.nª TEMPLATE=aaaaaaaaaaª OUTPUT_FORMAT=[DATA] ª PRIMARY_PROVIDER_CODE=aaaaª PRIMARY_PROVIDER_DUNS=nnnnnnnnnª RETURN_TZ=aaª DATA_ROWS=nnnª COLUMN_HEADERS=[Template data element names separated by commas]ª The format of the value associated with each of the Input header record Data Elements are dictated by the Data Dictionary. The value associated with the DATA_ROWS Data Element shall define the total number of data records that follow in the message after the COLUMN_HEADERS record. The COLUMN_HEADERS record defines, by Data Element name, the data associated with each comma separated column contained in each subsequent data record (row). On Input, either the Data Element's full name or alias listed in the Data Dictionary may be specified. 4.2.7.3 Response Header Records S&CP Phase IA Version 1.2 May 27, 1998 21 When explicitly specified using the OUTPUT_FORMAT=DATA Query Variable or implied by the Input of a CSV format message, the OASIS shall respond with the following standard response header records for all OASIS Templates: REQUEST_STATUS=nnnª ERROR_MESSAGE=aaa ª TIME_STAMP=yyyymmddhhmmsstzª VERSION=nn.nª TEMPLATE=aaaaaaaaaaª OUTPUT_FORMAT=DATAª PRIMARY_PROVIDER_CODE=aaaaª PRIMARY_PROVIDER_DUNS=nnnnnnnnnª RETURN_TZ=tzª DATA_ROWS=nnnª COLUMN_HEADERS=[Template data element names separated by commas] ª The format of the value associated with each of the Response header record Data Elements are dictated by the Data Dictionary. The value associated with the DATA_ROWS Data Element shall define the total number of data records returned in the message following the COLUMN_HEADERS header record. The COLUMN_HEADERS record defines, by Data Element name, the data associated with each comma-separated column contained in each subsequent data record (row). In all OASIS responses, the Data Element's full name shall be listed in the COLUMN_HEADERS record. The order of the column headings shall be the same as shown in the Templates for URL uploads and downloads. For graphical displays, the Provider may define the order that the Data Element names are shown. 4.2.7.4 Data Records Data Records immediately follow the standard Input or Response header records. With the exception of data records grouped together as a single "logical record" through the use of Continuation Records, each data record in a CSV formatted Input message represents a single, complete execution of the associated OASIS Template. That is, sending five CSV formatted Input messages for a given Template to the same PRIMARY_PROVIDER_CODE with a single data record per message shall be handled in exactly the same fashion as sending a single CSV formatted Input message for the same Template and PRIMARY_PROVIDER_CODE which contains five data records. Each field (column) within each data record defines the value to be associated with the corresponding Data Element defined in the COLUMN_HEADERS record. The number of Data Records in the message is S&CP Phase IA Version 1.2 May 27, 1998 22 defined by the DATA_ROWS header record. The data values associated with each column Data Element are interpreted based on the Data Element type as defined in the Data Dictionary: a. Numeric Data Elements: All numeric Data Elements shall be represented by an ASCII string of numeric digits in base ten, plus the decimal point. b. Text Data Elements: Alphabetic and alphanumeric data elements shall be represented as ASCII strings and encoded using the following rules: Text strings that do not contain commas (,) or double quotes (") shall be accepted both with and without being enclosed by double quotes. Text fields with commas (,) or double quotes (") must be enclosed with double quotes. In addition double quotes within a text field shall be indicated by two double quotes (""). The Data Element field length specified in Data Dictionary does not include the additional double quotes necessary to encode text data. a. Null Data Elements: Null Data Elements shall be represented by two consecutive commas (,,) corresponding to the leading and trailing (if appropriate) Data Element comma separators. Null text strings may optionally be represented by two consecutive double quote characters within the leading and trailing comma separators (i.e., ,"", ). 4.2.7.5 Continuation Records Continuation records shall be used to indicate that the information in multiple rows (records) is part of one logical record. Continuation records will be indicated through the use of a column header called CONTINUATION_FLAG. This column header is either the first column (if in a response to a query) or second column (if in a response to an input) in all Templates permitting continuation records. The first record shall contain a N in the CONTINUATION_FLAG column and each following record which is part of a continuation record shall contain a "Y" in this column, thus associating the information in that record with the information in the previous record. An "N" shall indicate that the record is not a continuation record. Any values corresponding to COLUMN_HEADERs other than those explicitly allowed for a particular Template shall be ignored. However commas must be included to properly align the fields. S&CP Phase IA Version 1.2 May 27, 1998 23 4.2.7.6 Error Handling in CSV-Formatted Responses Validity of each record in the CSV-formatted Response to a Template Input shall be indicated through the use of RECORD_STATUS and ERROR_MESSAGE Data Elements which are included in each data record (row) of the Response. If no error was encountered in an Input data record, the RECORD_STATUS Data Element in the corresponding Response record shall be returned with a value of 200 (success), and the ERROR_MESSAGE shall be blank. If any error is detected in processing an Input data record, it shall be indicated by a RECORD_STATUS Data Element value other than 200. The ERROR_MESSAGE shall be set to an appropriate text message to indicate the source of the error in that data record. The overall validity of each Template Query or Input shall be indicated in the CSV-formatted Response via the two REQUEST_STATUS and ERROR_MESSAGE header records (see section 4.2.7.3): If no errors were encountered in processing the User's Input data records, the REQUEST_STATUS shall be returned with the value of 200 (success), and the ERROR_MESSAGE shall be blank. If any errors were detected in the Template Input data records, the REQUEST_STATUS value shall be any value other t h an 200, and the ERROR_MESSAGE shall be set to an appropriate text message to indicate the source of the error. S&CP Phase IA Version 1.2 May 27, 1998 24 The OASIS node shall validate all Input records before returning a Response to the User. All valid records shall be processed by the node, while invalid records shall be identified as erroneous through the use of RECORD_STATUS and ERROR_MESSAGE. The User must correct the invalid fields and resubmit only those records which were invalid. If an error is encountered in a record which is part of a set of Continuation records, then all records belonging to that set must be resubmitted. 4.2.8 Registration Information 4.2.8.1 General As specified in the Information Access Requirements, OASIS Nodes shall provide a mechanism to register Users of the OASIS with a Provider. For all levels of access to OASIS information beyond simple read-only access, OASIS node shall provide a mechanism to identify Users of the OASIS at least to the level of their respective Companies. Both Company and User registration information shall be maintained by the OASIS node. 4.2.8.2 Company Information OASIS Templates require that certain Company registration information be maintained. As an extension of the Company registration information of the host, domain and port identifiers for dynamic notification of changes in the Customer's purchase requests, a field should be added to the Company's registration information that would define/identify how notification would be delivered to that Company should a transmission or ancillary purchase request be directed to that Company as a Seller of a transmission or ancillary service. The pertinent information would be either a full HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information or a "mailto:" URL with the appropriate mailbox address string. On receipt of any purchase request directed to that Company as SELLER via either the "transrequest" or "ancrequest" templates, or on submission of any change in request STATUS to that Company as SELLER via either the "transcust" or "anccust" templates, a notification message formatted as documented for the delivery of notification to the Customer, shall be formatted and directed to the Seller. At a minimum, OASIS shall maintain the following information for each Company: a. Company Code: 4 character code for primary transmission providers; 6 character code for eligible customers in accordance with NERC Tagging Information System (TIS) requirements shall be maintained for each Company. S&CP Phase IA Version 1.2 May 27, 1998 25 b. Default Contact: Unless specified for each individual user affiliated with the Company, default contact information consisting of a phone number, fax number, and e-mail address shall be maintained for each Company. c. Provider Affiliation: Each eligible Customer shall be obligated to identify to the OASIS TSIP any affiliation with a Transmission Provider whose "home page" is on that OASIS node. d. Notification URL: For Companies using the URL notification mechanism for delivery of messages on each change of ancillary/transmission reservation STATUS, each Company shall provide the IP host name and port number to be used in delivering notification messages. OASIS nodes shall have the right to refuse support for notification to any IP ports other than port 80. 4.2.8.3 User Information With the exception of "read-only" (visitor) access, OASIS nodes shall as a minimum provide a mechanism to identify Users of the node with at least their Company. However, OASIS nodes and Providers shall have the right to require full User identification even for visitor accounts. To support the required OASIS Template Data Elements, OASIS nodes shall maintain the following information for each registered User: Company Name Phone Fax Email In the event no additional User identification/registration information is maintained by the OASIS, all Template Data Elements referring to "company, name, phone, fax, e-mail" for either Customers or Sellers shall default to the Contact Information maintained for that User's Company. 4.2.9 Representation of Time 4.2.9.1 General It is critical that all Users of OASIS have a clear and unambiguous representation of time associated with all information transferred to/from OASIS. For this reason, all Data Elements associated with time in OASIS shall represent "wall clock" times, which are NOT to be S&CP Phase IA Version 1.2 May 27, 1998 26 confused with other common industry conventions such as "hour ending." For the convenience of the User community, OASIS nodes shall be allowed to accept the input and display of "time" in any acceptable form provided such non-standard representations are CLEARLY labeled on the associated HTML screens. Alternate representations of time in CSV formatted messages shall not be allowed. The following rules shall be implemented in OASIS for the representation of time on User entries (Query and Input) and output (Response) Templates. 4.2.9.2 Input Time All time related Data Elements associated with either the Input or Query of Input/Response or Query/Response OASIS Templates shall be validated according the following rules. If the time zone associated with a time Data Element is associated with either Universal Time (UT) or a "standard" time zone (e.g., ES, CS, etc.), OASIS shall accept and apply a fixed hour offset from Universal Time year-round. If the time zone associated with a time Data Element is specified with a "daylight savings" time zone (e.g. ED, CD, etc.), OASIS shall verify that daylight savings time is in effect for the date/time specified. If daylight savings time (as specified by the time from 2:00am on the first Sunday of April through 2:00 am on the last Sunday of October) is not in effect, the Users input shall be rejected with an error response. If daylight savings time is in effect, the Users input shall be accepted and the appropriate hours offset from Universal Time shall be applied by OASIS for conversion to all other time zones. The input of start/stop times for transactions spanning the crossover day between standard and daylight (and vices versa) times must be made either entirely in standard time (valid year-round), or in two different time zones (xS/xD or xD/xS) for the start and stop times, depending on the time of year. 4.2.9.3 Output (Response) Time The OASIS shall return all time Data Elements in the response to Input/Response or Query/Response OASIS Templates based on either the User specified RETURN_TZ header Query Variable or an appropriate OASIS specific default. OASIS shall interpret RETURN_TZ to specify: a. The base time zone for conversion of all time Data Elements (e.g. Eastern, Pacific, etc.) b. Whether daylight savings time is recognized. For example, a RETURN_TZ=ES would return all time Data Elements in Eastern Standard Time year-round. However, a RETURN_TZ=ED would direct OASIS to return all time Data Elements in Eastern Standard Time S&CP Phase IA Version 1.2 May 27, 1998 27 (ES) when daylight savings time is not in effect, and then return all time Data Elements in Eastern Daylight Time (ED) when daylight time is in effect. 4.2.10 Transaction Process 4.2.10.1 Purchase Transactions Customers shall purchase services from the Seller using the following steps (see Exhibit 4-1): a. The Templates (transrequest and ancrequest) shall be used by a Customer to enter a request for specific transmission services from a specific Seller. The Customer may enter a BID_PRICE which is different from the OFFER_PRICE in order to try to negotiate a lower price. The OASIS sets the initial STATUS of the request to QUEUED. The Customer may set the STATUS_NOTIFICATION to indicate that the OASIS must notify the Customer on any change of STATUS of transstatus (see Dynamic Notification).Prior to or commensurate with a Seller's setting of a preconfirmed reservation request's STATUS to ACCEPTED (and by implication CONFIRMED), the Seller must set OFFER_PRICE equal to the value of BID_PRICE as established by the Customer on submission of the request. b. The Templates (transstatus and ancstatus) shall be used by Customers and Sellers to monitor the status of their transactions in progress. These Templates shall also be used by any Users to review the status of any transactions. The NEGOTIATED_PRICE_FLAG data element is set when the Seller agrees to a BID_PRICE (by setting OFFER_PRICE equal to BID_PRICE) that is different from the previously posted price. It will show "higher" when OFFER_PRICE is higher than the posted price, and "lower" when the OFFER_PRICE is lower than the posted price. c. The Templates (transsell and ancsell) shall be used by a Seller both to set a new value into STATUS and to negotiate a price by entering a new OFFER_PRICE which is different from the BID_PRICE entered by the Customer in the transrequest Template (if it was not PRECONFIRMED). During these negotiations, a Reseller shall formally indicate the approval or disapproval of a transaction and indicate which rights from prior confirmed reservations are to be reassigned. A Primary Provider may, but is not required, to enter transaction approval or disapproval using this Template. The valid STATUS values which may be set by a Seller are: RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, DISPLACED, ANNULLED, or RETRACTED. S&CP Phase IA Version 1.2 May 27, 1998 28 d. The Customer shall use the transstatus and ancstatus Templates to view the Seller's new offer price and/or approval/disapproval decision. e. After receiving notification of the transaction's STATUS being set to "OFFER" by the Seller, the Templates (transcust and anccust) shall be used by the Customer to modify the BID_PRICE and set the STATUS to REBID. After negotiations are complete (STATUS set to "ACCEPTED" by the Seller), the Customer shall formally enter the confirmation or withdrawal of the offer to purchase services for the OFFER_PRICE shown in the transstatus Template. The valid STATUS values which a Customer may set are: REBID, CONFIRMED, or WITHDRAWN. f. The Seller shall use the transstatus (ancstatus) Template to view the Customer's new bid price and/or confirmation/withdrawal decision, again responding through transsell or ancsell if necessary. If the Seller offers to sell a service at an OFFER_PRICE less than that posted in the transoffering (ancoffering) Template, the transoffering (ancoffering) Template must be updated to reflect the new OFFER_PRICE. g. For deals consummated off the OASIS by a Seller, after the Customer has accepted the offering, the Templates (transassign and ancassign) may be used by the Seller to notify the Primary Provider of the transfer of rights to the Customer. Continuation records may be used to indicate the reassigning of rights for a "profile" of different assignments and different capacities over different time periods. h. The source of all user and seller contact information shall be the User registration process. Therefore, it shall not be input as part of uploads, but shall be provided as part of all transaction downloads. i. OASIS shall accept a seller initiated change in STATUS to ACCEPTED only when OFFER_PRICE matches BID_PRICE (i.e., seller must set OFFER_PRICE equal to BID_PRICE prior to or coincident with setting STATUS to accepted) j. OASIS shall accept a customer initiated change in STATUS to CONFIRMED only when BID_PRICE matches OFFER_PRICE (i.e., customer must set BID_PRICE equal to OFFER_PRICE prior to or coincident with setting STATUS to confirmed).. 4.2.10.2 Status Values The possible STATUS values are: QUEUED = initial status assigned by TSIP on receipt of "customer services purchase request" S&CP Phase IA Version 1.2 May 27, 1998 29 RECEIVED= assigned by TP to acknowledge QUEUED requests and indicate the service request is being evaluated, including for completing the required ancillary services STUDY= assigned by TP to indicate some level of study is required or being performed to evaluate service request OFFER= assigned by TP to indicate that a new OFFER_PRICE is being proposed REBID= assigned by TC to indicate that a new BID_PRICE is being proposed ACCEPTED= assigned by TP to indicate service request at the designated OFFER_PRICE has been approved/accepted. If the reservation request was submitted PRECONFIRMED, OASIS shall immediately set the reservation status to CONFIRMED. Depending upon the type of ancillary services required, the Seller may or may not require all ancillary service reservations to be completed before accepting a request. REFUSED= assigned by TP to indicate service request has been denied, SELLER_COMMENTS should be used to communicate reason for denial of service CONFIRMED= assigned by TC in response to TP posting "ACCEPTED" status, to confirm service. Once a request has been "CONFIRMED", a transmission service reservation exists WITHDRAWN= assigned by TC at any point in request evaluation to withdraw the request from any further action DISPLACED= assigned by TP when a "CONFIRMED" reservation from a TC is displaced by a longer term request and the TC has exercised right of first refusal (i.e. refused to match terms of new request) ANNULLED= assigned by TP when, by mutual agreement with the TC, a confirmed reservation is to be voided RETRACTED= assigned by TP when the TC fails to confirm or withdraw the request within the required time period S&CP Phase IA Version 1.2 May 27, 1998 30 Exhibit 4-1 - State Diagram of Purchase Transactions S&CP Phase IA Version 1.2 May 27, 1998 31 4.2.10.3 Dynamic Notification Customers may specify the delivery of dynamic notification messages on each change in STATUS of an ancillary or transmission service reservation. OASIS shall support the delivery of dynamic notification messages through either the HTTP protocol or by electronic mail. The selection of which mechanism is used and the contents of the messages delivered to the client program or e-mail address is defined by the content of the STATUS_NOTIFICATION data element as described in the next subsections. Regardless of whether this dynamic notification method is used or not, it shall still remain the User's responsibility to get the desired information, possibly through the use of a periodic "integrity request". OASIS nodes shall not be obligated or liable to guarantee delivery/receipt of messages via the STATUS_NOTIFICATION mechanism other than on a "best effort" basis. As an extension of the Company registration information of the host, domain and port identifiers for dynamic notification of changes in the Customer's purchase requests, a field should be added to the Company's registration information that would define/identify how notification would be delivered to that Company should a transmission or ancillary purchase request be directed to that Company as a Seller of a transmission or ancillary service. The pertinent information would be either a full HTTP protocol URL defining the protocol, host name, port, path, resource, etc. information or a "mailto:" URL with the appropriate mailbox address string. On receipt of any purchase request directed to that Company as SELLER via either the "transrequest" or "ancrequest" templates, or on submission of any change in request STATUS to that Company as SELLER via either the "transcust" or "anccust" templates, a notification message formatted as documented for the delivery of notification to the Customer, shall be formatted and directed to the Seller. 4.2.10.3.1 HTTP Notification OASIS shall deliver dynamic notification to a client system based on HTTP URL information supplied in part by the STATUS_NOTIFICATION data element and by information supplied as part of the Customer's Company registration information. HTTP URL's are formed by the concatenation of a protocol field (i.e., http: ), a domain name (e.g., //www.tsin.com), a port designation (e.g., :80 ), and resource location information. The STATUS_NOTIFICATION data element shall contain the protocol field "http:", which designates the notification method/protocol to be used, followed by all resource location information required; the target domain name and port designations shall be inserted into the notification URL based on the Customer's Company registration S&CP Phase IA Version 1.2 May 27, 1998 32 information. The resource location information may include directory information, cgi script identifiers and URL encoded query string name/value pairs as required by the Customer's application. OASIS performs no processing on the resource location information other than to include it verbatim along with the protocol, domain name and port information when forming the URL that will be used to deliver the HTTP protocol notification message. For example, Company XYZ has established the domain name and port designations of "//oasistc.xyz.com:80" as part of their registration information. When a transmission reservation is submitted by one of Company XYZ's users (the Customer), and includes a STATUS_NOTIFICATION data element with the value of "http:/cgi-bin/status?DEAL_REF=8&REQUEST_REF=173", OASIS shall deliver an HTTP notification message using the URL: http://oasistc.xyz.com:80/cgi-bin/status?DEAL_REF=8&REQUEST_REF= 173 If the STATUS_NOTIFICATION field contained only the "http:" protocol designation, the notification message would be delivered using the URL: http://oasistc.xyz.com:80 The contents of the HTTP protocol notification message delivered by OASIS shall consist of the complete URL created by combining fields from the STATUS_NOTIFICATION data element and Company registration information as part of an HTTP GET method request. In addition to the GET method HTTP header record, OASIS shall also append the CSV formatted output of the transstatus template information for that particular reservation using the standard Content-type: text/x-oasis-csv and appropriate Content-length: HTTP header records. OASIS shall use a Primary Provider specific default value for RETURN_TZ in formulating the transstatus response information. Continuing with the previous example, the important records in the HTTP notification message that would be delivered to Company XYZ for the transmission reservation request submitted to Primary Provider ABC and given an ASSIGNMENT_REF of 245 would be, GET http://oasistc.xyz.com:80/cgi-bin/status?DEAL_REF=8&REQUEST_REF= 173 HTTP/1.0 . . Content-type: text/x-oasis-csv Content-length: REQUEST_STATUS=200 TIME_STAMP= VERSION=1.2 TEMPLATE=transstatus OUTPUT_FORMAT=DATA S&CP Phase IA Version 1.2 May 27, 1998 33 PRIMARY_PROVIDER_CODE=ABC PRIMARY_PROVIDER_DUNS=123456789 RETURN_TZ= DATA_ROWS=1 COLUMN_HEADERS=CONTINUATION_FLAG, ASSIGNMENT_REF, . . . N, 245, . . . In the event an error is encountered delivering the HTTP notification message to the target URL as indicated by a failure of the target system to respond, or return of HTTP response status of 408, 500, 503, or 504, OASIS shall retry up to two more times, once every 5 minutes. 4.2.10.3.2 Email Notification OASIS shall deliver dynamic notification to an e-mail address based on Mailto: URL information specified in the STATUS_NOTIFICATION data element. Mailto: URL's consist of the "mailto:" protocol identifier and an Internet mail address to which the notification message should be sent. The STATUS_NOTIFICATION data element shall contain the protocol field "mailto:", which designates the notification method/protocol to be used, followed by an Internet mail address in conformance with RFC 822. OASIS shall send an e-mail message to the Internet mail address containing the following information: "To:" set to the mail address from the STATUS_NOTIFICATION data element, "From:" set to an appropriate mail address of the OASIS node, "Subject:" shall be the transstatus template name followed by the value of the ASSIGNMENT_REF data element and the current value for the STATUS data element associated with the reservation (e.g., "Subject: transstatus 245 ACCEPTED"), and the body of the message shall contain the CSV formatted output of the transstatus template information for that particular reservation. OASIS shall use a Primary Provider specific default value for RETURN_TZ in formulating the transstatus response information. 4.2.11 Reference Identifiers The TSIP shall assign a unique reference identifier, ASSIGNMENT_REF, for each Customer request to purchase capacity or services. The value of ASSIGNMENT_REF may be used to imply the order in which the request was received by the TSIP. This identifier will be used to track the request through various stages, and will be kept with the service through out its life. Whenever the service is resold, a new ASSIGNMENT_REF number is assigned, but previous ASSIGNMENT_REF numbers are also kept so that a chain of all transactions related to the service can be maintained. The TSIP shall assign a unique reference identifier, POSTING_REF, to each Seller's offerings of service for sale or other information (messages) posted on OASIS. This identifier shall be referenced by S&CP Phase IA Version 1.2 May 27, 1998 34 the Seller in any/all subsequent template submissions which would result in a modification to or deletion of that specific offering or message. Optionally, Customers may also refer to this POSTING_REF in their subsequent purchase requests to aid in identifying the specific offering associated with the purchase request. Sellers may aggregate portions of several previous transmission service reservations to create a new offering to be posted on OASIS. When all or a portion of such offerings are sold, the Seller (original Customer) is obligated to notify the Primary Provider of the sale/assignment by inserting appropriate reassignment information on OASIS (via the transsell or transassign templates) or by some other approved method. This reassignment information consists of the ASSIGNMENT_REF value assigned to the original reservation(s) and the time interval and capacity amount(s) being reassigned to the new reservation. These values are retained in the REASSIGNED_REF, REASSIGNED_START_TIME, REASSIGNED_STOP_TIME, and REASSIGNED_CAPACITY data elements. Sellers may identify their service offerings received from Customers through the Seller supplied value specified for the SALE_REF data element. Customers may track their purchase requests through the Customer supplied values specified for the DEAL_REF and REQUEST_REF data elements. Customers may also use POSTING_REF and SALE_REF in their purchase requests to refer back to posted offerings. 4.2.12 Linking of Ancillary Services to Transmission Services The requirements related to ancillary services are shown in transoffering (and updated using transupdate) using the ANC_SVC_REQ data element containing the following permitted values: SC:x; RV:x; RF:x; EI:x; SP:x; SU:x; where SC, RV, RF, EI, SP and SU are the ancillary services 1 through 6 described in the Proforma Tariff, SC - Scheduling, system Control and dispatch RV - Reactive supply and Voltage control RF - Regulation and Frequency response EI - Energy Imbalance SP - SPinning reserve SU - SUpplemental reserve and where x={M,R,O,U} means one of the following: Mandatory, which implies that the Primary Provider must provide the ancillary service Required, which implies that the ancillary service is required, but not necessarily from the Primary Provider S&CP Phase IA Version 1.2 May 27, 1998 35 Optional, which implies that the ancillary service is not necessarily required, but could be provided Unknown, which implies that the requirements for the ancillary service are not known at this time Ancillary services may be requested by a User from the Provider at the same time as transmission services are requested via the transrequest template, by entering the special codes into ANC_SVC_LINK to represent the Proforma ancillary services 1 through 6 (or more) as follows: SC:(AA); RV: (AA); RF: (AA[:xxx[:yyy[:nnn]]]); EI: (AA[:xxx[:yyy[:nnn]]]); SP: (AA[:xxx[:yyy[:nnn]]]); SU: (AA[:xxx[:yyy[:nnn]]]); {Registered}:(AA[:xxx[:yyy[:nnn]]]) where AA is the appropriate PRIMARY_PROVIDER_CODE, SELLER_CODE, or CUSTOMER_CODE, and represents the company providing the ancillary services. "AA" may be unspecified for "xxx" type identical to "FT", in which case the ":" character must be present and precede the "FT" type. If multiple "AA" terms are necessary, then each "AA" grouping will be enclosed within parenthesis, with the overall group subordinate to the ANC_SVC_TYPE specified within parenthesis. and where xxx represents either: _ "FT" to indicate that the Customer will determine ancillary services at a future time, or _ "SP" to indicate that the Customer will self-provide the ancillary services, or _ "RQ" to indicate that the Customer is asking the OASIS to initiate the process for making an ancillary services reservation with the indicated Provider or Seller on behalf of the Customer. The Customer must then continue the reservation process with the Provider or Seller. If the transmission services request is for preconfirmed service, then the ancillary services shall also be preconfirmed, or _ "AR" to indicate an assignment reference number sequence follows. The terms "yyy" and "nnn" are subordinate to the xxx type of "AR". yyy represents the ancillary services reservation number (ASSIGMNENT_REF) and nnn represents the capacity of the reserved ancillary services. Square brackets are used to indicated optional elements and are not used in the actual linkage itself. Specifically, the :yyy is applicable to only the "AR" term and the :nnn may optionally be left off if the capacity of ancillary services is the same as for the transmission services, and optionally multiple ancillary reservations may be indicated by additional (xxx[:yyy[:nnn]]) enclosed within parenthesis. If no capacity amount is indicated, the required capacity is assumed to come from the S&CP Phase IA Version 1.2 May 27, 1998 36 ancillary reservations in the order indicated in the codes, on an "as-needed" basis. Examples: example 1: Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU are required, but will be defined at a future time. "SC: (TPEL:RQ); RV: (TPEL:RQ); RF:(:FT); EI:(:FT); SP:(:FT); SU:(:FT)" ; example 2: Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and RF, EI, SP and SU are self-supplied. The customer code is "CPSE" "SC: (TPEL:RQ); RV: (TPEL:RQ); RF:(CPSE:SP); EI:(CPSE:SP); SP:(CPSE:SP); SU:(CPSE:SP)" example 3: Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU were purchased via a prior OASIS reservation from seller "SANC" whose reservation number was "39843". There is sufficient capacity within the Ancillary reservation to handle this Transmission reservation. "SC:(TPEL:RQ); RV:(TPEL:RQ); RF:(SANC:AR:39843); EI:(SANC:AR:39843) SP:(SANC:AR:39843); SU:(SANC:AR:39843)" example 4: Assume ancillary services SC and RV are mandatory from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU were purchased via prior OASIS reservations from sellers "SANC" and "TANC", whose reservation numbers where "8763" and "9824" respectively. There is not sufficient capacity within the Ancillary reservation from seller "SANC" to handle this Transmission reservation. In this case the OASIS reservation number 8763 will be depleted for the time frame specified within the transmission reservation and the remaining required amount will come from reservation number "9824". "SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763)(TANC:AR:9824)); EI:((SANC:AR:8763)(TANC:AR:9824)); SP:((SANC:AR:8763)(TANC:AR:9824)); SU:((SANC:AR:8763)(TANC:AR:9824))" example 5: Assume a transmission reservation in the amount of 100 mw/hour for a period of one day is made. Ancillary services SC and RV are mandatory S&CP Phase IA Version 1.2 May 27, 1998 37 from the TP, whose code is "TPEL", and ancillary services RF, EI, SP and SU were purchased via prior OASIS reservations from sellers "SANC" and "TANC", whose reservation numbers where "8763" and "9824" respectively. There is sufficient capacity within the Ancillary reservation from seller "SANC" to handle this Transmission reservation, however the purchaser wishes to use only "40 mw's" from this seller. In this case the OASIS reservation number 8763 will be depleted in the amount of "40 mw's" for the time frame specified within the transmission reservation and the remaining required amount will come from reservation number "9824". "SC:(TPEL:RQ); RV:(TPEL:RQ); RF:((SANC:AR:8763:40)(TANC:AR:9824)); EI:((SANC:AR:8763:40)(TANC:AR:9824)); SP:((SANC:AR:8763:40)(TANC:AR:9824)); SU:((SANC:AR:8763:40)(TANC:AR:9824))" 4.3 TEMPLATE DESCRIPTIONS The following OASIS Templates define the Data Elements in fixed number and sequence which must be provided for all data transfers to and from the OASIS nodes. The definitions of the data elements are listed in the Data Element Dictionary in Appendix A. TSIPs must provide a more detailed supplemental definition of the list of Sellers, Paths, Point of Receipt (POR), Point of Delivery (POD), Capacity Types, Ancillary Service Types and Templates on-line, clarifying how the terms are being used (see LIST Template). If POR and POD are not used, then Path Name must include directionality. Many of the Templates represent query-response interactions between the User and the OASIS Node. These interactions are indicated by the "Query" and "Response" section respectively of each Template. Some, as noted in their descriptions, are Input information, sent from the User to the OASIS Node. The Response is generally a mirror of the Input, although in some Templates, the TSIP must add some information. 4.3.1 Template Summary The following table provides a summary of the process areas, and Templates to be used by Users to query information that will be downloaded or to upload information to the Primary Providers. These processes define the functions that must be supported by an OASIS Node. Process Area Process Name Template(s) S&CP Phase IA Version 1.2 May 27, 1998 38 4.3.2 Query/Response transofferin Query/Response of Transmission Capacity g Posted Services Offerings Being Offered Query/Response Ancillary ancoffering Service Offerings 4.3.3 Query/Response transserv Query/Response of Transmission Services Services Information Query/Response Ancillary ancserv Services 4.3.4 Query/Response schedule Query/Response of Transmission Schedules Schedules and Curtailments Query/Response curtail Curtailments 4.3.5 Query/Response List of list Query/Response of Sellers, Paths, PORs, Lists of PODs, Capacity Types, Information Ancillary Service Types, Templates 4.3.6 Query/Response Audit Log auditlog Query/Response of Audit Log 4.3.7 Purchase Request Purchase of transrequest Transmission Transmission Services Services (Input) Query/Response Status of transstatus Transmission Service Request Seller Approves Purchase transsell (Input) Customer Confirm/Withdraw transcust Purchase of Transmission Service (Input) Alternate POD/POR transalt Seller Reassign Rights transassign (Input) S&CP Phase IA Version 1.2 May 27, 1998 39 4.3.8 Seller Seller Post Transmission transpost Posting of Service for Sale (Input) Transmission Service Seller Modify (Remove) transupdate Transmission Service for Sale (Input) 4.3.9 Purchase of Request Purchase of ancrequest Ancillary Service Ancillary Service (Input) Query/Response Status of ancstatus Ancillary Service Request Seller Approves Purchase ancsell of Ancillary Service (Input) Customer Accept/Withdraw anccust Purchase of Ancillary Service (Input) S&CP Phase IA Version 1.2 May 27, 1998 40 4.3.10 Seller Seller Post Ancillary ancpost Post Ancillary Service (Input) Service Seller Modify (Remove) ancupdate Ancillary Service for Sale (Input) 4.3.11 Informal Post Want Ads (Input) messagepost Messages Query/Response Want Ads message Delete Want Ad (Input) messagedelet e Personnel Transfers personnel Discretion discretion Personnel Transfers personnel Standards of Conduct stdconduct 4.3.2 Query/Response of Posted Services Being Offered The following Templates define the information to be posted on services offered for sale. All discounts for service negotiated by a Customer and Primary Provider (as Seller) at a price less than the currently posted offering price shall be posted on OASIS in such a manner as to be viewed using these Templates. All secondary market and/or third-party posting and Primary Provider offerings for like services shall also be viewed using these templates. The Query must start with the standard header Query Variable Data Elements, listed in Section 4.2.6.2, and may include any valid combination of the remaining Query Variables, shown below in the Templates. START_TIME and STOP_TIME is the requested time interval for the Response to show all offerings which intersect that interval (see Section 4.2.6.6). TIME_OF_LAST_UPDATE can be used to specify all services updated since a specific point in time. Query variable listed with an asterix (*) can have at least 4 multiple instances defined by the user in making the query. In the Response, OFFER_START_TIME and OFFER_STOP_TIME indicate the "request time window" within which a customer must request a service in order to get the posted OFFER_PRICE. START_TIME and STOP_TIME indicate the time frame that the service is being offered for. The SERVICE_DESCRIPTION data element shall define any attributes and/or special terms and conditions applicable to the offering that are not listed under the standard SERVICE_DESCRIPTION associated with S&CP Phase IA Version 1.2 May 27, 1998 41 the product definition supplied in the transserv or ancserv templates. SERVICE_DESCRIPTION shall be null if there are no unique attributes or terms associated with the offering. 4.3.2.1 Transmission Capacity Offerings Available for Purchase (transoffering) Transmission Services Offerings Available for Purchase (transoffering) is used to offer transmission services that are posted for sale by the Primary Provider or Resellers. At a minimum this Template must be used to post TTC and each increment and type of service required by applicable regulations and the Primary Provider s tariffs. This Template must include, for each posted path, the Primary Provider's TTC, firm ATC and non-firm ATC, as required by FERC orders 888 and 889 (plus revisions) and/or if provided in the Primary Provider's tariff. Additional transmission services may be offered with the same Template. The POSTING_REF is set by the TSIP when an offering is posted and can be used in transrequests to refer to a particular offering. A User may query information about services available from all sellers for the time frame specified by the SERVICE_INCREMENT data element, namely, hourly, daily, weekly, monthly, or yearly. Template: transoffering 1. Query * PATH_NAME * SELLER_CODE * SELLER_DUNS * POINT_OF_RECEIPT * POINT_OF_DELIVERY * SERVICE_INCREMENT * TS_CLASS * TS_TYPE * TS_PERIOD START_TIME (of transmission services) STOP_TIME (of transmission services) POSTING_REF TIME_OF_LAST_UPDATE 2. Response The response is one or more records showing the requested service information. Note that the Customer will receive as a series of records spanning all the SELLER_CODEs, PATH_NAMEs, PORs, PODs, TS_xxx, and the START_TIME/STOP_TIME specified in the query. The SALE_REF S&CP Phase IA Version 1.2 May 27, 1998 42 is a value provided by the SELLER to identify the transmission service product being sold. The ANC_SVC_REQ indicates all ancillary services required for the specified transmission services. All Template elements are defined in the Data Element Dictionary. TIME_OF_LAST_UPDATE SELLER_CODE SELLER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY INTERFACE_TYPE OFFER_START_TIME OFFER_STOP_TIME START_TIME STOP_TIME CAPACITY SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS ANC_SVC_REQ SALE_REF POSTING_REF CEILING_PRICE OFFER_PRICE PRICE_UNITS SERVICE_DESCRIPTION (if null, then look at transserv) NERC_CURTAILMENT_PRIORITY OTHER_CURTAIMENT_PRIORITY SELLER_NAME SELLER_PHONE SELLER_FAX SELLER_EMAIL SELLER_COMMENTS 4.3.2.2 Ancillary Services Available for Purchase (ancoffering) Ancillary Services Available for Purchase (ancoffering) is used to provide information regarding the ancillary services that are available for sale by all sellers (both Primary Provider and Third Party Sellers). Template: ancoffering 1. Query * SELLER_CODE S&CP Phase IA Version 1.2 May 27, 1998 43 * SELLER_DUNS * CONTROL_AREA * SERVICE_INCREMENT * ANC_SERVICE_TYPE START_TIME STOP_TIME POSTING_REF TIME_OF_LAST_UPDATE 2. Response TIME_OF_LAST_UPDATE SELLER_CODE SELLER_DUNS CONTROL_AREA OFFER_START_TIME OFFER_STOP_TIME START_TIME STOP_TIME CAPACITY SERVICE_INCREMENT ANCILLARY_SERVICE_TYPE SALE_REF POSTING_REF CEILING_PRICE OFFER_PRICE PRICE_UNITS SERVICE_DESCRIPTION (if blank, then look at ancserv) SELLER_NAME SELLER_PHONE SELLER_FAX SELLER_EMAIL SELLER_COMMENTS 4.3.3 Query/Response of Services Information 4.3.3.1 Transmission Services (transserv) Transmission Services (transserv) is used to provide additional information regarding the transmission services SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, TS_WINDOW, NERC_CURTAIMENT_PRIORITY,and OTHER_CURTAIMENT_PRIORITY that are available for sale by a Provider in the Templates in Section 4.3.2. This Template is used to summarize Provider tariff information for the convenience of the User. The Provider also sets PRICE_UNITS with this Template. Template: transserv S&CP Phase IA Version 1.2 May 27, 1998 44 1. Query TIME_OF_LAST_UPDATE 2. Response TIME_OF_LAST_UPDATE SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS CEILING_PRICE PRICE_UNITS SERVICE_DESCRIPTION NERC_CURTAILMENT_PRIORITY OTHER_CURTAIMENT_PRIORITY TARIFF_REFERENCE 4.3.3.2 Ancillary Services (ancserv) Ancillary Services (ancserv) is used to provide additional information regarding the ancillary services that are available for sale by a Provider in the Templates in Section 4.3.2. This Template is used to summarize Provider tariff information for the convenience of the User. The Provider also sets PRICE_UNITS with this Template. Template: ancserv 1. Query TIME_OF_LAST_UPDATE 2. Response TIME_OF_LAST_UPDATE SERVICE_INCREMENT ANC_SERVICE_TYPE CEILING_PRICE PRICE_UNITS SERVICE_DESCRIPTION TARIFF_REFERENCE 4.3.4 Query/Response of Schedules and Curtailments 4.3.4.1 Hourly Schedule (schedule) Hourly Schedule (schedule) is used to show what a Provider's scheduled transmission capacity usage actually was for specific S&CP Phase IA Version 1.2 May 27, 1998 45 Paths. All the information provided is derived from that in the transmission reservation (see Template transstatus), except CAPACITY_SCHEDULED, which is the amount of the reservation which was scheduled. Posting of the schedules is organized around the transmission reservations, not the energy schedules. This may require the Primary Provider to map schedules back to the reservation. These records would have to be created for all reservations/schedules done off the OASIS during the operations scheduling period. Template: schedule 1. Query * PATH_NAME * SELLER_CODE * SELLER_DUNS * CUSTOMER_CODE * CUSTOMER_DUNS * POINT_OF_RECEIPT * POINT_OF_DELIVERY * SERVICE_INCREMENT * TS_CLASS * TS_TYPE * TS_PERIOD START_TIME STOP_TIME TIME_OF_LAST_UPDATE ASSIGNMENT_REF 2. Response TIME_OF_LAST_UPDATE SELLER_CODE SELLER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY CUSTOMER_CODE CUSTOMER_DUNS AFFILIATE_FLAG START_TIME (start time of schedule) STOP_TIME (stop time of schedule) CAPACITY (reserved) CAPACITY_SCHEDULED (total of energy scheduled for this customer for this reservation for this hour) SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS S&CP Phase IA Version 1.2 May 27, 1998 46 NERC_CURTAILMENT_PRIORITY OTHER_CURTAIMENT_PRIORITY ASSIGNMENT_REF (Last rights holder) 4.3.4.2 Curtailment/Interruption (curtail) Curtailment/Interruption (curtail) provides additional information about the actual curtailment of transmission reservations that have been scheduled for energy exchange. All fields are derived from the reservation except the CAPACITY_CURTAILED, CURTAILMENT_REASON and CURTAILMENT_OPTIONS. These fields provide information on the reasons for the curtailment, procedures to be followed and options for the Customer, if any, to relieve the curtailment. Template: curtail 1. Query * PATH_NAME * SELLER_CODE * SELLER_DUNS * CUSTOMER_CODE * CUSTOMER_DUNS * POINT_OF_RECEIPT * POINT_OF_DELIVERY * SERVICE_INCREMENT * TS_CLASS * TS_TYPE * TS_PERIOD START_TIME STOP_TIME TIME_OF_LAST_UPDATE ASSIGNMENT_REF 2. Response TIME_OF_LAST_UPDATE SELLER_CODE SELLER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY CUSTOMER_CODE CUSTOMER_DUNS AFFILIATE_FLAG START_TIME (Start time of curtailment) STOP_TIME (Stop time of curtailment) CAPACITY (Capacity reserved) CAPACITY_SCHEDULED CAPACITY_CURTAILED S&CP Phase IA Version 1.2 May 27, 1998 47 SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS NERC_CURTAILMENT_PRIORITY OTHER_CURTAIMENT_PRIORITY CURTAILMENT_REASON CURTAILMENT_PROCEDURES CURTAILMENT_OPTIONS ASSIGNMENT_REF 4.3.5 Query/Response of Lists of Information 4.3.5.1 List (list) List (list) is used to provide lists of valid names. The minimum set of lists is LIST, SELLER_CODEs, PATHs, PORs, PODs, SERVICE_INCREMENTs, TS_CLASSes, TS_TYPEs, TS_PERIODs, NERC_CURTAILMENT_PRIORITY, OTHER_CURTAILMENT_PRIORITY, ANCILLARY_SERVICE_TYPEs, CATEGORYs, and TEMPLATEs. These names may be used to query information, post or request services. Template: list 1. Query LIST_NAME TIME_OF_LAST_UPDATE 2. Response TIME_OF_LAST_UPDATE LIST_NAME LIST_ITEM LIST_ITEM_DESCRIPTION 4.3.6 Query/Response to Obtain the Audit log 4.3.6.1 Audit Log Information (auditlog) S&CP Phase IA Version 1.2 May 27, 1998 48 Audit Log Information (auditlog) is used to provide a means of accessing the required audit information. The TSIP will maintain two types of logs: a. Log of all changes to posted TS Information, such as CAPACITY. This log will record as a minimum the time of the change, the Template name, the name of the Template data element changed and the old and new values of the Template data element. b. A complete record of all transaction events, such as those contained in the Templates 4.3.8, 4.3.9 and 4.3.10. For transaction event logs, the response will include: TIME_STAMP, TEMPLATE, ELEMENT_NAME, AND NEW_DATA. In this case the value of OLD_DATA in not applicable. Template: auditlog 1. Query START_TIME (search against audit log) STOP_TIME (search against audit log) 2. Response ASSIGNMENT_REF or POSTING_REF TIME_STAMP TEMPLATE ELEMENT_NAME (for data elements whose values have changed) OLD_DATA NEW_DATA 4.3.7 Purchase Transmission Services The following Templates shall be used by Customers and Sellers to transact purchases of services. 4.3.7.1 Customer Capacity Purchase Request (transrequest) The Customer Capacity Purchase Request (Input) (transrequest) is used by the Customer to request the purchase of transmission services. The response simply acknowledges that the Customer's request was received by the OASIS Node. It does not imply that the Seller has received the request. Inputting values into the reference Data Elements is optional. S&CP Phase IA Version 1.2 May 27, 1998 49 CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. Supporting "profiles" of services, which request different capacities for different time periods within a single request, is at the discretion of the Primary Provider. Continuation records may be used to indicate requests for these service profiles. Only the following fields may be redefined in a continuation record for the transrequest Template: CAPACITY, BID_PRICE, START_TIME, and STOP_TIME. For requesting transmission services which include multiple paths, only the following fields may be redefined in a continuation record for the transrequest Template: PATH_NAME. Supporting multiple paths is at the discretion of the Provider. The START_TIME and STOP_TIME indicate the requested period of service. When the request is received at the OASIS Node, the TSIP assigns a unique ASSIGNMENT_REF value and queues the request with a time stamp. The STATUS for the request is QUEUED. Specification of a value YES in the PRECONFIRMED field authorizes the TSIP to automatically change the STATUS field in the transstatus Template to CONFIRMED when that request is ACCEPTED by the Seller. Template: transrequest 1. Input CONTINUATION_FLAG SELLER_CODE (Primary or Reseller) SELLER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK CAPACITY SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_SUBCLASS STATUS_NOTIFICATION START_TIME STOP_TIME BID_PRICE PRECONFIRMED ANC_SVC_LINK POSTING_REF (Optionally set by Customer) SALE_REF (Optionally set by Customer) REQUEST_REF (Optionally set by Customer) S&CP Phase IA Version 1.2 May 27, 1998 50 DEAL_REF (Optionally set by Customer) CUSTOMER_COMMENTS 2. Response (acknowledgment) RECORD_STATUS CONTINUATION_FLAG ASSIGNMENT_REF (assigned by TSIP) SELLER_CODE SELLER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK CAPACITY SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_SUBCLASS STATUS_NOTIFICATION START_TIME STOP_TIME BID_PRICE PRECONFIRMED ANC_SVC_LINK POSTING_REF SALE_REF REQUEST_REF DEAL_REF CUSTOMER_COMMENTS ERROR_MESSAGE 4.3.7.2 Status of Customer Purchase Request (transstatus) The Status of Customer Purchase Request (transstatus) is provided upon the request of any Customer or Provider to indicate the current status of one or more reservation records. Users may also view any transaction's status. Transmission Providers shall make source and sink information available at the time the request status posting is updated to show that a transmission request is confirmed. Only the following fields may be redefined in a continuation record for the transstatus response Template: PATH_NAME, CAPACITY, START_TIME, STOP_TIME, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME, and REASSIGNED_STOP_TIME. The AFFILIATE_FLAG will be set by the TSIP to indicate whether or not the Customer is an affiliate of the Primary Provider. The S&CP Phase IA Version 1.2 May 27, 1998 51 NEGOTIATED_PRICE_FLAG will be set by the TSIP to indicate whether the OFFER_PRICE is higher, lower, or the same as the BID_PRICE. Template: transstatus 1. Query * SELLER_CODE * SELLER_DUNS * CUSTOMER_CODE * CUSTOMER_DUNS * PATH_NAME * POINT_OF_RECEIPT * POINT_OF_DELIVERY * SERVICE_INCREMENT * TS_CLASS * TS_TYPE * TS_PERIOD * STATUS START_TIME (Beginning time of service) STOP_TIME START_TIME_QUEUED (Beginning time queue) STOP_TIME_QUEUED NEGOTIATED_PRICE_FLAG ASSIGNMENT_REF REASSIGNED_REF SALE_REF REQUEST_REF DEAL_REF TIME_OF_LAST_UPDATE 2. Response CONTINUATION_FLAG ASSIGNMENT_REF SELLER_CODE SELLER_DUNS CUSTOMER_CODE CUSTOMER_DUNS AFFILIATE_FLAG (Set by TSIP) PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK CAPACITY (total reservation) SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS S&CP Phase IA Version 1.2 May 27, 1998 52 NERC_CURTAILMENT_PRIORITY OTHER_CURTAIMENT_PRIORITY START_TIME STOP_TIME CEILING_PRICE OFFER_PRICE BID_PRICE PRECONFIRMED ANC_SVC_LINK ANC_SVC_REQ ALTERNATE_SERVICE_FLAG POSTING_REF SALE_REF REQUEST_REF DEAL_REF NEGOTIATED_PRICE_FLAG ("L" if Seller accepted Price is lower than OFFER_PRICE in transoffering Template; "H" if higher; otherwise blank) STATUS= RECEIVED, QUEUED, STUDY, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, DISPLACED, ANNULLED, RETRACTED STATUS_NOTIFICATION STATUS_COMMENTS TIME_QUEUED RESPONSE_TIME_LIMIT TIME_OF_LAST_UPDATE PRIMARY_PROVIDER_COMMENTS SELLER_COMMENTS CUSTOMER_COMMENTS SELLER_NAME SELLER_PHONE SELLER_FAX SELLER_EMAIL CUSTOMER_NAME CUSTOMER_PHONE CUSTOMER_FAX CUSTOMER_EMAIL REASSIGNED_REF REASSIGNED_CAPACITY (Capacity from each previous transaction) REASSIGNED_START_TIME REASSIGNED_STOP_TIME 4.3.7.3 Seller Approval of Purchase (transsell) Seller Approval of Purchase (Input) (transsell) is input by a Seller to modify the status and queue of a request by a Customer. If PRECONFIRMED then Seller can only change values of data elements, STATUS, STATUS_COMMENTS, SELLER_COMMENTS, REASSIGNED_REF, S&CP Phase IA Version 1.2 May 27, 1998 53 NEGOTIATED_PRICE_FLAG, ANC_SRV_REQ, REASSIGNED_START_TIME, REASSIGNED_STOP_TIME, and REASSIGNED_CAPACITY. If not PRECONFIRMED, then the Seller can also change OFFER_PRICE. Only the following fields may be redefined in a continuation record for the transsell Template: REASSIGNED_CAPACITY, OFFER_PRICE, REASSIGNED_REF, REASSIGNED_START_TIME, and REASSIGNED_STOP_TIME. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. The Seller may accept a reservation only when the BID_PRICE and the OFFER_PRICE are the same. Template: transsell 1. Input CONTINUATION_FLAG ASSIGNMENT_REF (Required) OFFER_PRICE STATUS= RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED, DISPLACED STATUS_COMMENTS OTHER_CURTAILMENT_PRIORITY (optional) ANC_SVC_REQ NEGOTIATED_PRICE_FLAG SELLER_COMMENTS RESPONSE_TIME_LIMIT REASSIGNED_REF REASSIGNED_CAPACITY (Previous capacity to be reassigned) REASSIGNED_START_TIME REASSIGNED_STOP_TIME 2. Response RECORD_STATUS CONTINUATION_FLAG ASSIGNMENT_REF OFFER_PRICE STATUS= RECEIVED, STUDY, OFFER, ACCEPTED, REFUSED, ANNULLED, RETRACTED, DISPLACED STATUS_COMMENTS OTHER_CURTAILMENT_PRIORITY ANC_SVC_REQ NEGOTIATED_PRICE_FLAG SELLER_COMMENTS RESPONSE_TIME_LIMIT REASSIGNED_REF REASSIGNED_CAPACITY (Previous capacity to be reassigned) S&CP Phase IA Version 1.2 May 27, 1998 54 REASSIGNED_START_TIME REASSIGNED_STOP_TIME ERROR_MESSAGE 4.3.7.4 Customer Confirmation of Purchase (Input) (transcust) Customer Confirmation of Purchase (Input) (transcust) is input by the Customer to state his agreement or withdrawal of a purchase after the Seller has indicated that the purchase request is approved. Only the BID_PRICE, STATUS, STATUS_COMMENTS, ANC_SVC_LINK, and CUSTOMER_COMMENTS data elements can be modified in this Template. CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. The Customer must change the BID_PRICE to be equal to the OFFER_PRICE for each record before the STATUS can be set to CONFIRMED. Template: transcust 1. Input CONTINUATION_FLAG ASSIGNMENT_REF (Required) REQUEST_REF DEAL_REF BID_PRICE STATUS= REBID, CONFIRMED, WITHDRAWN STATUS_COMMENTS ANC_SVC_LINK STATUS_NOTIFICATION If left blank, then original URL from the transrequest will be used CUSTOMER_COMMENTS 2. Response RECORD_STATUS CONTINUATION_FLAG ASSIGNMENT_REF REQUEST_REF DEAL_REF BID_PRICE STATUS= REBID, CONFIRMED, WITHDRAWN STATUS_COMMENTS ANC_SVC_LINK STATUS_NOTIFICATION CUSTOMER_COMMENTS ERROR_MESSAGE S&CP Phase IA Version 1.2 May 27, 1998 55 4.3.7.5 Alternate Point of Receipt/Delivery (transalt) Alternate Point of Delivery (transalt). The Customer may submit a request to use alternate points of receipt/delivery for an existing confirmed reservation, if allowed by applicable tariffs and service agreements. The assignment reference value associated with the prior confirmed reservation must be provided in the REASSIGNED_REF data element along with the alternate points of receipt/delivery. The request may be submitted as PRECONFIRMED. Requests submitted by the t r a nsalt template shall be handled by OASIS identically to reservations submitted using the transrequest template. CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. REASSIGNED_REF contains the ASSIGNMENT_REF of the original, confirmed reservation that is being designated to the alternate points of delivery/receipt. The Template allows for only one REASSIGNED_REF field. Therefore, if multiple, original reservations are being designated, a separate transalt Template must be submitted associated with each original reservation. There is no restriction that multiple submissions of the transalt Template may all refer back to the same, original reservation (i.e., may have the same REASSIGNED_REF). Demand profiles associated with the designation of alternate POD/POR may be submitted by additional records designating "Y" for CONTINUATION_FLAG, and specifying the CAPACITY, START_TIME, and STOP_TIME data elements corresponding to the MW demand being requested over each time interval associated with the reservation. The CAPACITY, START_TIME, and STOP_TIME data elements must fall within the amounts and time intervals associated with the original reservation. The following data elements in transstatus and the appropriate ones in transcust shall take on the following implied values: SELLER_CODE (value from SELLER_CODE in reservation designated by REASSIGNED_REF) SELLER_DUNS (value from SELLER_DUNS in reservation designated by REASSIGNED_REF) ALTERNATE_SERVICE_FLAG = YES OFFER_PRICE = $0 BID_PRICE = $0 CEILING_PRICE = $0 TS_CLASS = Non-Firm (or whatever the Provider designates) S&CP Phase IA Version 1.2 May 27, 1998 56 REASSIGNED_CAPACITY = MW capacity submitted in CAPACITY field of Template REASSIGNED_START_TIME = time submitted in START_TIME field of Template REASSIGNED_STOP_TIME = time submitted in STOP_TIME field of Template Template: transalt 1. Input CONTINUATION_FLAG PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK PRECONFIRMED CAPACITY (Must be less than or equal to original capacity reservation) STATUS_NOTIFICATION START_TIME (Valid only to hour and within the time of original reservation) STOP_TIME (Valid only to hour and within the time of original reservation) REQUEST_REF DEAL_REF REASSIGNED_REF (Assignment Reference for the Firm reservation being used for request) CUSTOMER_COMMENTS 2. Response (acknowledgment) RECORD_STATUS CONTINUATION_FLAG ASSIGNMENT_REF (assigned by the TSIP) SELLER_CODE (Primary) SELLER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK PRECONFIRMED ALTERNATE_SERVICE_FLAG (Defaulted to YES) CAPACITY (Capacity requested) STATUS_NOTIFICATION START_TIME S&CP Phase IA Version 1.2 May 27, 1998 57 STOP_TIME REQUEST_REF DEAL_REF REASSIGNED_REF (Assignment Reference for the Firm reservation being used for request) ERROR_MESSAGE 4.3.7.6 Seller to Reassign Service Rights to Another Customer (transassign) Seller to Reassign Service Rights to Another Customer (Input) (transassign) is used by the seller to ask the Transmission Services Information Provider to reassign some or all of the seller's rights to Services to another Customer, for seller confirmed transactions that have occurred off the OASIS. The TSIP shall assign a unique ASSIGNMENT_REF in the response (acknowledgment) and enter the status CONFIRMED as viewed in the transstatus Template. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Only the following fields may be redefined in a continuation record for the transassign input Template: CAPACITY, START_TIME, STOP_TIME, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME, and REASSIGNED_STOP_TIME. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Template: transassign 1. Input CONTINUATION_FLAG CUSTOMER_CODE CUSTOMER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK CAPACITY SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_SUBCLASS START_TIME STOP_TIME S&CP Phase IA Version 1.2 May 27, 1998 58 OFFER_PRICE ANC_SVC_LINK (optional: filled in if assignment is different than orginal transmission reservation) POSTING_NAME REASSIGNED_REF REASSIGNED_CAPACITY (Capacity being sold from each previous assignment) REASSIGNED_START_TIME REASSIGNED_STOP_TIME SELLER_COMMENTS 2. Response (acknowledgment) RECORD_STATUS CONTINUATION_FLAG ASSIGNMENT_REF (assigned by TSIP) CUSTOMER_CODE CUSTOMER_DUNS PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY SOURCE SINK CAPACITY (Total capacity being reassigned) SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_SUBCLASS START_TIME STOP_TIME OFFER_PRICE ANC_SVC_LINK POSTING_NAME REASSIGNED_REF REASSIGNED_CAPACITY (Capacity being sold from each previous assignment) REASSIGNED_START_TIME REASSIGNED_STOP_TIME SELLER_COMMENTS ERROR_MESSAGE 4.3.8 Seller Posting of Transmission Services Sellers shall use the following Templates for providing sell information. They may aggregate portions of several previous purchases to create a new service, if this capability is provided by the Transmission Services Information Provider: S&CP Phase IA Version 1.2 May 27, 1998 59 4.3.8.1 Seller Capacity Posting (transpost) Seller Capacity Posting (Input) (transpost) shall be used by the Seller to post the transmission capacity for resale on to the OASIS Node. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Template: transpost 1. Input PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY INTERFACE_TYPE CAPACITY SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS OTHER_CURTAILMENT_PRIORITY (optional) ANC_SVC_REQ START_TIME STOP_TIME OFFER_START_TIME OFFER_STOP_TIME SALE_REF OFFER_PRICE SERVICE_DESCRIPTION SELLER_COMMENTS 2. Response (Acknowledgment) RECORD_STATUS POSTING_REF (Assigned by TSIP) PATH_NAME POINT_OF_RECEIPT POINT_OF_DELIVERY INTERFACE_TYPE CAPACITY SERVICE_INCREMENT TS_CLASS TS_TYPE TS_PERIOD TS_WINDOW TS_SUBCLASS OTHER_CURTAILMENT_PRIORITY S&CP Phase IA Version 1.2 May 27, 1998 60 ANC_SVC_REQ START_TIME STOP_TIME OFFER_START_TIME OFFER_STOP_TIME SALE_REF OFFER_PRICE SERVICE_DESCRIPTION SELLER_COMMENTS ERROR_MESSAGE 4.3.8.2 Seller Capacity Modify (transupdate) Seller Capacity Modify (Input) (transupdate) shall be used by a Seller to modify a posting of transmission capacity. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Template: transupdate 1. Input POSTING_REF (Must be provided) CAPACITY (only if modified) START_TIME (only if modified) STOP_TIME (only if modified) OFFER_START_TIME (only if modified) OFFER_STOP_TIME (only if modified) ANC_SVC_REQ (only if modified) SALE_REF (only if modified) OFFER_PRICE (only if modified) SERVICE_DESCRIPTION (only if modified) SELLER_COMMENTS (only if modified) 2. Response (acknowledgment) RECORD_STATUS POSTING_REF CAPACITY START_TIME STOP_TIME OFFER_START_TIME OFFER_STOP_TIME ANC_SVC_REQ SALE_REF OFFER_PRICE SERVICE_DESCRIPTION SELLER_COMMENTS ERROR_MESSAGE S&CP Phase IA Version 1.2 May 27, 1998 61 4.3.9 Purchase of Ancillary Services 4.3.9.1 Customer Requests to Purchase Ancillary Services (ancrequest) Customer Requests to Purchase Ancillary Services (ancrequest) (Input, Template Upload) is used by the customer to purchase ancillary services that have been posted by a seller of those services. The same requirements exist for the use of STATUS_NOTIFICATION as for transrequest. The reference Data Elements are optional. CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. Template: ancrequest 1. Input SELLER_CODE SELLER_DUNS CONTROL_AREA CAPACITY SERVICE_INCREMENT ANC_SERVICE_TYPE STATUS_NOTIFICATION START_TIME STOP_TIME BID_PRICE PRECONFIRMED POSTING_REF (Optionally set by Customer) SALE_REF (Optionally set by Customer) REQUEST_REF (Optionally set by Customer) DEAL_REF (Optionally set by Customer) CUSTOMER_COMMENTS 2. Response (acknowledgment) RECORD_STATUS ASSIGNMENT_REF (assigned by TSIP) SELLER_CODE SELLER_DUNS CONTROL_AREA CAPACITY SERVICE_INCREMENT ANC_SERVICE_TYPE STATUS_NOTIFICATION START_TIME STOP_TIME S&CP Phase IA Version 1.2 May 27, 1998 62 BID_PRICE PRECONFIRMED POSTING_REF SALE_REF REQUEST_REF DEAL_REF CUSTOMER_COMMENTS ERROR_MESSAGE 4.3.9.2 Ancillary Services Status (ancstatus) Ancillary Services Status (ancstatus) is used to provide the status of purchase requests regarding the ancillary services that are available for sale by all Service Providers. The AFFILIATE_FLAG will be set by the TSIP to indicate whether or not the Customer is an affiliate of the Seller. The values of STATUS and processes for setting STATUS are the same as for transstatus. Template: ancstatus 1. Query * SELLER_CODE * SELLER_DUNS * CUSTOMER_CODE * CUSTOMER_DUNS CONTROL_AREA SERVICE_INCREMENT ANC_SERVICE_TYPE STATUS START_TIME STOP_TIME START_TIME_QUEUED STOP_TIME_QUEUED ASSIGNMENT_REF SALE_REF REQUEST_REF DEAL_REF TIME_OF_LAST_UPDATE (only if TIME_OF_LAST_UPDATE is posted by record) 2. Response ASSIGNMENT_REF SELLER_CODE SELLER_DUNS CUSTOMER_CODE S&CP Phase IA Version 1.2 May 27, 1998 63 CUSTOMER_DUNS AFFILIATE_FLAG (Set by TSIP) CONTROL_AREA CAPACITY SERVICE_INCREMENT ANC_SERVICE_TYPE START_TIME STOP_TIME CEILING_PRICE OFFER_PRICE BID_PRICE PRECONFIRMED POSTING_REF SALE_REF REQUEST_REF DEAL_REF NEGOTIATED_PRICE_FLAG ("L" if Seller accepted Price is lower than OFFER_PRICE in ancoffering Template; "H" if higher; otherwise blank) STATUS= QUEUED, RECEIVED, REBID, OFFER, ACCEPTED, REFUSED, CONFIRMED, WITHDRAWN, ANNULLED, RETRACTED STATUS_NOTIFICATION STATUS_COMMENTS TIME_QUEUED RESPONSE_TIME_LIMIT TIME_OF_LAST_UPDATE PRIMARY_PROVIDER_COMMENTS SELLER_COMMENTS CUSTOMER_COMMENTS SELLER_NAME SELLER_PHONE SELLER_FAX SELLER_EMAIL CUSTOMER_NAME CUSTOMER_PHONE CUSTOMER_FAX CUSTOMER_EMAIL 4.3.9.3 Seller Approves Ancillary Service (ancsell) Seller Approves Ancillary Service (ancsell) is used by the Seller to confirm acceptance after the Seller has approved the purchase of ancillary service. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Template: ancsell S&CP Phase IA Version 1.2 May 27, 1998 64 1. Input ASSIGNMENT_REF (Required) OFFER_PRICE STATUS= RECEIVED, OFFER, ACCEPTED, REFUSED STATUS_COMMENTS SELLER_COMMENTS 2. Response (acknowledgment) RECORD_STATUS ASSIGNMENT_REF OFFER_PRICE STATUS= RECEIVED, OFFER, ACCEPTED, REFUSED STATUS_COMMENTS NEGOTIATED_PRICE_FLAG RESPONSE_TIME_LIMIT SELLER_COMMENTS ERROR_MESSAGE 4.3.9.4 Customer accepts Ancillary Service (anccust) Customer accepts Ancillary Service (anccust) is used by the customer to confirm acceptance after the seller has approved the purchase of ancillary service. The Customer must change the BID_PRICE to be equal to the OFFER_PRICE before the STATUS can be set to CONFIRMED. CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. Template: anccust 1. Input ASSIGNMENT_REF (Required) REQUEST_REF DEAL_REF BID_PRICE STATUS= REBID, CONFIRMED, WITHDRAWN STATUS_COMMENTS STATUS_NOTIFICATION (If left blank, then the original URL from the ancrequest will be used CUSTOMER_COMMENTS 2. Response (Acknowledgment) RECORD_STATUS ASSIGNMENT_REF S&CP Phase IA Version 1.2 May 27, 1998 65 REQUEST_REF DEAL_REF BID_PRICE STATUS= REBID, CONFIRMED, WITHDRAWN STATUS_COMMENTS STATUS_NOTIFICATION CUSTOMER_COMMENTS ERROR_MESSAGE 4.3.10 Seller Posting of Ancillary Services 4.3.10.1 Seller Ancillary Services Posting (ancpost) Seller Ancillary Services Posting (ancpost) is used by the Seller to post information regarding the different services that are available for sale by third party Sellers of ancillary services. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Template: ancpost 1. Input CONTROL_AREA SERVICE_DESCRIPTION CAPACITY SERVICE_INCREMENT ANC_SERVICE_TYPE START_TIME STOP_TIME OFFER_START_TIME OFFER_STOP_TIME SALE_REF OFFER_PRICE SELLER_COMMENTS 2. Response (acknowledgment) RECORD_STATUS POSTING_REF (Assigned by TSIP) CONTROL_AREA SERVICE_DESCRIPTION CAPACITY SERVICE_INCREMENT ANC_SERVICE_TYPE START_TIME STOP_TIME OFFER_START_TIME OFFER_STOP_TIME S&CP Phase IA Version 1.2 May 27, 1998 66 SALE_REF OFFER_PRICE SELLER_COMMENTS ERROR_MESSAGE 4.3.10.2 Seller Modify Ancillary Services Posting (ancupdate) Seller Modify Ancillary Services Posting (ancupdate) is used by the Seller to modify posted information regarding ancillary services that are available for sale by a third party Seller. SELLER_CODE and SELLER_DUNS shall be determined from the registered connection used to input the request. Template: ancupdate 1. Input POSTING_REF (Required) CAPACITY (only if modified) SERVICE_DESCRIPTION (only if modified) START_TIME (only if modified) STOP_TIME (only if modified) OFFER_START_TIME (only if modified) OFFER_STOP_TIME (only if modified) SALE_REF (only if modified) OFFER_PRICE (only if modified) SELLER_COMMENTS (only if modified) 2. Response (acknowledgment) RECORD_STATUS POSTING_REF CAPACITY SERVICE_DESCRIPTION START_TIME STOP_TIME OFFER_START_TIME OFFER_STOP_TIME SALE_REF OFFER_PRICE SELLER_COMMENTS ERROR_MESSAGE 4.3.11 Informal Messages S&CP Phase IA Version 1.2 May 27, 1998 67 4.3.11.1 Provider/Customer Want Ads and Informal Message Posting Request (messagepost) Provider/Customer Want Ads and Informal Message Posting Request (messagepost) is used by Providers and Customers who wish to post a message. The valid entries for CATEGORY shall be defined by providers and shall be listed in the List of CATEGORY Template. One CATEGORY shall be DISCOUNT. All discount prices accepted by a Customer shall be immediately posted as a message using the DISCOUNT CATEGORY. This will permit carry-over from Phase 1. CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. Template: messagepost 1. Input SUBJECT CATEGORY VALID_FROM_TIME VALID_TO_TIME MESSAGE (must be specified) 2. Response (acknowledgment) RECORD_STATUS POSTING_REF (assigned by information provider) SUBJECT CATEGORY VALID_FROM_TIME VALID_TO_TIME MESSAGE ERROR_MESSAGE 4.3.11.2 Message (message) Message (message) is used to view a posted Want Ad or Informal Message. The CATEGORY data element can be queried. Specifically it shall be possible to query for the CATEGORY of DISCOUNT. This will permit carry-over from Phase 1. Template: message 1. Query CUSTOMER_CODE CUSTOMER_DUNS POSTING_REF S&CP Phase IA Version 1.2 May 27, 1998 68 CATEGORY VALID_FROM_TIME VALID_TO_TIME TIME_POSTED 2. Response CUSTOMER_CODE CUSTOMER_DUNS POSTING_REF SUBJECT CATEGORY VALID_FROM_TIME VALID_TO_TIME TIME_POSTED CUSTOMER_NAME CUSTOMER_PHONE CUSTOMER_FAX CUSTOMER_EMAIL MESSAGE 4.3.11.3 Provider/Sellers Message Delete Request (messagedelete) Provider/Sellers Message Delete Request (messagedelete) is used by Providers and Sellers who wish to delete their message. The POSTING_REF number is used to determine which message. CUSTOMER_CODE and CUSTOMER_DUNS shall be determined from the registered connection used to input the request. Template: messagedelete 1. Input POSTING_REF 2. Response (Acknowledgment) RECORD_STATUS POSTING_REF ERROR_MESSAGE 4.3.11.4 Personnel Transfers (personnel) Template: personnel 1. Query S&CP Phase IA Version 1.2 May 27, 1998 69 TIME_OF_LAST_UPDATE START_TIME_POSTED STOP_TIME_POSTED 2. Response POSTING_NAME EMPLOYEE_NAME FORMER_POSITION FORMER_COMPANY FORMER_DEPARTMENT NEW_POSITION NEW_COMPANY NEW_DEPARTMENT DATE_TIME_EFFECTIVE DATE_TIME_POSTED TIME_OF_LAST_UPDATE 4.3.11.5 Discretion (discretion) Template: discretion 1. Query START_TIME_POSTED STOP_TIME_POSTED START_TIME STOP_TIME SERVICE_TYPE SERVICE_NAME TIME_OF_LAST_UPDATE 2. Response POSTING_NAME RESPONSIBLE_PARTY_NAME (name of person granting discretion) SERVICE_TYPE (ancillary or transmission) SERVICE_NAME (make consistent with offering Templates) TARIFF_REFERENCE START_TIME STOP_TIME DISCRETION_DESCRIPTION TIME_POSTED TIME_OF_LAST_UPDATE 4.3.11.6 Standards of Conduct (stdconduct) S&CP Phase IA Version 1.2 May 27, 1998 70 Template: stdconduct 1. Query START_TIME_POSTED STOP_TIME_POSTED TIME_OF_LAST_UPDATE 2. Response POSTING_NAME RESPONSIBLE_PARTY_NAME STANDARDS_OF_CONDUCT_ISSUES TIME_POSTED TIME_OF_LAST_UPDATE 4.4 FILE REQUEST AND FILE DOWNLOAD EXAMPLES 4.4.1 File Example for Hourly Offering Example of the request to Primary Provider, aaa, and response for Seller, wxyz, for PATH_NAME "W/AAAA/PATH-ABC//" for April 10, 1996 from 8 a.m. to 3 p.m. (Note that the PATH_NAME consists of a REGION_CODE, PRIMARY_PROVIDER_CODE, PATH_CODE, and an OPTIONAL_CODE, separated with a slash, "/".) The VERSION for Phase 1A is 1.2. The request is in the form of a URL query string and the response is a ASCII delimited file. 1. Query http://(OASIS Node name)/OASIS/aaa/data/transoffering? ver=1.2&templ=transoffering& fmt=data&pprov=AAAA &pprovduns=123456789& path=W/AAA/ABC// &seller=WXYZAA &sellerduns=987654321& POR=aaa& POD=bbb& servincre=hourly& TSCLASS1=firm &TSCLASS2=non- firm&tz=PD&stime=19960410080000PD&sptime= 19960410150000PD 2. Response Data REQUEST-STATUS=2005 (Successful) TIME_STAMP=19960409113526PD 5 VERSION=1.25 TEMPLATE=transoffering5 OUTPUT_FORMAT=DATA 5 PRIMARY_PROVIDER_CODE=AAAA5 S&CP Phase IA Version 1.2 May 27, 1998 71 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=145 COLUMN_HEADERS=TIME_OF_LAST_UPDATE,SELLER_CODE,SELLER_DUNS,PATH_NAME , POINT_OF_RECEIPT,POINT_OF_DELIVERY,INTERFACE_TYPE,OFFER_START_TIME, OFFER_STOP_TIME, START_TIME,STOP_TIME, CAPACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, SALE_REF, POSTING_REF, CEILING_PRICE, OFFER_PRICE, PRICE_UNITS, SERVICE_DESCRIPTION,SELLER_NAME,SELLER_PHONE,SELLER_FAX, SELLER- EMAIL,SELLER_COMMENTS 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410080000PD,19960410090000PD,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A, A001, 1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410080000PD,19960410090000PD,300, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50, 1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410090000PD,1996041010000PD,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410090000PD,19960410100000PD,300, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50, 1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410100000PD,19960410110000PD,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410100000PD,19960410110000PD,300, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50, 1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410110000PD,19960410120000PD,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410110000PD,19960410120000PD,300, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50, 1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT 5 . . . . . . . . . 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410140000PD,19960410150000PD,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50,1.35,MW,N/A,N/A,N/A,N/A,N/A,10% DISCOUNT 5 19960409030000PD,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,19960402080000 PD,19960410080000PD,19960410140000PD,19960410150000PD,300, HOURLY, S&CP Phase IA Version 1.2 May 27, 1998 72 NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, N/A,A001,1.50, 1.35,MW,N/A,N/A,N/A,N/A,N/A, 10% DISCOUNT 5 4.4.2 File Example for Hourly Schedule Data This example shows a request for the hourly schedule data from Primary Provider, aaa, related to the seller, wxyz, for the period 10 a.m. to 3 p.m. on April 10, 1996. There are two identical requests examples using two slightly different methods. The first request is using a HTTP URL request string through an HTML GET method. The second request is a similar example using fetch_http from a file using a POST method. 1. Query URL Request (HTTP method=GET) http://(OASIS Node name)/OASIS/aaa/data/schedule? ver=1.0& pprov=AAAA& templ=schedule& fmt=data &pprovduns=123456789 &path=W/AAA/ABC//& seller=WXYZ &por=BBB &pod=CCC& tz=PD& stime=19960410100000PD& sptime=19960410150000PD URL Request (HTTP method=POST) $ fetch_http http://(OASIS Node name)/OASIS/aaa/data/OASISdata -f c:/OASIS/wxyz/upload/in-file.txt Where in-file.txt contains the following: ver=1.0& pprov=AAAA& templ=schedule& fmt=data &pprovduns=123456789 &path=W/AAA/ABC//& seller=WXYZ &por=BBB &pod=CCC& tz=PD& stime=19960410100000PD& sptime=19960410150000PD 2. Response Data REQUEST-STATUS=2005 TIME_STAMP=19960410114702PD5 VERSION=1.25 TEMPLATE=schedule5 OUTPUT_FORMAT=DATA 5 PRIMARY_PROVIDER_CODE=AAAA5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=55 COLUMN_HEADERS=TIME_OF_LAST_UPDATE,SELLER_CODE,SELLER_DUNS,PATH_NAME , POINT_OF_RECEIPT,POINT_OF_DELIVERY,CUSTOMER_CODE,CUSTOMER_DUNS, AFFILIATE_FLAG,START_TIME,STOP_TIME,CAPACITY,CAPACITY_SCHEDULED, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, ASSIGNMENT_REF5 S&CP Phase IA Version 1.2 May 27, 1998 73 19960409030000pd,wxyz,0987654321,W/AAA/ABC//,BBB,CCC,WXYZAA,09876543 22,Y, 19960410100000PD,19960410110000PD,300,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 8567435 . . . 5 . . . 5 19960409030000pd,wxyz,0987654321,W/AAA/ABC//,BBB,CCC,WXYZAA,09876543 22,Y, 19960410130000PD,19960410140000PD,300,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A,,8567435 19960409030000pd,wxyz,0987654321,W/AAA/ABC//,BBB,CCC,WXYZAA,09876543 22,Y, 19960410140000PD,19960410150000PD,300,300, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 8567435 4.4.3 Customer Posting a Transmission Service Offering This example shows how a Customer would post for sale the transmission service that was purchased previously. The Seller would create a file and upload the file using the FETCH_HTTP program to send a file to the OASIS node of the Primary Provider. 1. Input: VERSION=1.25 TEMPLATE=transpost5 OUTPUT_FORMAT=DATA 5 PRIMARY_PROVIDER_CODE=AAAA5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=15 COLUMN_HEADERS=PATH_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, INTERFACE_TYPE, CAPACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, START_TIME, STOP_TIME, OFFER_START_TIME, OFFER_STOP_TIME, SALE_REF, OFFER_PRICE, SERVICE_DESCRIPTION, SELLER_COMMENTPF5 WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,150, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A,, 19960402080000PD,19960410080000PD, 19960410080000PD,19960410150000PD, A123,.90,N/A,"As Joe said, ""It is a good buy"""5 FETCH_HTTP Command to send posting $ fetch_http http://(OASIS Node name)/OASIS/abcd/data/transrequest - f c:/OASIS/abcd/upload/post.txt 2. Response Data REQUEST-STATUS=200 5 (Successful) TIME_STAMP=19960409113526PD 5 VERSION=1.25 S&CP Phase IA Version 1.2 May 27, 1998 74 TEMPLATE=transpost5 OUTPUT_FORMAT=DATA 5 PRIMARY_PROVIDER_CODE=AAAA5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=15 COLUMN_HEADERS=RECORD_STATUS, PATH_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, INTERFACE_TYPE, CAPACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, START_TIME, STOP_TIME, OFFER_START_TIME, OFFER_STOP_TIME, SALE_REF, OFFER_PRICE, SERVICE_DESCRIPTION, SELLER_COMMENTS, ERROR_MESSAGE5 200,WXYZ,987654321,W/AAA/ABC//,N/A,N/A,E,150, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19960402080000PD,19960410080000PD, 19960410080000PD,19960410150000PD, A123,.90,N/A, "As Joe said, ""It is a good buy""", No Error5 4.4.4 Example of Re-aggregating Purchasing Services using Reassignment The following examples do not show the complete Template information, but only show those elements of the Template of interest to the example. a. Customer #1, "BestE" requests the purchase of 150 MW Firm ATC for 8 a.m. to 5 p.m. for $1.00 from a Primary Provider (transrequest). TEMPLATE=transrequest5 CUSTOMER_CODE=BestE5 CAPACITY=1505 TS_CLASS="FIRM"5 START_TIME="1996050708000000PD"5 STOP_TIME="1996050717000000PD"5 BID_PRICE="$1.00"5 The Information Provider assigns ASSIGNMENT_REF = 5000 on acknowledgment. b. Customer #1 purchases 120 MW ATC Non-firm for 3 p.m. to 9 p.m. for $.90 (transrequest). The Information Provider assigns the ASSIGNMENT_REF=5001 when the request for purchase is made and is shown in the acknowledgment. TEMPLATE="transrequest"5 CUSTOMER_CODE="BestE"5 CAPACITY=1205 TS_CLASS="NON-FIRM"5 START_TIME="1996050715000000PD"5 STOP_TIME="1996050721000000PD"5 BID_PRICE="$1.05"5 S&CP Phase IA Version 1.2 May 27, 1998 75 c Customer #1 becomes Seller #1 and post the Transmission service of 100 MW ATC Non-firm capacity from 8 a.m. to 9 p.m. for resale at $.90/MW-hour. TEMPLATE="transpost"5 SELLER_CODE="BestE"5 CAPACITY=1005 TS_CLASS="NON-FIRM"5 START_TIME="1996050708000000PD"5 STOP_TIME="1996050721000000PD"5 SALE_REF="BEST100"5 OFFER_PRICE=.905 SELLER_COMMENTS="aggregating two previous purchases"5 d. Customer #2 then requests purchase of 100 MW Non-firm from Reseller #1 from 8 a.m. to 6 p.m. for $0.90/MW-hour (transrequest). TEMPLATE="transrequest"5 CUSTOMER_CODE="Whlsle"5 SELLER_CODE="BestE"5 CAPACITY=1005 TS_CLASS="NON-FIRM"5 START_TIME="1996050708000000PD"5 STOP_TIME="1996050721000000PD"5 SALE_REF="BEST100"5 DEAL_REF="WPC100"5 BID_PRICE=.905 CUSTOMER_COMMENTS="Only need service until 6 p.m."5 The Information Provider provides the ASSIGNMENT_REF=5002 for this transaction. e. Seller informs the Information Provider of the reassignment of the previous transmission rights when the seller accepts the customer purchase request (transsell). TEMPLATE="transsell"5 CUSTOMER_CODE="Whlsle"5 SELLER_CODE="BestE"5 ASSIGNMENT_REF=50025 STATUS="Accepted"5 REASSIGNED_REF1=50005 REASSIGNED_CAPACITY1=1005 REASSIGNED_START_TIME1="199605070800PD"5 REASSIGNED_STOP_TIME1="199605071700PD"5 REASSIGNED_REF2=50015 REASSIGNED_CAPACITY2=1005 REASSIGNED_START_TIME2="199605071700PD"5 REASSIGNED_STOP_TIME2="199605071800PD"5 S&CP Phase IA Version 1.2 May 27, 1998 76 4.4.5 File Examples of the Use of Continuation Records a. Basic Continuation Records The first example of the use of Continuation Records is for the transrequest Template submitted by a Seller for purchase of a transmission reservation spanning 16 hours from 06:00 to 22:00 with "ramped" demand at beginning and end of time period. Two additional reservations appear prior to and following the profile to demonstrate the handling of ASSIGNMENT_REF by the OASIS node. Only the following fields may be redefined in a continuation record for the transrequest Template: CAPACITY, START_TIME, STOP_TIME. Specification of any values corresponding to COLUMN_HEADERs other than CAPACITY, START_TIME, and STOP_TIME will be ignored, however commas must be included to properly align the CAPACITY, START_TIME and STOP_TIME fields. Input: VERSION=1.25 TEMPLATE=transrequest5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=75 COLUMN_HEADERS=CONTINUATION_FLAG, SELLER_CODE, SELLER_DUNS, PATH_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, SOURCE, SINK, CAPACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, STATUS_NOTIFICATION, START_TIME, STOP_TIME, BID_PRICE, PRECONFIRMED, ANC_SVC_LINK, POSTING_REF, SALE_REF, REQUEST_REF, DEAL_REF, CUSTOMER_COMMENTS5 N, AEP, 123456789, ABC/XY, CE, MECS, , , 35, DAILY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A,, pub/AEP/incoming, 19970423000000ES, 19970424000000ES, 24.50, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, Standard daily reservation5 N, AEP, 123456789, ABC/XY, CE, AMPO, , , 5, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, pub/AEP/incoming, 19970423060000ES, 19970423070000ES, 2.50, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, First piece of profile spanning 5 records5 Y, , , , , , , , 10, , , , , , , 19970423070000ES, 19970423080000ES, , , , , , , , ,Second piece5 Y, , , , , , , , 15, , , , , , , 19970423080000ES, 19970423200000ES, , , , , , , , ,Third piece5 Y, , , , , , , , 10, , , , , , , 19970423200000ES, 19970423210000ES, , , , , , , , ,Fourth piece5 Y, , , , , , , , 5, , , , , , , 19970423210000ES, 19970423220000ES, , , , , , , , ,Fifth piece5 S&CP Phase IA Version 1.2 May 27, 1998 77 N, AEP, 123456789, ABC/XY, CE, MECS, , , 20, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, pub/AEP/incoming, 19970423040000ES, 19970423160000ES, 2.00, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, Standard hourly reservation after profiled reservation5 Response: REQUEST_STATUS=2005 TIME_STAMP=19970422160523ES5 TEMPLATE=transrequest5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=75 COLUMN_HEADERS=RECORD_STATUS, CONTINUATION_FLAG, SELLER_CODE, SELLER_DUNS, PATH_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, SOURCE, SINK, CAPACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, STATUS_NOTIFICATION, START_TIME, STOP_TIME, BID_PRICE, PRECONFIRMED, ANC_SVC_LINK, POSTING_REF, SALE_REF, REQUEST_REF, DEAL_REF, CUSTOMER_COMMENTS, ERROR_MESSAGE5 200, N, AEP, 123456789, ABC/XY, CE, MECS, , , 35, DAILY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, pub/AEP/incoming, 19970423000000ES, 19970424000000ES, 24.50, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, Standard daily reservation, No error5 200, N, AEP, 123456789, ABC/XY, CE, AMPO, , , 5, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, pub/AEP/incoming, 19970423060000ES, 19970423070000ES, 2.50, Y,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, First piece of profile spanning 5 records, No error5 200, Y, , , , , , , , 10, , , , , , , 19970423070000ES, 19970423080000ES, , , , , , , , , Second piece, No error5 200, Y, , , , , , , , 15, , , , , , , 19970423080000ES, 19970423200000ES, , , , , , , , , Third piece, No error5 200, Y, , , , , , , , 10, , , , , , , 19970423200000ES, 19970423210000ES, , , , , , , , , Fourth piece, No error5 200, Y, , , , , , , , 5, , , , , , , 19970423210000ES, 19970423220000ES, , , , , , , , , Fifth piece, No error5 200, N, AEP, 123456789, ABC/XY, CE, MECS, , , 20, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, pub/AEP/incoming, 19970423040000ES, 19970423160000ES, 2.00, Y, SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), P0123 , S123, R765, D123, Standard hourly reservation after profiled reservation, No error5 b. Submission of Reassignment Information - Case 1: In the prior example, a reservation request was submitted to "Rseler" for 20MW of Hourly Non-firm service from 04:00 to 16:00. Assume that Rseler has previously reserved service for the CE-VP path for Daily Firm in amount of 50 MW on 4/23 under S&CP Phase IA Version 1.2 May 27, 1998 78 ASSIGNMENT_REF=7019, and Hourly Non-Firm in amount of 10 MW from 08:00 to 20:00 on 4/23 under ASSIGNMENT_REF=7880. Rseler must designate which transmission service rights are to be reassigned to Cust to satisfy the 20MW from 04:00 to 16:00. This reassignment information is conveyed by Rseler using the transsell Template when the reservation request is ACCEPTED. At the SELLER's discretion, rights are assigned from the Non-firm reservation first (ASSIGNMENT_REF=7880) with the balance taken up by the Firm reservation (ASSIGNMENT_REF=7019). The only fields allowed in "continuation" records for transsell Template are REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , and REASSIGNED_STOP_TIME. Price may not be negotiated for each "segment" in a capacity profile. Input: VERSION=1.25 TEMPLATE=transsell5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=35 COLUMN_HEADERS=CONTINUATION_FLAG, ASSIGNMENT_REF, OFFER_PRICE, STATUS, STATUS_COMMENTS, ANC_SVC_LINK, SELLER_COMMENTS, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , REASSIGNED_STOP_TIME N, 8236, 2.00, ACCEPTED, Status comments here,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(custR234); SU:(cust:R345), Seller comments here, 7019, 20, 19970423040000ES, 19970423080000ES5 Y, , , , , , , 7880, 10, 19970423080000ES, 19970423160000ES5 Y, , , , , , , 7019, 10, 19970423080000ES, 19970423160000ES5 Response: VERSION=1.25 TEMPLATE=transsell5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=35 COLUMN_HEADERS=RECORD_STATUS, CONTINUATION_FLAG, ASSIGNMENT_REF, OFFER_PRICE, STATUS, STATUS_COMMENTS, ANC_SVC_LINK, SELLER_COMMENTS, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , REASSIGNED_STOP_TIME, ERROR_MESSAGE5 200, N, 8236, 2.00, ACCEPTED, Status comments here,SC:(cust:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); SP:(cust:R234); SU:(cust:R345), Seller comments here, 7019, 20, 19970423040000ES, 19970423080000ES,5 200, Y, , , , , , , 7880, 10, 19970423080000ES, 19970423160000ES,5 200, Y, , , , , , , 7019, 10, 19970423080000ES, 19970423160000ES,5 S&CP Phase IA Version 1.2 May 27, 1998 79 c. Submission of Reassignment Information - Case 2: Primary provider, AEP, is notified of a sale/assignment of transmission service rights from "Resell" to "cust". The parameters of the new reservation are for 10MW on 4/23 for "off-peak" hours (00:00-06:00 and 22:00-24:00) on POR/POD CE-VP. Rseler is assigning rights to 10MW from a prior reservation for the CE-VP path for Daily Firm in amount of 50 MW on 4/23 under ASSIGNMENT_REF=7019 to Cust. AEP would submit the following information using the transassign Template to post this (re)sale. The only fields allowed in "continuation" records for the transassign Template are CAPACITY, START_TIME , STOP_TIME , REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , and REASSIGNED_STOP_TIME. Even though there is a one-to-one correspondence between the segments of the new reservations and the reassignment of service from a prior reservation, it is entirely possible that a reservation spanning a single contiguous period would require multiple continuation records to convey reassignment information, and vice versa. Fields for CUSTOMER_NAME and SELLER_NAME were used to convey user names for subsequent resolution of contact information from user registration. Input: VERSION=1.25 TEMPLATE=transassign5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=25 COLUMN_HEADERS=CONTINUATION_FLAG, CUSTOMER_CODE, CUSTOMER_DUNS, P A T H_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, SOURCE, SINK, C A PACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, T S _SUBCLASS, START_TIME, STOP_TIME, OFFER_PRICE, SALE_REF, P O S T I N G _ N A M E , REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , REASSIGNED_STOP_TIME , SELLER_COMMENTS5 N, Resler, 456123789, Cust, 987654321, , CE, VP, , , 10, HOURLY, N O N-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19970423000000ES, 19970423060000ES, 2.00, Joe Smith, Jane Doe , N, 19970422121354ES, , 7019, 10, 19970423000000ES, 19970423060000ES, Seller comments go here5 Y, , , , , , , , , , 10, , , , , , 19970423220000ES, 1 9 970424000000ES, , , , , , , 7019, 10, 19970423220000ES, 19970424000000ES 5 Response: S&CP Phase IA Version 1.2 May 27, 1998 80 REQUEST_STATUS=2005 TIME_STAMP=19970422144520ES5 VERSION=1.25 TEMPLATE=transassign5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=25 COLUMN_HEADERS=RECORD_STATUS, CONTINUATION_FLAG, ASSIGNMENT_REF, S E L L ER_CODE, SELLER_DUNS, CUSTOMER_CODE, CUSTOMER_DUNS, A F FILIATE_FLAG, PATH_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, S O URCE, SINK, CAPACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, START_TIME, STOP_TIME, OFFER_PRICE, SELLER_NAME, CUSTOMER_NAME, TIME_QUEUED, SALE_REF, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , REASSIGNED_STOP_TIME , SELLER_COMMENTS, ERROR_MESSAGE5 200, N, 8207, Rseler, 456123789, Cust, 987654321, N, , CE, VP, , , 10, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19970423000000ES, 19970423060000ES, 2.00, Joe Smith, Jane Doe , 19970422121354ES, , 7019, 10, 19970423000000ES, 19970423060000ES, Seller comments go here,5 200, Y, , , , , , , , , , , , 10, , , , , , 19970423220000ES, 1 9 9 7 0 424000000ES, , , , , , 7019, 10, 19970423220000ES, 19970424000000ES, ,5 d. Query of Transmission Reservation Status: The following typical response to a transstatus query might be delivered for 4/23 based on prior examples. Note that the only fields returned in "continuation" records are, CAPACITY, START_TIME , S T O P _TIME , REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , and REASSIGNED_STOP_TIME (price fields are debatable). Input: Response: REQUEST_STATUS=2005 TIME_STAMP=19970423040523ES5 TEMPLATE=transstatus5 OUTPUT_FORMAT=DATA5 PRIMARY_PROVIDER_CODE=AEP5 PRIMARY_PROVIDER_DUNS=1234567895 DATA_ROWS=115 C O LUMN_HEADERS= CONTINUATION_FLAG, ASSIGNMENT_REF, SELLER_CODE, SELLER_DUNS, CUSTOMER_CODE, CUSTOMER_DUNS, AFFILIATE_FLAG, P A T H_NAME, POINT_OF_RECEIPT, POINT_OF_DELIVERY, SOURCE, SINK, S&CP Phase IA Version 1.2 May 27, 1998 81 C A PACITY, SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, TS_SUBCLASS, START_TIME , STOP_TIME, CEILING_PRICE, OFFER_PRICE, BID_PRICE, PRECONFIRMED, ANC_SVC_LINK, ALTERNATE_SERVICE_FLAG, POSTING_REF, SALE_REF, REQUEST_REF, DEAL_REF, NEGOTIATED_PRICE_FLAG, STATUS, STATUS_COMMENTS, TIME_QUEUED, TIME_OF_LAST_UPDATE, PRIMARY_PROVIDER_COMMENTS, SELLER_COMMENTS, CUSTOMER_COMMENTS, SELLER_NAME, SELLER_PHONE, SELLER_FAX, SELLER_EMAIL, CUSTOMER_NAME, CUSTOMER_PHONE, CUSTOMER_FAX, CUSTOMER_EMAIL, REASSIGNED_REF, REASSIGNED_CAPACITY, REASSIGNED_START_TIME , REASSIGNED_STOP_TIME5 N, 8207, Rseler, 456123789, ACust, 987654321, N, , CE, VP, , , 10, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19970423000000ES, 1 9 9 7 0 4 2 3 0 6 0 0 0 0 E S , 2 . 2 5 , 2.00, 6.20, N , S C : ( c u s t:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); S P : ( custR234); SU:(cust:R345),N, , , , , N, CONFIRMED, , 19970422121354ES, , TP Comments, Seller comments go here, Customer comments, Joe Smith, (888)-123-4567, (888)-123-1231, jsmith@xyz.com, J a n e Doe, (999)-123-4567, (999)-123-8823, , 7019, 10, 19970423000000ES, 19970423060000ES 5 Y, , , , , , , , , , , , ,10, , , , , , 19970423220000ES, 19970424000000ES, , , , , , , , , , , , , , , , , , , , , , 7019, 10, 19970423220000ES, 19970424000000ES5 N, 8234, Rseler, 456123789, ACust, 987654321, N, , CE, MECS, , , 35 D A ILY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19970423000000ES, 1 9 9 7 0 4 2 3 0 6 0 0 0 0 E S , 4 2 . 00, 24.50, 24.50, N , S C : ( c u s t:SP);RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); S P : ( custR234); SU:(cust:R345),N, , , , , N, CONFIRMED, , 19970422121354ES, , Standard daily reservation, System Operator, Customer comments, Frank Orth, (999)-123-4567, (999)-123-1231, jsmith@xyz.com, Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 10, 19970423000000ES, 19970423060000ES 5 N, 8235, AEP, 123456789, Cust, 987654321, N, , CE, AMPO, , , 5, HOURLY, NON-FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19970423060000ES, 1 9 9 7 0 4 2 3 0 7 0 0 0 0 E S , 2.50, 2.50, 6.20, N, S C : ( c u s t : S P );RV:(cust:SP);RF(cust:RQ); EI:(cust:R123); S P : ( custR234); SU:(cust:R345),N, , , , , N, CONFIRMED, , 1 9 9 70422160523ES, , Profile verified, First piece, Customer c o mments, System Operator, (888)-123-4567, (888)-123-1231, jsmith@xyz.com, Jane Doe, (999)-123-4567, (999)-123-8823, , 7019, 10, 19970423000000ES, 19970423060000ES 5 Y, , , , , , , , , , , , ,10, , , , , , , 19970423070000ES, 19970423080000ES, , , , , , , , , , , , , , , , , , , , , , , , , 5 Y, , , , , , , , , , , , ,15, , , , , , ,19970423080000ES, 19970423200000ES, , , , , , , , , , , , , , , , , , , , , , , , , 5 Y, , , , , , , , , , , , ,10, , , , , , , 19970423200000ES, 19970423210000ES, , , , , , , , , , , , , , , , , , , , , , , , , 5 Y, , , , , , , , , , , , ,5, , , , , , 19970423210000ES, 19970423220000ES, , , , , , , , , , , , , , , , , , , , , , , , , 5 N, 8236, Rseler, 456123789, Cust, 987654321, N, , CE, VP, , , 20, HOURLY, FIRM, POINT_TO_POINT, OFF_PEAK, N/A, 19970424040000ES, 19970424160000ES, 2.00, 2.50, 6.20, N, , , ,,, CONFIRMED, , 19970422160523ES, , Bid price refused, Negotiated OFFER_PRICE accepted, Joe Smith, (888)-123-4567, (888)-123-1231, jsmith@xyz.com, S&CP Phase IA Version 1.2 May 27, 1998 82 J a n e Doe, (999)-123-4567, (999)-123-8823, , 7019, 20, 19970423040000ES, 19970423080000ES5 Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 7880, 10, , , , , , 19970423080000ES, 19970423160000ES5 Y, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 7019, 10, , , , , , 19970423080000ES, 19970423160000ES5 4.4.6 Example of Negotiation of Price 4.4.6.1 Negotiation with Preconfirmation a. The Customer submits a PRECONFIRMED transmission service request using the transrequest Template. Initially, the STATUS is set to QUEUED by OASIS. b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED, STUDY, ACCEPTED, or REFUSED. Since the request is PRECONFIRMED, the Seller is blocked from altering OFFER_PRICE by OASIS, and blocked from setting status to OFFER. c. If the Seller sets STATUS to ACCEPTED, OASIS will immediately set STATUS to CONFIRMED and sets the OFFER_PRICE to the BID_PRICE. d. The Customer may WITHDRAW request via transcust Template at any time up to point where the Seller sets STATUS to ACCEPTED. e. Once the STATUS is CONFIRMED, the OFFER_PRICE officially becomes the terms of the reservation. 4.4.6.2 Negotiations without Preconfirmation e. The Customer submits a transmission reservation request with the BID_PRICE less than the CEILING_PRICE via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS. b. The Seller has the option of setting the STATUS via the transsell Template to one of the following: RECEIVED, STUDY, ACCEPTED, OFFER, or REFUSED. c. The Seller determines that the BID_PRICE is too low, sets the OFFER_PRICE to the price he wants, and sets the STATUS to OFFER via the transsell Template. S&CP Phase IA Version 1.2 May 27, 1998 83 d. The Customer agrees to the OFFER_PRICE, sets the BID_PRICE equal to the OFFER_PRICE, and sets the STATUS to CONFIRMED via the transcust Template. e. The OFFER_PRICE with the STATUS of CONFIRMED locks in the terms of the reservation. 4.4.6.3 Multiple Step Negotiations a. The Customer submits a transmission reservation request with the BID_PRICE less than the CEILING_PRICE via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS. b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED, STUDY, ACCEPTED, OFFER, or REFUSED. c. The Seller determines that the BID_PRICE is too low, sets the OFFER_PRICE to the desired value, and sets the STATUS to OFFER via the transsell Template. d. The Customer responds to the new OFFER_PRICE with an updated BID_PRICE and sets the STATUS to REBID for re-evaluation by the Seller. e. The Seller determines that the BID_PRICE now is acceptable and sets the STATUS to ACCEPTED via the transsell Template. The transition to ACCEPTED state requires the OFFER_PRICE to be set to the BID_PRICE: accepting a reservation with an OFFER_PRICE different from BID_PRICE would require the STATUS be set to OFFER rather than ACCEPTED (see item c). f. The Customer agrees to the OFFER_PRICE and sets the STATUS to CONFIRM via the transcust Template. g. The OFFER_PRICE with the STATUS as CONFIRMED locks in the terms of the reservation. 4.4.6.4 Negotiations Refused by Seller a. The Customer submits a transmission reservation request with the BID_PRICE less than the CEILING_PRICE via the transrequest Template. Initially the STATUS is set to QUEUED by OASIS. S&CP Phase IA Version 1.2 May 27, 1998 84 b. The Seller has the option of setting the STATUS via the transsell Template to one of the following: RECEIVED, STUDY, ACCEPTED, OFFER, or REFUSED. c. The Seller determines that the BID_PRICE is too low, sets OFFER_PRICE to his desired value, and sets STATUS to OFFER via the transsell Template. d. The Customer responds to OFFER_PRICE with updated BID_PRICE and sets the STATUS to REBID via the transcust Template for re-evaluation by Seller. e. The Seller breaks off all further negotiations by setting the STATUS to REFUSED. 4.4.6.5 Negotiations Withdrawn by Customer a. The Customer submits a transmission reservation request with the BID_PRICE less than the CEILING_PRICE via the transrequest. Initially the STATUS is set to QUEUED by OASIS. b. The Seller has the option of setting STATUS via the transsell Template to one of the following: RECEIVED, STUDY, ACCEPTED, OFFER, or REFUSED. c. The Seller determines that the BID_PRICE is too low, sets the OFFER_PRICE to his desired value, and sets the STATUS to OFFER via the transsell Template. d. The Customer responds to the OFFER_PRICE with an updated BID_PRICE and sets the STATUS to REBID for re-evaluation by Seller. S&CP Phase IA Version 1.2 May 27, 1998 85 e. The Seller determines that the BID_PRICE is still too low, sets the OFFER_PRICE to another value, and sets STATUS to OFFER via the transsell Template. f. The Customer breaks off all further negotiations by setting STATUS to WITHDRAWN (or the customer/seller could go through additional iterations of REBID/OFFER until negotiations are broken off or the reservation is CONFIRMED). 4.5 INFORMATION SUPPORTED BY WEB PAGE There shall be a Web page on each OASIS node with information on requesting the text file of the tariffs and service agreements. 5. PERFORMANCE REQUIREMENTS A critical aspect of any system is its performance. Performance encompasses many issues, such as security, sizing, response to user requests, availability, backup, and other parameters that are critical for the system to function as desired. The following sections cover the performance requirements for the OASIS. 5.1 SECURITY Breaches of security include many inadvertent or possibly even planned actions. Therefore, several requirements shall be implemented by the TSIPs to avoid these problems: a. Provider Update of TS Information: Only Providers, including Secondary Providers, shall be permitted to update their own TS Information. b. Customer Input Only ASCII Text: TSIPs shall be permitted to require that inputs from Customers shall be filtered to permit only strict ASCII text (strip bit 8 from each byte). S&CP Phase IA Version 1.2 May 27, 1998 86 c. Provider Updating Over Public Facilities: If public facilities are involved in the connection between a Provider and the OASIS Node, the Provider shall be able to update his TS Information only through the use of ASCII or through encrypted files. d. User Registration and Login: All Users shall be required to register and login to a Provider's Account before accessing that Provider's TS Information. e. User Passwords: All Users shall enter their personal password when they wish access to TS Information beyond the lowest Access Privilege. f. Service Request Transactions: Whenever Service Request transactions are implemented entirely over the OASIS, both an individual Customer password for the request, and an individual Provider password for the notification of acceptance shall be required. g. Data Encryption: Sophisticated data encryption techniques and the "secure id" mechanisms being used on the public Internet shall be used to transfer sensitive data across the Internet and directly between OASIS Nodes. h. Viruses: Since only data is being transmitted between the OASIS Nodes and the Users, viruses are unlikely to be passed between them. Therefore, TSIPs shall be responsible for ensuring that the OASIS Nodes are free from viruses, but need not screen data exchanges with Users for viruses. i. Performance Log: TSIPs shall keep a log on User usage of OASIS resources. j. Disconnection: TSIPs shall be allowed to disconnect any User who is degrading the performance of the OASIS Node through the excessive use of resources, beyond what is permitted in their Service Level Agreement. k. Premature Access: The TSIP log shall also be used to ensure that Users who are affiliated with the Provider's company (or any other User) do not have access to TS information before it is publicly available. l. Firewalls: TSIPs shall employ security measures such as firewalls to minimize the possibility that unauthorized S&CP Phase IA Version 1.2 May 27, 1998 87 users shall access or modify TS Information or reach into Provider or User systems. Interfaces through Public Data Networks or the Internet shall be permitted as long as these security requirements are met. m. Certificates and Public Key Standards (optional): Use of alternative forms of login and authentication using certificates and public key standards is acceptable. 5.2 ACCESS PRIVILEGES Users shall be assigned different Access Privileges based on external agreements between the User and the Provider. These Access Privileges are associated with individual Users rather than just a company, to ensure that only authorized Users within a company have the appropriate access. The following Access Privileges shall be available as a minimum: a. Access Privilege Read-Only: The User may only read publicly available TS Information. b. Access Privilege for Transactions: The Customer is authorized to transact Service Requests. c. Access Privilege Read/Write: A Secondary Provider shall have write access to his own Provider Account on an OASIS Node. 5.3 OASIS RESPONSE TIME REQUIREMENTS TSIPs can only be responsible for the response capabilities of two portions of the Internet-based OASIS network: The response capabilities of the OASIS Node server to process interactions with Users The bandwidth of the connection(s) between the OASIS Node server and the Internet. Therefore, the OASIS response time requirements are as follows: a. OASIS Node Server Response Time: The OASIS Node server shall be capable of supporting its connection(s) to S&CP Phase IA Version 1.2 May 27, 1998 88 Users with an average aggregate data rate of at least "A" bits per second. "A" is defined as follows: * A = N R bits/sec where: N = 5% of registered Customers. and R = 28,800 bits/sec per Customer. b. OASIS Node Network Connection Bandwidth: The bandwidth "B" of the OASIS Node connection(s) to the Internet shall be at least: * B = 2 A bits/sec c. Time to Meet Response Requirements: The minimum time responses shall be met within 1 month of User registration for any single new User. If more than 10 new Users register in one month, 2 months lead time shall be permitted to expand/ upgrade the OASIS Node to meet the response requirements. 5.4 OASIS PROVIDER ACCOUNT AVAILABILITY The following are the OASIS Provider Account availability requirements: a. OASIS Provider Account Availability: The availability of each OASIS Provider account on an OASIS Node shall be at least 98.0% (downtime of about 7 days per year). Availability is defined as: % Availability = (1 - Cumulative Provider Account Downtime) * 100 Total Time A Provider account shall be considered to be down, and downtime shall be accumulated, upon occurrence of any of the following: 1. One or more Users cannot link and log on to the Provider account. The downtime accumulated shall be calculated as: * for affected Users of 1/n (Login Time), which is the time used by each affected User to try to link and log on to the Provider account, and where "n" is the total number of Users actively registered for that Provider account. S&CP Phase IA Version 1.2 May 27, 1998 89 2. One or more Users cannot access TS Information once they have logged on to a Provider account. The downtime accumulated shall be calculated as: * for affected Users of 1/n (Access Time), which is the time used by each affected User to try to access data, and where "n" is the total number of Users actively registered for that Provider. 3. A five (5) minute penalty shall be added to the cumulative downtime for every time a User loses their connection to a Provider's account due to an OASIS Node momentary failure or problem. 5.5 BACKUP AND RECOVERY The following backup and recovery requirements shall be met: a. Normal Backup of TS Information: Backup of TS Information and equipment shall be provided within the OASIS Nodes so that no data or transaction logs are lost or become inaccessible by Users due to any single point of failure. Backed up data shall be no older than 30 seconds. Single points of failure include the loss of one: Disk drive or other storage device Processor Inter-processor communications (e.g. LAN) Inter-OASIS communications Software application Database Communication ports for access by Users Any other single item which affects the access of TS Information by Users b. Spurious Failure Recovery Time: After a spurious failure situation, all affected Users shall regain access to all TS Information within 30 minutes. A spurious failure is a temporary loss of services which can be overcome by rebooting a system or restarting a program. S&CP Phase IA Version 1.2 May 27, 1998 90 Permanent loss of any physical component is considered a catastrophic failure. c. Long-Term Backup: Permanent loss of critical data due to a catastrophic failure shall be minimized through off-line storage on a daily basis and through off-site data storage on a periodic basis. d. Catastrophic Failure Recovery: Recovery from a catastrophic failure or loss of an OASIS Node may be provided through the use of alternate OASIS Nodes which meet the same availability and response time requirements. TSIPs may set up prior agreements with other TSIPs as to which Nodes will act as backups to which other Nodes, and what procedure will be used to undertake the recovery. Recovery from a catastrophic failure shall be designed to be achieved within 24 hours. 5.6 TIME SYNCHRONIZATION The following are the time requirements: a. Time Synchronization: Time shall be synchronized on OASIS Nodes such that all time stamps will be accurate to within "0.5 second of official time. This synchronization may be handled over the network using NTP, or may be synchronized locally using time standard signals (e.g. WWVB, GPS equipment). b. Network Time Protocol (NTP): OASIS Nodes shall support the Internet tool for time synchronization, Network Time Protocol (NTP), which is described in RFC- 1305, version 3, so that Users shall be able to request the display and the downloading of current time on an OASIS Node for purposes of user applications which might be sensitive to OASIS time. 5.7 TS INFORMATION TIMING REQUIREMENTS The TS Information timing requirements are as follows, except they are waived during emergencies. a. TS Information Availability: The most recent Provider TS information shall be available on the OASIS S&CP Phase IA Version 1.2 May 27, 1998 91 Node within 5 minutes of its required posting time at least 98% of the time. The remaining 2% of the time the TS Information shall be available within 10 minutes of its scheduled posting time. b. Notification of Posted or Changed TS Information: Notification of TS Information posted or changed by a Provider shall be made available within 60 seconds to the log. c. Acknowledgment by the TSIP: Acknowledgment by the TSIP of the receipt of User Purchase requests shall occur within 1 minute. The actual negotiations and agreements on Purchase requests do not have time constraints. 5.8 TS INFORMATION ACCURACY The following requirements relate to the accuracy of the TS information: a. TS Information Reasonability: TS information posted and updated by the Provider shall be validated for reasonability and consistency through the use of limit checks and other validation methods. b. TS Information Accuracy: Although precise measures of accuracy are difficult to establish, Providers shall use their best efforts to provide accurate information. 5.9 PERFORMANCE AUDITING The following are the performance auditing requirements: a. User Help Desk Support: TSIPs shall provide a "Help Desk" that is available at least during normal business hours (local time zone) and normal work days. b. Monitoring Performance Parameters: TSIPs shall use their best efforts to monitor performance parameters. Any User shall be able to read or download these performance statistics. S&CP Phase IA Version 1.2 May 27, 1998 92 5.10 MIGRATION REQUIREMENTS Whenever a new version of the S&CP is to be implemented, a migration plan will be developed for cutting over to the new version. S&CP Phase IA Version 1.2 May 27, 1998 93 Appendix A Data Element Dictionary May 27, 1998 Version 1.2 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters AFFILIATE_FLAG AFFLAG 1{ALPHANUMERIC}3 Valid Values Set to YES if customer is an YES affiliate of the provider NO ANC_SERVICE_TYPE ANCTYPE 1{ALPHANUMERIC}2 Valid types EI - Energy Imbalance 0 EI SP - Spinning Reserve SP SU - Supplemental Reserve SU RV - Reactive supply and RV Voltage Control RF RF- Regulation and Frequency SC response {Registered SC- Scheduling, system Control } and Dispatch {Registered} must be registered with www.tsin.com and listed in the ANCSERV template S&CP Phase IA, Version 1.2 May 27, 1998 A-1 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters ANC_SVC_LINK ANCSVCLI 1{ALPHANUMERIC}3 Formatted string The method for linking NK 00 as follows: ancillary services to a SC:(AA); RV: transmission service request. (AA); RF: The provider and capacity of (AA[:xxx[:yyy[:n each ancillary service is nn]]]); EI: identified using the formatted (AA[:xxx[:yyy[:n string: nn]]]); SC:(AA); RV: (AA); RF: SP: (AA[:xxx[:yyy[:nnn]]]); EI: (AA[:xxx[:yyy[:n (AA[:xxx[:yyy[:nnn]]]); nn]]]); SU: SP: (AA[:xxx[:yyy[:nnn]]]); SU: (AA[:xxx[:yyy[:n (AA[:xxx[:yyy[:nnn]]]); nn]]]); {Registered}:(AA[:xxx[:yyy[:nnn {Registered}:(AA ]]]) [:xxx[:yyy[:nnn] where AA is the appropriate ]]) PRIMARY_PROVIDER_CODE, SELLER_CODE, or CUSTOMER_CODE, and represents the company providing the ancillary services. "AA" may be unspecified for "xxx" type identical to "FT", in which case the ":" character must be present and precede the "FT" type. If multiple "AA" terms are necessary, then each "AA" grouping will be enclosed within parenthesis, with the overall group subordinate to the ANC_SVC_TYPE specified S&CP Phase IA, Version 1.2 May 27, 1998 A-2 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters ANC_SVC_REQ ANCSVCRE 1{ALPHANUMERIC}1 EI:{M,R,O,U}; Ancillary services required for Q 00 SP:{M,R,O,U}; a transmission services SU:{M,R,O,U}; offering. The appropriate RV:{M,R,O,U}; letter {M,R,O,U} will be RF:{M,R,O,U}; assigned to each of the six SC:{M,R,O,U}; Proforma FERC ancillary {registered}:{M, services (see R,O,U} ANC_SERVICE_TYPE), where the letters mean the following: (M) Mandatory, which implies that the Primary Provider must provide the ancillary service (R) Required, which implies that the ancillary service is required, but not necessarily from the Primary Provider (O) Optional, which implies that the ancillary service is not necessarily required, but could be provided (U) Unknown, which implies that the requirements for the ancillary service are not known at this time S&CP Phase IA, Version 1.2 May 27, 1998 A-3 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters ALTERNATE_SERVICE_ ALTSVCFL 2{ALPHANUMERIC}3 Defaulted to Used as a flag to identify FLAG G YES this reservation as a NON-FIRM use of FIRM transmission services on an alternate point of delivery. ASSIGNMENT_REF AREF 1{ALPHANUMERIC}1 Unique value A unique reference number 2 assigned by a Transmission Information Provider to provide a unique record for each transmission or ancillary service request. A single transmission or ancillary service request will be over a contiguous time period, i.e. from a START_TIME to an STOP_TIME. BID_PRICE BIDPR 1{NUMERIC}5 + Positive number The current bid price of a . with 2 decimals Service in dollars and cents. + 2{NUMERIC}2 Used by Customers to designate a price being bid. S&CP Phase IA, Version 1.2 May 27, 1998 A-4 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters CAPACITY CAP 1{NUMERIC}12 Non-negative Transfer capability is the number in units measure of the ability of the of MW interconnected electric system to readily move or transfer power from one area to another over all transmission lines (or paths) between those areas under specified system conditions. In this context "area" may be an individual electric system, powerpool, control area, subregion, or NERC region or portion thereof. CAPACITY_CURTAILED CAPCUR 1{NUMERIC}12 Non-negative The amount of transfer number in units capability curtailed by the of MW Primary provider for emergency reasons CAPACITY_SCHEDULED CAPSCH 1{NUMERIC}12 Non-negative Transfer capability scheduled number in units on each path of MW CATEGORY CAT 1{ALPHANUMERIC}2 Valid name from A name to be used to categorize 5 CATEGORY in LIST messages. Valid names would Template include: Discount, Want-Ad, Curtailment, Outage, Oasis Maint Notice CEILING_PRICE CEILPR 1{NUMERIC}5 + Positive number Ceiling price of the Service as . with 2 decimals entered by the Transmission + 2{NUMERIC}2 Provider. S&CP Phase IA, Version 1.2 May 27, 1998 A-5 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters COLUMN_HEADERS HEADERS 1{ALPHANUMERIC}L Headers Example: imited to all surrounded with COLUMN_HEADER=APATH_NAME","POIN the elements A and separated T_OF_RECEIPT","POINT_OF_DELIVER names in one by commas. Y","SOURCE","SINK" Template Limited to valid Template element names. Must use full element name and not alias. CONTINUATION_FLAG CONT 1{ALPHANUMERIC}1 "Y" or "N" Indicates whether or not this record is a continuation from the previous record CONTROL_AREA AREA 1{ALPHANUMERIC}2 Valid name of a A part of the power system with 0 control area metered tie lines and capable of matching generation and load while meeting scheduled interchange. Location of Ancillary Services is my CONTROL_AREA. CURTAILMENT_OPTION CUROPT 1{ALPHANUMERIC}8 Free form text Customer options, if any, to S 0 avoid curtailment CURTAILMENT_ CURPROC 1{ALPHANUMERIC}8 Free form text Curtailment procedures to be PROCEDURES 0 followed in the event of a curtailment CURTAILMENT_REASON CURREAS 1{ALPHANUMERIC}8 Free-form text Reason for curtailment of 0 service. S&CP Phase IA, Version 1.2 May 27, 1998 A-6 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters CUSTOMER_CODE CUST 1{ALPHANUMERIC}6 Unique value, Any entity (or its designated registered on agent) that is eligible to view TSIN.COM OASIS information, to execute a service agreement, and/or to receive transmission service. CUSTOMER_COMMENTS CUSTCOM 1{ALPHANUMERIC} Free-form text Informative text. 80 CUSTOMER_DUNS CUSTDUNS 9{NUMERIC}9 Unique DUNS Unique DUNS number for a number Customer CUSTOMER_EMAIL CUSTEMAI 1{ALPHANUMERIC}2 Valid Internet Internet E-Mail address of L 5 E-Mail address Customer contact person CUSTOMER_FAX CUSTFAX 14{ALPHANUMERIC} Area code and FAX phone number of Customer 20 telephone contact person number, plus any extensions (aaa)-nnn-nnnn xnnnn CUSTOMER_NAME CUSTNAME 1{ALPHANUMERIC}2 Free form text Name of Customer contact person 5 CUSTOMER_PHONE CUSTPHON 14{ALPHANUMERIC} Area code and Telephone of Customer contact 20 telephone person number, plus any extensions (aaa)-nnn-nnnn xnnnn S&CP Phase IA, Version 1.2 May 27, 1998 A-7 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters DATA_ROWS ROWS 1{NUMERIC} Positive Number Number of records (rows) of unlimited data exclusive of header information that are to be uploaded or downloaded in a file. DATE_TIME_EFFECTIV TIMEEFCT 16{ALPHANUMERIC} Valid date and Date and time a message or E 16 time in seconds service offer is in effect yyyy+mo+dd+hh +mm+ss+tz DATE_TIME_POSTED TIMEPSTD 16{ALPHANUMERIC} Valid date and Date and time to seconds a 16 time in seconds message or service offered was yyyy+mo+dd+hh posted +mm+ss+tz DEAL_REF DREF 1{ALPHANUMERIC}1 Unique value, The unique reference assigned 2 Assigned by by a Customer to two or more Customer service purchases to identify each of them as related to others in the same power service deal. These requests may be related to each other in time sequence through a single Provider, or as a series of wheels through multiple Providers, or a combination of both time and wheels. The User uses the DEAL_REF to uniquely identify a combination of requests relating to a particular deal. S&CP Phase IA, Version 1.2 May 27, 1998 A-8 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters DISCRETION_DESCRIP 0{ALPHANUMERIC}1 Free form text A detailed description of the TION DISCDESC 000 discretion being reported ELEMENT_NAME ELEMENT 1{ALPHANUMERIC}4 Valid Template Template element name as 0 element name indicated in data dictionary EMPLOYEE_NAME EMPNAME 1{ALPHANUMERIC}2 Free form text Name of person who is 5 transferring from one position to another ERROR_MESSAGE ERROR 1{ALPHANUMERIC}2 Free form text Error message related to a 50 RECORD_STATUS or REQUEST_STATUS FORMER_COMPANY FORMCO 1{ALPHANUMERIC}2 Free form text Former company of the person 5 who is transferring FORMER_DEPARTMENT FORMDEPT 1{ALPHANUMERIC}2 Free form text Former department of the person 5 who is transferring FORMER_POSITION FORMPOS 1{ALPHANUMERIC}2 Free form text Former position held by the 5 person who is transferring INTERFACE_TYPE INTERFAC 1{ALPHANUMERIC}1 I,E Type of interface define by E path: Internal (I) to a control area or External (E) to a control area LIST_ITEM ITEM 1{ALPHANUMERIC}5 Free form text Item from list, such as list of 0 SELLERs, list of PATHs, list of PORs, list of PODs, Lists of SERVICE_INCREMENT, TS_CLASS, TS_TYPE, TS_PERIOD, NERC_CURTAILMENT_PRIORITY, OTHER_CURTAILMENT_PRIORITY, SERVICE_INCREMENT, CATEGORY List of TEMPLATEs S&CP Phase IA, Version 1.2 May 27, 1998 A-9 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters LIST_ITEM_DESCRIPT ITEMDESC 0{ALPHANUMERIC}1 Free form text A detailed description of the ION 00 LIST_ITEM LIST_NAME LIST 1{alphanumeric}2 LIST, SELLER, List of valid names for each of 5 PATH, POR, POD, the types of lists. The minimum SERVICE_INCREMEN set of lists defined must be T, TS_CLASS, implemented. TS_TYPE, TS_PERIOD, TS_SUBCLASS, ANCILLARY_SERVIC E_TYPE, CATEGORY, TEMPLATE MESSAGE MSG 1{ALPHANUMERIC}2 Free form text An informative text message 00 NEGOTIATED_PRICE_F NGPRIFLG 1{ALPHANUMERIC}1 H, L, or blank Set to H if OFFER_PRICE is LAG higher than the currently posted price; set to L if OFFER_PRICE is lower than the currently posted price NERC_CURTAILMENT_P NERCURT 1{NUMERIC}1 Integer 1-7 One of the NERC seven RIORITY curtailment priorites, documented in LIST templat NEW_COMPANY NEWCO 1{ALPHANUMERIC}2 Free form text New company of the person who 5 is transferring NEW_DATA NEWDATA 1{ALPHANUMERIC}2 Any valid date For audit log, the new updated 00 element value value of a Template data element after update. S&CP Phase IA, Version 1.2 May 27, 1998 A-10 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters NEW_DEPARTMENT NEWDEPT 1{ALPHANUMERIC}2 Free form text New department of the person 5 who is transferring NEW_POSITION NEWPOS 1{ALPHANUMERIC}2 Free form text New position held by the person 5 who is transferring OFFER_PRICE OFFPR 1{NUMERIC}5 + Positive number The current offered price of a . with 2 decimals Service in dollars and cents. + 2{NUMERIC}2 Used by the Seller to indicate the offering price. OFFER_START_TIME OFFSTIME 16{ALPHANUMERIC} Valid Date and Start time of the window 16 Time to seconds: during which a Customer may request a discounted offer. yyyy+mo+dd+hh +mm+ss+tz OFFER_STOP_TIME OFFSPTIM 16{ALPHANUMERIC} Valid Date and Stop time of the window during E 16 Time to seconds: which a Customer may request a discounted offer. (Expiration yyyy+mo+dd+hh time of an offer) +mm+ss+tz OLD_DATA OLDDATA 1{ALPHANUMERIC}2 Any valid data For audit log, the old value of 00 element value a Template data element prior to being updated. This element is not applicable in the audit log for transaction events. OPTIONAL_CODE N/A 0{ALPHANUMERIC}2 Unique path name OPTIONAL_CODE - 25 chars, 5 within region unique for Path. If used for directionality, then the first 12 characters shall represent POR, followed by >->, followed by 12 characters which shall represent POD. Used by PATH_NAME. S&CP Phase IA, Version 1.2 May 27, 1998 A-11 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters OTHER_CURTAILMENT_ OTHCUR 0{ALPHANUMERIC}8 Free form tect Other than NERC curtailment PRIORITY priorities, such as regional curtailment priorities. Suggested format region+number, for example MAPP4, WSCC7. Documented in LIST template. OUTPUT_FORMAT FMT 4{ALPHANUMERIC}4 HTML, DATA Format of response: HTML = hypertext markup language for presentation using a web browser DATA = text for use in a downloaded file. PATH_CODE N/A 0{ALPHANUMERIC}1 Unique code for Unique code within a Region for 2 each path as each path. Used by PATH_NAME defined by primary provider S&CP Phase IA, Version 1.2 May 27, 1998 A-12 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters PATH_NAME PATH 5{ALPHANUMERIC}5 Unique value The unique name assigned to a 0 single transmission line or the set of one or more parallel transmission lines whose power transfer capabilities are strongly interrelated and must be determined in aggregate. These lines are typically described as being on a path, corridor or interconnection in some regions, or as crossing an interface or cut-plane in other regions. Multiple lines may be owned by different parties and require prorating of capability shares. The name is constructed from the following codes, with each code separated by a "/". Trailing / may be omitted, if there are no values for OPTION_CODE and SPARE_CODE: REGION_CODE - 2 chars, unique to OASIS System PRIMARY_PROVIDER_CODE - 4 chars, unique within Region PATH_CODE - 12 chars, unique for Primary Provider OPTIONAL_CODE - 25 chars, unique for Path. If used for directionality, then the first S&CP Phase IA, Version 1.2 May 27, 1998 A-13 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters POINT_OF_DELIVERY POD 1{ALPHANUMERIC}1 Unique value Point of Delivery is one or 2 within Primary more point(s) of Provider interconnection on the Transmission Provider's transmission system where capacity and/or energy transmitted by the Transmission Provider will be made available to the Receiving Party. This is used along with Point of Receipt to define a Path and direction of flow on that path. For internal paths, this would be a specific location(s) in the area. For an external path, this may be an area-to-area interface. S&CP Phase IA, Version 1.2 May 27, 1998 A-14 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters POINT_OF_RECEIPT Unique value Point of Receipt is one or more POR 1{ALPHANUMERIC}1 within Primary point(s) of interconnection on 2 Provider the Transmission Provider's transmission system where capacity and/or energy transmitted will be made available to the Transmission Provider by the Delivering Party. This is used along with Point of Delivery to define a Path and direction of flow on that path. For internal paths, this would be a specific location(s) in the area. For an external path, this may be an area-to-area interface. POSTING_NAME POSTNAME 1{ALPHANUMERIC}2 Free form text Name of person who is posting 5 the information on the OASIS POSTING_REF POSTREF 1{ALPHANUMERIC}1 Unique Value Assigned by TSIP when Service 2 or Message is received by TSIP. Unique number can be used by the user to modify or delete the posting. PRECONFIRMED PRECONF 2{ALPHA}3 YES or NO Used by Customer to preconfirm sale in Template transrequest or ancrequest. If customer indicates sale is preconfirmed, then the response is YES and the customer does not need to confirm the sale. S&CP Phase IA, Version 1.2 May 27, 1998 A-15 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters PRICE_UNITS UNITS 1(ALPHA)20 Free form text The units used for CEILING_PRICE, OFFER_PRICE, and BID_PRICE. Examples: $/MWhr, $/MWmonth PRIMARY_PROVIDER_ PPROVCOM 1{ALPHANUMERIC} Free-form text Informative text. Usually COMMENTS 80 entered by the Primary Provider through a back end system. PRIMARY_PROVIDER_C PROVIDER 1{ALPHANUMERIC}4 Unique code Unique code for each Primary ODE Provider. Used by PATH_NAME and in URL. Registered as part of URL at www.tsin.com. PRIMARY_PROVIDER_D PPROVDUN 9{NUMERIC}9 Valid DUNS Unique code for each Primary. UNS S number Provided by Dun and Bradstreet. REASSIGNED_CAPACIT RASCAP 1{NUMERIC}12 Positive number, The amount of transfer Y cannot exceed capability that was reassigned previous from one entity to another. assigned capacity S&CP Phase IA, Version 1.2 May 27, 1998 A-16 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters REASSIGNED_REF REREF 1{ALPHANUMERIC}1 Unique value When customer makes a purchase 2 of a transmission service that was posted for resale and a new ASSIGNMENT_REF number is issued the previous ASSIGNMENT_REF number now becomes the REASSIGNMENT_REF. Also used by SELLER when posting transmission or ancillary services for resale to show the previous assignment reference number. Also used by the customer when making a request to use FIRM service as NON-FIRM over alternate points of delivery. REASSIGNED_START_T RESSTIME 16ALPHANUMERIC}1 Valid date and Beginning date and time of the IME 6 time to seconds: reassigned transmission service yyyy+mo+dd+hh+tz REASSIGNED_STOP_TI RESSPIME 16{ALPHANUMERIC} Valid date and Date and time of the end of the ME 16 time to hour: transmission service that is reassigned to another User. yyyy+mo+dd+hh+tz RECORD_STATUS Record status indicating record RECSTATU 1{NUMERIC}3 Error number was successful or error code if S unsuccessful. 200 = Successful S&CP Phase IA, Version 1.2 May 27, 1998 A-17 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters REGION_CODE N/A 1{ALPHANUMERIC}2 Unique within Defined for NERC regions, with OASIS System the following defined: E - ECAR I - MAIN S - SERC T - ERCOT A - MAPP P - SPP M - MAAC N - NPCC W - WSCC Second character or digit reserved for subregion id as defined by each region. REQUEST_REF RREF 1{ALPHANUMERIC}1 Unique value A reference uniquely assigned 2 by a Customer to a request for service from a Provider. REQUEST_STATUS 1{NUMERIC}3 Error number Message status indicating RSTATUS message was successful (if all RECORD_STATUS show success) or error code if any RECORD_STATUS showed unsuccessful. 200 = Successful RESPONSE_TIME_LIMI RESPTL 16{ALPHANUMERIC} Valid date and Date and time to seconds by T 16 time to seconds: when a response must be received from a Customer yyyy+mo+dd+hh +mm+ss+tz RESPONSIBLE_PARTY_ PARTNAME 1{ALPHANUMERIC}2 Free form text The name of the person NAME 5 responsible for granting the discretion. S&CP Phase IA, Version 1.2 May 27, 1998 A-18 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters RETURN_TZ TZ 2{ALPHANUMERIC}2 AD, AS, PD, PS, A time zone code, indicating ED, ES, MD, MS, the base time zone, and whether CD,CS, UT daylight saving time is to be used. This field may be set by a Customer in a query. Returned date and time data is converted to this time zone. SALE_REF SREF 1{ALPHANUMERIC}1 Unique value Identifier which is set by 2 seller (including Primary Provider) when posting a service for sale SELLER_CODE SELLER 1{ALPHANUMERIC}6 Unique value Organization name of Primary Provider or Reseller. SELLER_COMMENTS SELCOM 1{ALPHANUMERIC} Free-form text Informative text provided by 80 the Seller SELLER_DUNS SELDUNS 9{NUMERIC}9 Valid DUNS Unique Data Universal Numbering number System provided by Dun and Bradstreet. Code for a Primary Provider or Seller. SELLER_EMAIL SELEMAIL 5{ALPHANUMERIC}6 Valid network E-Mail address of Seller 0 reference contact person SERVICE_INCREMENT Valid increments SRVINCR 1{ALPHANUMERIC}8 The transmission service HOURLY increments provided. Five are Daily pre-defined, while additional Weekly increments can be used if they Monthly are registered on TSIN.COM and Yearly shown in the Provider's LIST {Registered} template S&CP Phase IA, Version 1.2 May 27, 1998 A-19 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters SELLER_FAX SELFAX 14{ALPHANUMERIC} Area code and The fax telephone number for 20 telephone contact person at Seller. number, plus any extensions Example: (aaa)- nnn-nnnn xnnnn SELLER_NAME SELNAME 1{ALPHANUMERIC}2 Free form text The name of an individual 5 contact person at the Seller. SELLER_PHONE SELPHONE 14{ALPHANUMERIC} Area code and The telephone number of a 20 telephone contact person as a Seller number, plus any extensions (aaa)-nnn-nnnn xnnnn SERVICE_DESCRIPTIO SVCDESC 1{ALPHANUMERIC} Free-form text Information regarding a N 200 service. SERVICE_NAME SVCNAME 1{ALPHANUMERIC} Free-form text Name of service affected by the 25 discretionary action SERVICE_TYPE SVCTYPE 1{ALPHANUMERIC} Free-form text Type of service affected by the 25 discretionary action. SINK SINK 0{ALPHANUMERIC}1 Valid area The area in which the SINK is 4 name located. SOURCE SOURCE 0{ALPHANUMERIC}1 Valid area The area in which the SOURCE is 4 name located. SPARE_CODE N/A 0{ALPHANUMERIC}3 Defined by Spare code to be used at a region later time. Used by PATH_NAME S&CP Phase IA, Version 1.2 May 27, 1998 A-20 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters STANDARDS_OF_CONDU STDISSUE 0{ALPHANUMERIC}2 Free-form text Issues that were in violation CT_ISSUES 00 of the FERC Standards of Conduct START_TIME STIME 16{ALPHANUMERIC} Valid Date and Start date and clock time of a 16 Time to seconds: service. When used as a query variable, it requires the yyyy+mo+dd+hh return of all items whose Stop +mm+ss+tz time is after the Start time. Note that for some Templates when used as a query variable the time may be only valid up to the hour, day or month. If more data is given than is valid, the hour, day or month will be used to make the date and time inclusive, i.e. date or time will be truncated to valid hour, day or month. START_TIME_POSTED STIMEP 16{ALPHANUMERIC} Valid Date and Query parameter to indicate all 16 Time to seconds: the records are to be retrieved that were posted on or after yyyy+mo+dd+hh this time. +mm+ss+tz START_TIME_QUEUED STIMEQ 16{ALPHANUMERIC} Valid Date and Start date and clock time of a 16 Time to seconds: service, used for requesting transactions queued after this yyyy+mo+dd+hh time +mm+ss+tz S&CP Phase IA, Version 1.2 May 27, 1998 A-21 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters STATUS STATUS 5{ALPHANUMERIC}2 Valid field QUEUED = initial status 5 (QUEUED, assigned by TSIP on RECEIVED, STUDY, receipt of "customer REBID, OFFER, capacity purchase ACCEPTED, request" REFUSED, RECEIVED = reassigned by TP CONFIRMED, to acknowledge WITHDRAWN, QUEUED requests DISPLACED, and indicate the ANNULLED, service request RETRACTED) is being evaluated STUDY= assigned by TP to indicate some level of study is required or being performed to evaluate service request OFFER= assigned by TP to indicate that a OFFER_PRICE is being proposed REBID= assigned by S&CP Phase IA, Version 1.2 May 27, 1998 A-22 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters STATUS_COMMENTS STACOM 1{ALPHANUMERIC} Free form text Informative text. 80 STATUS_NOTIFICATIO STATNOT 1{ALPHANUMERIC} http://URL:portn The STATUS_NOTIFICATION data N 200 umber/direcotry/ element shall contain the cgi script/query protocol field "http:", which parameters designates the notification or method/protocol to be used, Mailto: location information required; the target domain name and port designations shall be inserted into the notification URL based on the Customer's Company registration information. The resource location information may include directory information, cgi script identifiers and URL encoded query string name/value pairs as required by the Customer's application. or mailto and email address for the status information the Customer wants to receive upon a change in STATUS of transstatus, or ancstatus S&CP Phase IA, Version 1.2 May 27, 1998 A-23 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters STOP_TIME SPTIME 16{ALPHANUMERIC} Valid date and Stop date and clock time. When 16 time used as a query variable, it yyyy+mo+dd+hh requires the return of all +mm+ss+tz items which start before the Stop time. Note that for some Templates when used as a query variable the time may be only valid up to the hour, day or month. If more data is given than is valid, the hour, day or month will be used to make the date and time inclusive, i.e. date or time will be increased to include STOP_TIME. STOP_TIME_POSTED STPTIMEP 16{ALPHANUMERIC} Valid Date and Query parameter to indicate all 16 Time to seconds: the records are to be retrieved that were posted on or before yyyy+mo+dd+hh this time. +mm+ss+tz STOP_TIME_QUEUED SPTIMEQ 16{ALPHANUMERIC} Valid Date and Stop date and clock time, used 16 Time to seconds: for requesting transactions queued before this time yyyy+mo+dd+hh +mm+ss+tz SUBJECT SUBJ 1{ALPHANUMERIC} Free form text Informative text used to 80 summarize a topic in a message TARIFF_REFERENCE TARIFF 1{ALPHANUMERIC} Free form text. Tariffs approved by FERC 150 Name and description of Tariff S&CP Phase IA, Version 1.2 May 27, 1998 A-24 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters TEMPLATE TEMPL 1{ALPHANUMERIC}2 Valid Name of The name of a logical 0 Template from collection of DATA_ELEMENTS in Section 4.3 or a User's interaction with an from LIST OASIS Node. Template TIME_OF_LAST_UPDAT TLUPDATE 16{ALPHANUMERIC} Valid date and Date and time to seconds that E 16 time to seconds: data was last updated. May be used to search data updated yyyy+mo+dd+hh since a specific point in time. +mm+ss+tz TIME_POSTED TIMEPST 16{ALPHANUMERIC} Valid Date and Date and time a message is 16 Time to seconds: posted yyyy+mo+dd+hh +mm+ss+tz TIME_QUEUED TIMEQ 16{ALPHANUMERIC} Valid Date and Date and time that the request 16 Time to seconds: was queued yyyy+mo+dd+hh +mm+ss+tz TIME_STAMP TSTAMP 16{ALPHANUMERIC} Valid date and Time data is created 16 Time to seconds yyyy+mo+dd+hh+mm +ss+tz TS_CLASS TSCLASS 1{ALPHANUMERIC}2 Valid classes: The transmission service 0 FIRM classes provided. Three are NON-FIRM pre-defined, while additional TTC classes can be used if they are Registered} registered on TSIN.COM and shown in the Provider's LIST template page S&CP Phase IA, Version 1.2 May 27, 1998 A-25 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters TS_PERIOD Valid periods The transmission service TSPER 1{ALPHANUMERIC}2 ON_PEAK periods provided. Three are 0 OFF_PEAK pre-defined, while additional FULL_PERIOD periods can be used if they are {Registered} registered on TSIN.COM and shown in the Provider's LIST template TS_SUBCLASS Free Form TSSUBC 1{ALPHANUMERIC}2 The transmission service 0 subclasses provided. These are freeform. TS_TYPE Valid periods TSTYPE 1{ALPHANUMERIC}2 The transmission service types POINT_TO_PO 0 provided. Two are pre-defined, INT while additional types can be NETWORK used if they are registered on {Registered TSIN.COM and shown in the } Provider's LIST template TS_WINDOW Valid periods TSWIND 1{ALPHANUMERIC}2 The transmission service FIXED 0 windows provided. Two are pre- SLIDING defined, while additional {Registered windows can be used if they are } registered on TSIN.COM and shown in the Provider's LIST template S&CP Phase IA, Version 1.2 May 27, 1998 A-26 Data Dictionary Alias Field Format : Restricted Definition of Data Element Element Name minimum Values characters {type of ASCII} maximum characters TZ TZ 2{ALPHANUMERIC}2 Valid time zone Time zones: and indication Atlantic time = AD, AS whether daylight Eastern time = ED, ES savings time is Central time = CD, CS to be used Mountain time = MD, MS Pacific time = PD, PS Universal time = UT VALID_FROM_TIME VALFTIME 16{ALPHANUMERIC} Valid date and Date and time after which the 16 time message is valid yyyy+mo+dd+hh +mm+ss+tz VALID_TO_TIME VALTTIME 16{ALPHANUMERIC} Valid date and Date and time before which the 16 time message is valid yyyy+mo+dd+hh +mm+ss+tz VERSION VER 1{REAL NUMBER}6 Range of 1.0 to Specifies which version of the 9999.9 OASIS Standards and Communication Protocol to use when interpreting the request S&CP Phase IA, Version 1.2 May 27, 1998 A-27