Internet Engineering Task Force P. Hallam-Baker Internet-Draft Comodo Group Inc. Intended status: Standards Track July 31, 2012 Expires: February 1, 2013 Simple Cloud Interoperable Jason Encoding for REST Web Services (SCIJER) Bindings draft-hallambaker-scijer-00 Abstract SCIJER (pronounced skyjer) specifies a mapping of data types to JavaScript Object Notation (JSON) encoding. The JSON specification defines encodings for integers, strings, arrays and objects. This document specifies a mapping between JSON encoding and an extended set of types. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 1, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Hallam-Baker Expires February 1, 2013 [Page 1] Internet-Draft SCIJER JSON BINDING July 2012 described in the Simplified BSD License. Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Object . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Serializable . . . . . . . . . . . . . . . . . . . . . . . 3 3.2.1. Array . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Boolean . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Integer . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. Floating Point . . . . . . . . . . . . . . . . . . . . . . 4 3.6. String . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6.1. URI . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6.2. Label . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6.3. Name . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 5 3.8. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.8.1. DateTime . . . . . . . . . . . . . . . . . . . . . . . 6 3.8.2. ElapsedTime . . . . . . . . . . . . . . . . . . . . . . 6 3.9. Binary . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Hallam-Baker Expires February 1, 2013 [Page 2] Internet-Draft SCIJER JSON BINDING July 2012 1. Definitions 1.1. Requirements Language 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 [RFC2119]. 1.2. Defined Terms The following terms are used in this document: 2. Introduction JSON is a format for encoding data structures in UTF8 text format with similar capabilities to XML and ASN.1 but with lower coding overhead. Unlike XML and ASN.1, JSON does not have a schema language. This draft defines a mapping between JSON data types and programming language types that MAY be used as the basis for a schema language definition. 3. Bindings Specify conversions between JSON encoding and C, C# and Java types. 3.1. Object JSON C C# Java 3.2. Serializable 3.2.1. Array Hallam-Baker Expires February 1, 2013 [Page 3] Internet-Draft SCIJER JSON BINDING July 2012 JSON C C# Java 3.2.2. List JSON C C# Java 3.3. Boolean JSON true | false C int C# bool C# boolean 3.4. Integer JSON number without decimal point C, C#, Java int or long 3.5. Floating Point JSON number with decimal point C, C#, Java float or double 3.6. String The String type maps to the JSON string encoding. The following subtypes are defined to represent commonly used syntactic restrictions. Hallam-Baker Expires February 1, 2013 [Page 4] Internet-Draft SCIJER JSON BINDING July 2012 JSON String encoding C char * [NB must use appropriate wrappers to encode/decode UTF8] C#, Java String URI Label Name 3.6.1. URI A URI is a string that contains a URI as specified in [RFC3986]. 3.6.2. Label A label is a string that MUST NOT contain any ASCII character other than digits (0-9), alphabetic (a-z, A-Z), underscore or dash. All other UNICODE characters are permitted. The Label type provide a means of avoiding content injection attacks by ensuring that a field does not contain characters commonly used as control characters in scripting languages. 3.6.3. Name A Name is a sequence of Labels separated by period characters '.'. Note that the syntactic restriction of a Name is not exactly the same as the restriction on a DNS address. 3.7. Enumeration An enumeration is encoded as a Label. 3.8. Time SSCIJER supports two encodings DateTime A string encoded in [RFC3339] format. This provides a human readable representation. ElapsedTime A number that represents the number of seconds that have elapsed since January 1, 0001 at 00:00:00.000 in the Gregorian calendar. Decimals MAY be used to represent time intervals of less than a second. Hallam-Baker Expires February 1, 2013 [Page 5] Internet-Draft SCIJER JSON BINDING July 2012 Conversion between the two encodings MUST be informed by the times at which leap seconds were introduced into the UTC coding. This creates a challenge in the case that a device only has access to time in one form but not the other. In order to address this problem, implementations MUST accept time values encoded in either format and SHOULD emit the encoding specified in the schema. 3.8.1. DateTime JSON String [Encoded in [RFC3339] format.] C System dependent C# DateTime Java Date Represents a date and time in the Gregorian callendar using the format described in [RFC3339]. 3.8.2. ElapsedTime JSON Number C System dependent C# DateTime Java Date A number that represents the number of seconds that have elapsed since January 1, 0001 at 00:00:00.000 in the Gregorian calendar. Decimals MAY be used to represent time intervals of less than a second. 3.9. Binary JSON String [Base64 encoding of binary data] C {unsigned char *, length} C#, Java byte [] 3.10. Hallam-Baker Expires February 1, 2013 [Page 6] Internet-Draft SCIJER JSON BINDING July 2012 4. Security Considerations 5. IANA Considerations 6. Acknowledgements The name of this draft was inspired by Mark Nottingham. 7. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Author's Address Phillip Hallam-Baker Comodo Group Inc. Email: philliph@comodo.com Hallam-Baker Expires February 1, 2013 [Page 7]