CEE Board W. Heinbockel CEE Specification The MITRE Corporation July 8, 2011 CEE Log Syntax (CLS) Encoding: XML (application/cee+xml) draft-cls-xml-06-6 Abstract This document defines a Common Event Expression (CEE) Log Syntax (CLS) encoding that is compatible with the W3C Extensible Markup Language (XML) 1.0 format. This syntax encoding specifies how to encode a CEE event record using XML, as well as how to extract the CEE event record data from an XML encoded event record. Copyright Notice Copyright (c) 2011 The MITRE Corporation. All rights reserved. Document License The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use CEE for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. Disclaimers THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF. The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders. Heinbockel [Page 1] CEE Specification CLS Encoding: XML July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. XML Event Record Encoding Process . . . . . . . . . . . . . . 3 4. XML Syntax Encoding . . . . . . . . . . . . . . . . . . . . . 4 4.1. Field . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. Field Name . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Field Value . . . . . . . . . . . . . . . . . . . . . 5 4.1.3. Fields with No Values . . . . . . . . . . . . . . . . 5 4.1.4. Fields with More Than One Value . . . . . . . . . . . 5 4.2. Value Types . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. string . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. binary . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.3. tag . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.4. integer . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.5. float . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.6. boolean . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.7. timestamp . . . . . . . . . . . . . . . . . . . . . . 11 4.2.8. duration . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.9. ipv4Address . . . . . . . . . . . . . . . . . . . . . 12 4.2.10. ipv6Address . . . . . . . . . . . . . . . . . . . . . 13 4.2.11. macAddress . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Core Fields . . . . . . . . . . . . . . . . . . . . . . . 14 5. Event Extensions . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Event Augmentation . . . . . . . . . . . . . . . . . . . . 15 6. Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Event Identification . . . . . . . . . . . . . . . . . . . . . 15 8. XML Encoded CEE Event Record Examples . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. CEE XML Schema . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Heinbockel [Page 2] CEE Specification CLS Encoding: XML July 2011 1. Introduction The W3C Extensible Markup Language (XML) 1.0 format is a text-based data exchange format and is used by a larger number of devices and web services. The simplicity, readability, and efficiency of XML makes it ideal for encoding event record data. This document describes a method for encoding a CEE event record into a XML compatible format. The XML format is documented in [W3C.REC-xml]. The CEE event record format and CLS syntax encoding requirements are defined in [CEE.CLS]. An overview of the CEE Architecture, including the CEE event format and CLS encodings is provided in [CEE.ARCH]. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Guidance for use of XML follows that from [RFC3470]. 3. XML Event Record Encoding Process CEE makes a distinction between the event recording and the event encoding process. Once an event occurs that should be recorded, the relevant data from that event is captured as a CEE event record. When the event record is to be recorded in a log or shared, the CEE record should be encoded according to one or more CLS encodings. In order for event consumers to consume CLS encoded event record, the consumer must simply decode the CLS encoded record into the original CEE event record. The encoding and decoding of CEE event records using of CLS encodings MUST be able to be performed without data loss. XML encoded event records MUST be processed in a manner that meets the event record processing instructions detailed in [CEE.CLS]. +---------+ +----------+ encode +-----------+ | | data | CEE | =======> | XML | | Event | =====> | Event | | Encoded | | | | Record | <======= | Record | +---------+ +----------+ decode +-----------+ XML Encoding Process Heinbockel [Page 3] CEE Specification CLS Encoding: XML July 2011 4. XML Syntax Encoding Each XML encoded CEE event record MUST be encoded in a format that conforms to [W3C.REC-xml] and MUST validate against the official CEE XML Event schema in Appendix A. Each CEE XML document SHOULD include an XML header that indicates the text encoding. If no XML header is included, the CEE XML MUST be interpreted as being encoded in UTF-8, as described in [RFC3629]. All insignificant whitespace occurring in and around XML elements and other structures MUST be ignored. Each CEE XML record SHOULD include an XML namespace. If it does, the namespace for each element defined in this specification MUST be "http://cee.mitre.org". The XML syntax encoding of a CEE event record MUST begin with a "CEE" XML element and have an "Event" child element that provides the event fields. Additional child elements MAY be present and MUST be valid XML-encoded data after the "Event" element. An XML encoded CEE event record MUST NOT exceed 64 KB (65535 octets) in size. Examples of XML encoded CEE event records can be found in Section 8. The full XML CEE event record XML Schema is included in Appendix A. 4.1. Field In the CLS XML encoding, CEE core field and name-value fields are encoded differently within an event record. Name-value fields MAY appear in any order and are represented as an XML "Field" element. The field name MUST be placed in the Field element's "name" attribute. Each field has zero or more field values, which are represented within child elements that correspond to the field value's type. The text representation of the value is then placed as the value element's text node. If the field has no child field type elements, then it MUST be interpreted that the name- value field has no value. The CEE core event fields are encoded as predefined in the CEE XML Event Schema as XML elements. Core fields MUST be specified before any name-value fields and MUST appear in the order defined in Section 4.3. Heinbockel [Page 4] CEE Specification CLS Encoding: XML July 2011 4.1.1. Field Name The field name is an identifier to provide context to the field values. Each CEE field name MUST be encoded as a UTF-8 XML string and contained within double quote ('"', ABNF %x22) characters. Each XML field name MUST also meet the restrictions for a valid CEE Field Name from [CEE.CLS]: o A CEE field name MUST contain between 1 and 32 characters o Each field name MUST start with an ASCII letter (ABNF ALPHA) or underscore ('_', ABNF %x5F) characters o A field name MUST contain only number (ABNF DIGIT), ASCII letter, and underscore characters 4.1.2. Field Value Each field MUST have zero or more field values and each value MUST be encoded based on its CEE value type and per the W3C XML 1.0 specification ([W3C.REC-xml]). The encoding for each value type is defined in Section 4.2. A field MUST NOT have more than 255 field values. Each encoded field value MUST NOT exceed 2 KB (2048 octets) in size. 4.1.3. Fields with No Values Fields that do not have a value SHOULD be removed from the encoding, if possible. Otherwise, the field MUST be recorded without a field value. A CEE XML field having no field value and no field type indicates that the field has a nil value, or that there is no value associated with the field. Nil values have no associated type. In XML, a nil value MUST be encoded as field having no field value or field type. For core fields (Section 4.3), an empty or nil value is indicated by a single hypen ('-', ABNF %x2D) character. 4.1.4. Fields with More Than One Value For fields having more than one value, the values MUST be encoded as a sequence of CEE XML field values. Each value MUST be properly encoded and enclosed within an XML element that indicates the value type. Heinbockel [Page 5] CEE Specification CLS Encoding: XML July 2011 A CEE field MUST NOT have more than 255 field values. 4.2. Value Types The XML encoding supports all eleven (11) CEE value types: string, binary, integer, float, boolean, timestamp, duration, ipv4Address, ipv6Address, macAddress, and tag. All CEE value types can be supported in XML. While some value types are already natively supported in XML, the remainder can be defined within an XML Schema ([W3C.REC-xmlschema-1], [W3C.REC-xmlschema-2]). The XML Schema representations are provided for each CEE field type. All CEE XML values MUST be encoded based on the type-specific rules and then formatted to be compliant with the string value encoding rules (see Section 4.2.1). 4.2.1. string All CEE string values MUST be a sequence of valid Unicode characters and encoded as specified in the XML header. If no XML header is present, the string values SHOULD be encoded in UTF-8. Each string value MUST be encoded into a proper XML string value and enclosed within a CEE string ("") XML element. The string encoding rules are defined in the following sections. The XML Schema definition for the CEE string value XML element is: 4.2.1.1. Encoding Rules In XML, all values MUST be encoded as a sequence of characters according to the XML text encoding rules defined in the XML 1.0 Specification, [W3C.REC-xml]. These characters are specified in XML as being either supported, reserved, or illegal. Illegal characters MUST NOT be specified in any form (native or escaped). Reserved characters MUST be escaped or otherwise encoded, and MUST NOT appear in their native form. All other characters are supported and can appear in either their native or XML escaped form. Heinbockel [Page 6] CEE Specification CLS Encoding: XML July 2011 4.2.1.2. Illegal Characters Illegal characters MUST NOT appear in CEE value or XML encoding. XML 1.0 defines only one illegal character: NIL (ABNF %x00). A NIL character MUST NOT appear in any character encoding format (e.g., UTF-8, UTF-16) or in the XML character escape format: "�". 4.2.1.3. Reserved Characters There are several characters that MUST only appear in an escaped form and MUST NOT appear in their native form within a XML-encoded string value. This set of disallowed string characters include the less- than sign ('<', ABNF %x3C), ampersand ('&', ABNF %x26), and ASCII control (ABNF %x01-%x1F) characters. The greater-than sign ('>', ABNF %x3E) MAY be encoded, but is not mandatory. [W3C.REC-xml] defines two valid escape sequences: a character entity and a numeric character reference. Each escape sequence MUST begin when an ampersand and end with a semicolon (';', ABNF %x3B). Valid character entity references are defined in [W3C.REC-xml], but only for a few of the more commonly escaped characters; not every XML reserved character has a character entity reference. However, the more generic, numeric reference character reference can be used to represent any character except illegal characters. The numeric reference escape sequences MUST begin with an ampersand; followed by a pound sign ('#', ABNF %x23); the Unicode character value as a decimal, or an 'x' (ABNF %x78) and a hexadecimal value; and a final semicolon. A list of valid XML escape sequences for reserved XML characters is provided in Table 1. Additional valid XML escape sequences are defined in [W3C.REC-xml]. XML-STRING = *XML-CHAR XML-CHAR = ESCAPE-SEQ / NATIVE-CHAR NATIVE-CHAR = *OCTET ; except reserved or illegal characters ESCAPE-SEQ = "&" ( ESCAPE-STR / ESCAPE-NUM ) ";" ESCAPE-STR = 1*ALPHA ; defined by W3C XML 1.0 Specification ESCAPE-NUM = "#" ( 1*DIGIT / "x" 1*HEXDIG ) XML Character Escaping ABNF Definition Heinbockel [Page 7] CEE Specification CLS Encoding: XML July 2011 +-----------+------+------------------+-------------------+ | Character | ABNF | Character Entity | Numeric Reference | +-----------+------+------------------+-------------------+ | " | %x22 | " | " " | | & | %x26 | & | $ $ | | ' | %x27 | ' | ' ' | | < | %x3C | < | < < | | > | %x3E | > | > > | +-----------+------+------------------+-------------------+ Table 1: XML Character Escape Sequences 4.2.1.4. Whitespace CEE field values SHOULD be encoded with no leading or trailing whitespace. Whitespace characters in XML encodings are defined as a space (' ', ABNF %x20), horizontal tab (ABNF %x09), line feed (ABNF % x0A), or carriage return (ABNF %x0D). When processing CEE XML field values, leading and trailing whitespace SHOULD be ignored. Any whitespace characters appearing within the middle of a value MUST NOT be collapsed and MUST be handled exactly as provided by the value. 4.2.2. binary A binary value is a series of zero or more octet values and is intended to hold binary data such as files or byte streams. It can be used to hold values that contain non-Unicode sequences or illegal XML characters. In XML, all binary values MUST be encoded using Base64 as described in [RFC4648] and by the XML Schema "base64Binary" simpleType. To minimize the encoded message length, a Base64 encoded binary value SHOULD NOT contain any optional whitespace: space, tab, carriage return, or line feeds, as permitted by [RFC4648]. The entire CEE binary Base64 value MUST be encoded into XML as a string value, following the string encoding rules in Section 4.2.1. Each binary value MUST be placed as the value of the CEE XML "binary" element and placed as a child value for the associated XML field. The XML Schema definition for the CEE binary value XML element is: Heinbockel [Page 8] CEE Specification CLS Encoding: XML July 2011 4.2.3. tag The tag field type is a special field type within the CEE that is used to include references to event tags, or keywords. A set of standardized tag names are defined in the CEE Event Taxonomy as defined in the CEE Profile specification [CEE.Profile]. All CEE tag values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded tag value MUST be placed as the value of the CEE XML "tag" element as the value for the XML field element. The XML Schema definition for the CEE tag value XML element is: 4.2.4. integer Integer values are a sequence of decimal integers (ABNF DIGIT) of values %x30 through %x39 ("0" through "9"). The value of a CEE integer MUST be representable within a 64-bit signed integer, in the range [-(2^63), 2^63-1]. In XML, a CEE integer value is represented as a sequence of digits with no fractional or exponential parts. If the CEE value contains a fraction or exponent, then the number MUST be represented as a CEE float type in XML. For example, the CEE value "-100" SHOULD be a CEE integer, while "3.14159", "+12E3", and ".5" are CEE float values. All CEE integer values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded integer value MUST be placed as the value of the CEE XML "int" element as the value for the Heinbockel [Page 9] CEE Specification CLS Encoding: XML July 2011 XML field element. The XML Schema definition for the CEE integer value "int" XML element is: 4.2.5. float A float value is a representation of an arbitrary precision, finite, real number that can be represented within an IEEE 754 [IEEE.754.1985] 64-bit ("double") floating point format. A CEE float value are natively supported in XML and MUST encoded as a XML number value that has a fraction or an exponential component. If the CEE float value has a fractional component of "0" (e.g., "-12.0"), then the value SHOULD NOT be interpreted as a CEE integer value ("-12"). That is, the precision of a numeric value SHOULD NOT be lost when encoding or decoding a CEE float value into or out of XML. All CEE float values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded float value MUST be placed as the value of the CEE XML "float" element as the value for the XML field element. The XML Schema definition for the CEE float value XML element is: 4.2.6. boolean A boolean value supports Boolean, or binary-valued, logic and can only represent the values of "true" and "false". Boolean is another native XML type. To encode a CEE boolean value into XML, a true value MUST be encoded as the value "true" (ABNF % x74.72.75.65). A false value MUST be encoded as the value "false" (ABNF %x66.61.6C.73.65). Heinbockel [Page 10] CEE Specification CLS Encoding: XML July 2011 The XML "true" and "false" values MUST NOT be enclosed in quotes ('"', ABNF %x22). Otherwise, the values will be interpreted as a string and not a Boolean value. All CEE boolean values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded boolean value MUST be placed as the value of the CEE XML "bool" element as the value for the XML field element. The XML Schema definition for the CEE boolean value "bool" XML element is: 4.2.7. timestamp The CEE timestamp value type allows for the specification of a date, time, and timezone information as defined in [ISO.8601.1988]. CEE timestamp values MAY be rounded to nanosecond (1E-9 second) precision. To encode a CEE timestamp value into XML, the value MUST be formatted according to the CEE timestamp lexical representation format. All CEE timestamp values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded timestamp value MUST be placed as the value of the CEE XML "time" element as the value for the XML field element. The XML Schema definition for the CEE timestamp value "time" XML element is: Heinbockel [Page 11] CEE Specification CLS Encoding: XML July 2011 4.2.8. duration CEE duration value type supports values that represent a consecutive period of time in a format compliant with [ISO.8601.1988]. CEE duration values MAY be rounded to nanosecond (1E-9 second) precision. CEE duration values are encoding into XML by encoding the duration value into the CEE duration lexical representation format. All CEE duration values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded duration value MUST be placed as the value of the CEE XML "dur" element as the value for the XML field element. The XML Schema definition for the CEE duration value "dur" XML element is: 4.2.9. ipv4Address The ipv4Address field type holds a single network address within an IPv4 network. To encode a CEE ipv4Address value into XML, the IPv4 address MUST be represented using the CEE ipv4Address lexical representation, or IPv4 dotted-decimal, format. All CEE ipv4Address values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded ipv4Address value MUST be placed as the value of the CEE XML "ipv4" element as the value for the XML field element. The XML Schema definition for the CEE ipv4Address value "ipv4" XML element is: Heinbockel [Page 12] CEE Specification CLS Encoding: XML July 2011 4.2.10. ipv6Address The ipv6Address field type holds a single network address within an IPv6 network. For a CEE ipv6Address value to be encoded into XML, the IPv6 address MUST be represented using a valid IPv6 notation. Valid CEE ipv6Address lexical representations as defined in [CEE.CLS] and [RFC4291]. Once the ipv6Address value is in a valid format, it MUST encoded as an XML-compatible string (Section 4.2.1) and placed as the value of the CEE XML "ipv6" element as the value for the XML field element. The XML Schema definition for the CEE ipv6Address value "ipv6" XML element follows. Note that the XML pattern values are only split over multiple lines for readability. 4.2.11. macAddress The CEE macAddress field type represents Media Access Control (MAC) address values that are the physical network address of a network interface ([IEEE.802.1990]). The CEE macAddress value MUST be represented according to the CEE macAddress lexical representation format defined in [CEE.CLS]. All CEE macAddress values MUST be encoded according to the XML string encoding rules, Section 4.2.1. Each encoded macAddress value MUST be Heinbockel [Page 13] CEE Specification CLS Encoding: XML July 2011 placed as the value of the CEE XML "mac" element as the value for the XML field element. The XML Schema definition for the CEE macAddress value "mac" XML element is: 4.3. Core Fields The core field names, field types, and descriptions are defined in [CEE.CLS]. Each encoded CEE event record MUST have a field whose name and type matches one defined in [CEE.CLS]. A core field value MUST NOT be represented in XML using a field type other than its defined field type. A type designator MAY be used for the core fields and MUST indicate the core field's defined type. If no value is present for a mandatory core field, then the value MUST be a single hyphen character ('-', ABNF %x2D), which represents the nil value (see Section 4.1.3). When encoding the CEE record in XML, the core fields MUST appear and MUST be in the following order: +----------+-----------+--------------+ | Position | Field | Defined Type | +----------+-----------+--------------+ | 1 | id | string | | 2 | time | timestamp | | 3 | action | tag | | 4 | status | tag | | 5 | p_sys_id | string | | 6 | p_prod_id | string | +----------+-----------+--------------+ Table 2: CEE XML Core Field Order The XML Schema definition for each of these core fields can be found in Appendix A. Heinbockel [Page 14] CEE Specification CLS Encoding: XML July 2011 5. Event Extensions The XML CLS Encoding allows for event extensions and supports the following extensions: o Event Augmentation (Section 5.1) 5.1. Event Augmentation The event augmentation extension allows for non-destructive modification to XML CLS Encoded event records. Event augmentation extension sections are enclosed within an "Augmentation" element and MUST after the "Event" body element. Each augmentation section MUST have an "order" attribute that contains a unique, positive integer value. The augmentations SHOULD be processed after the "Event" body and in the ordering indicated by the "order" value. An "Augmentation" elements first children MUST include "time", "p_sys_id", and "p_prod_id" and MUST appear in that order. The format for each of these fields is defined in the CEE core fields Section 4.3. The remainder of the augmentation section MUST consist of zero or more fields that indicate the added fields and field values. Each field MUST be of the form described in Section 4.1. 6. Event Logs This CLS Encoding can encode an event log of CEE event records. A group of zero or more XML encoded event records MUST be encoded by placing each CEE XML Event "CEE" element as a child of a single XML "Log" element. That is, each CEE event record MUST be encoded as defined in Section 4. 7. Event Identification For devices and protocols that use MIME or Internet media types [RFC4288], the Internet media type "application/cee+xml" SHOULD be used to indicate an XML-encoded CEE event record. Heinbockel [Page 15] CEE Specification CLS Encoding: XML July 2011 8. XML Encoded CEE Event Record Examples Example 1--Valid example-event-1 login success 10.10.1.1 product A small XML encoded CEE event record that contains only the core fields. The type of each value is clearly indicated using a type designator. Note how the p_sys_id value is of the form of an IPv4 address, but is a CEE string type. Example 2--Valid example-event-2 download - host.example.com product web example.txt RmlsZSBDb250ZW50Li4uAAo= success relay.example.com cee-relay hipaa This example adds two additional event fields to the event body, as well as an augmentation section. The augmentation section indicates that the nil "status" value is replaced by "success" and a new tag Heinbockel [Page 16] CEE Specification CLS Encoding: XML July 2011 value was added to the original "tags" field by an intermediate system. The binary field type on the "file_data" field identifies that the value is a Base64 encoded binary value. Example 3--Valid example-event-3 login failed host2.example.com product bob Invalid username or password example-event-3 login success host2.example.com product bob Here is a XML encoding of an event log containing two CEE event records. Example 4--Invalid Heinbockel [Page 17] CEE Specification CLS Encoding: XML July 2011 invalid-event-4 login success audit This XML record is invalid for multiple reasons. First, the value of the time field is not presented as a valid CEE timestamp value, as required by the core time field definition. Also, the event record core fields are not in the proper order and two mandatory core fields are missing: p_sys_id and p_prod_id. Finally, the augmentation section is missing the required time, p_sys_id, and p_prod_id fields. Example 5--Invalid invalid-event-5 login success 10.0.0.1 product Accessing file \\\foo.txt This record not conform to the XML 1.0 Specification, [W3C.REC-xml]-- the less than sign ('<') in the event_text field value is not properly escaped as either "<", "<", or "<". Furthermore, the action, status and p_prod_id field are provided, but do not conform to the core field representations defined in Section 4.3. 9. Acknowledgments This specification is the product of the CEE Board and community. The CEE Board would like to thank their colleagues who reviewed drafts of this and previous documents. The CEE Board also gratefully Heinbockel [Page 18] CEE Specification CLS Encoding: XML July 2011 acknowledges and appreciates the many contributions from individual representing public and private section, especially Rainer Gerhards, Eric Fitzgerald, Raffael Marty, Steve Grubb, Dr. Anton Chuvakin, Dominique Karg, Peter Czanik, and George Saylor. 10. References 10.1. Normative References [CEE.CLS] CEE Board, "CEE Event Record and CLS Encoding Specification", April 2011. [IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985. [IEEE.802.1990] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture", IEEE Standard 802, 1990. [ISO.8601.1988] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- xml, October 2000, . [W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Heinbockel [Page 19] CEE Specification CLS Encoding: XML July 2011 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [W3C.REC-xmlschema-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . 10.2. Informative References [CEE.ARCH] CEE Board, "CEE Architecture Overview", May 2010. [CEE.Profile] CEE Board, "CEE Profile Specification", June 2011. [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. Appendix A. CEE XML Schema [NOTE: Several of the XML Schema elements were split over several lines for readability. There should be no whitespace contained in any of the following XML Schema xs:pattern value attributes.] Heinbockel [Page 20] CEE Specification CLS Encoding: XML July 2011 Heinbockel [Page 21] CEE Specification CLS Encoding: XML July 2011 Heinbockel [Page 22] CEE Specification CLS Encoding: XML July 2011 Heinbockel [Page 23] CEE Specification CLS Encoding: XML July 2011 Heinbockel [Page 24] CEE Specification CLS Encoding: XML July 2011 Author's Address William Heinbockel The MITRE Corporation 202 Burlington Rd Bedford, MA 01730 United States Phone: +1 781-271-2615 Email: heinbockel@mitre.org Heinbockel [Page 25]