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]