One document matched: draft-saintandre-json-namespaces-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="info" docName="draft-saintandre-json-namespaces-00" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="JSON Namespaces">JavaScript Object Notation (JSON) Namespaces</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>jhildebr@cisco.com</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matt Miller">
<organization>Cisco</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>mamille2@cisco.com</email>
</address>
</author>
<date day="24" month="October" year="2011"/>
<abstract>
<t>This document defines a convention for namespaced variable names in JavaScript Object Notation (JSON) data.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t>JavaScript Object Notation <xref target='JSON'/> is a text format for the serialization of structured data, derived from the object literals of the JavaScript programming language. Unlike the Extensible Markup Language <xref target='XML'/>, JSON does not provide methods for qualifying variable names, as XML does for elements and attributes <xref target='XML-NAMES'/>. However, in certain circumstances such namespaces can be useful. Therefore, this document defines a convention for namespaced variable names in JSON data.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target='RFC2119'/>.</t>
<t>Feedback is welcome on the apps-discuss@ietf.org mailing list.</t>
</section>
<section title="Namespace Convention" anchor='convention'>
<t>Various approaches have been proposed to namespaces (or "distributed extensibility") in JSON, from a centralized registry of variable names to prefixing with the "reverse domain name" of the namespace owner (e.g., "com.example.foo"). All of these approaches are preferable to use of the "x-" prefix <xref target='XDASH'/> or a similar construction, since they provides attribution and traceability for each namespace. The convention described here follows "Clark Notation" <xref target='CLARK'/> by preceding a variable name with a Uniform Resource Identifier <xref target='URI'/> enclosed in curly brackets ('{' and '}'). The use of URIs provides improved re-use of data models across existing representations, especially with XML when qualified by XML namespaces.</t>
<t>In JSON, a variable name that is namespaced in this way is the "string" production when appearing as the first part of the "member" production, as those productions are defined in <xref target='JSON'/>. An example follows.</t>
<figure>
<artwork><![CDATA[
{http://example.com/foo}bar
]]></artwork>
</figure>
<t>Namespace names MUST NOT include the characters '{' and '}'.</t>
</section>
<section title="When and How to Use JSON Namespaces" anchor='use'>
<t>The convention described here is not intended for use in "standalone" JSON objects, especially those defined by a JSON schema <xref target='JSON-SCHEMA'/>. Instead, it is intended for use when a particular variable is likely to be re-used or interleaved within data that represents other JSON objects. The following example shows a namespaced variable name used within an OAuth access token <xref target='OAUTH'/>.</t>
<figure>
<artwork><![CDATA[
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"{http://example.com/foo}bar":"baz"
}
]]></artwork>
</figure>
<t>Namespaces MUST NOT be used for core JSON attributes (such as 'char' and 'number').</t>
<t>An application MUST ignore namespaced variables that it does not understand, where by "ignore" is meant "discard the data without acting upon it or returning an error to the sender".</t>
</section>
<section title="Security Considerations" anchor="security">
<t>This convention introduces no security concerns beyond those described in <xref target='JSON'/>.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no actions of the IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='JSON'>
<front>
<title>The application/json Media Type for JavaScript Object Notation (JSON)</title>
<author initials='D.' surname='Crockford' fullname='D. Crockford'>
<organization /></author>
<date year='2006' month='July' />
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4627' />
<format type='TXT' octets='16319' target='http://www.rfc-editor.org/rfc/rfc4627.txt' />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date month='March' year='1997' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor='CLARK' target='http://www.jclark.com/xml/xmlns.htm'>
<front>
<title>Clark Notation</title>
<author initials='J.' surname='Clark' fullname='James Clark'>
</author>
<date year='1999' month='February' />
</front>
</reference>
<reference anchor='JSON-SCHEMA'>
<front>
<title>A JSON Media Type for Describing the Structure and Meaning of JSON Documents</title>
<author initials='K' surname='Zyp' fullname='Kris Zyp'>
<organization />
</author>
<author initials='G' surname='Court' fullname='Gary Court'>
<organization />
</author>
<date month='November' day='22' year='2010' />
<abstract><t>JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-zyp-json-schema-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-zyp-json-schema-03.txt' />
</reference>
<reference anchor='OAUTH'>
<front>
<title>The OAuth 2.0 Authorization Protocol</title>
<author initials='E' surname='Hammer-Lahav' fullname='Eran Hammer-Lahav'>
<organization />
</author>
<author initials='D' surname='Recordon' fullname='David Recordon'>
<organization />
</author>
<author initials='D' surname='Hardt' fullname='Dick Hardt'>
<organization />
</author>
<date month='September' day='22' year='2011' />
<abstract><t>The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-oauth-v2-22' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-22.txt' />
<format type='PDF'
target='http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-22.pdf' />
</reference>
<reference anchor='URI'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='ftp://ftp.isi.edu/in-notes/rfc3986.txt' />
<format type='HTML' octets='200858' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='165759' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='XDASH'>
<front>
<title>Deprecating Use of the "X-" Prefix in Application Protocols</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<author initials='D' surname='Crocker' fullname='D. Crocker'>
<organization />
</author>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
<organization />
</author>
<date month='October' day='24' year='2011' />
<abstract><t>Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the "X-" convention for most application protocol parameters.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-appsawg-xdash-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-02.txt' />
</reference>
<reference anchor='XML' target='http://www.w3.org/TR/2008/REC-xml-20081126'>
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials='E.' surname='Maler' fullname='Eve Maler'>
<organization />
</author>
<author initials='F.' surname='Yergeau' fullname='François Yergeau'>
<organization />
</author>
<author initials='C.' surname='Sperberg-McQueen' fullname='C. M. Sperberg-McQueen'>
<organization />
</author>
<author initials='J.' surname='Paoli' fullname='Jean Paoli'>
<organization />
</author>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<date month='November' day='26' year='2008' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xml-20081126' />
<format type='HTML' target='http://www.w3.org/TR/2008/REC-xml-20081126' />
</reference>
<reference anchor="XML-NAMES" target='http://www.w3.org/TR/2009/REC-xml-names-20091208'>
<front>
<title>Namespaces in XML 1.0 (Third Edition)</title>
<author initials='H.' surname='Thompson' fullname='Henry S. Thompson'>
<organization />
</author>
<author initials='D.' surname='Hollander' fullname='Dave Hollander'>
<organization />
</author>
<author initials='A.' surname='Layman' fullname='Andrew Layman'>
<organization />
</author>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<author initials='R.' surname='Tobin' fullname='Richard Tobin'>
<organization />
</author>
<date month='December' day='8' year='2009' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xml-names-20091208' />
<format type='HTML' target='http://www.w3.org/TR/2009/REC-xml-names-20091208' />
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t>This document has benefited from texts about distributed extensibility posted on the Internet by David Baron, Tim Bray, James Clark, Yaron Goland, Joe Gregoria, Mike Hanson, Jack Moffitt, Mark Nottingham, and Simon St. Laurent.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:04:57 |