<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-json-seq-suffix-00">
   <front>
      <title>A Media Type Structured Syntax Suffix for JSON Text Sequences</title>
      <author initials="E." surname="Wilde" fullname="Erik Wilde">
         <organization>CA Technologies</organization>
         <address>
            <email>erik.wilde@dret.net</email>
            <uri>http://dret.net/netdret/</uri>
         </address>
      </author>
      <date day="19" month="September" year="2016"/>
      <abstract>
         <t>Structured Syntax Suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "json-seq" as a structured syntax suffix for JSON Text Sequences.</t>
      </abstract>
      <note title="Note to Readers">
         <t>This draft should be discussed on the <eref target="https://www.ietf.org/mailman/listinfo/art">art mailing list</eref>.</t>
         <t>Online access to all versions and files is available on <eref target="https://github.com/dret/I-D/tree/master/json-seq-suffix">github</eref>.</t>
      </note>
   </front>
   <middle>
      <section title="Introduction" anchor="intro">
         <t>Media Type Structured Syntax Suffixes <xref target="RFC6838"/> were introduced as a way of how a media type can signal that it is based on another media type as its foundation. Some structured syntax suffixes were registered initially <xref target="RFC6839"/>, including "+json" for the widely popular JSON Format <xref target="RFC7195"/> format.</t>
         <t>JSON Text Sequences <xref target="RFC7464"/> is a new specification in the JSON space that defines how a sequence of multiple JSON texts can be represented in one representation. Since this specification can be used as the foundation for other formats, this specification defines and registers the "+json-seq" structured syntax suffix.</t>
      </section>
      <section title="Terminology">
         <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 <xref target="RFC2119"/>.</t>
      </section>
      <section title="Using +json-seq" anchor="usage">
         <t>The use case for the "+json-seq" structured syntax suffix is the same as for "+json": It SHOULD be used by media types when parsing the JSON Text Sequence of a media type leads to a meaningful result, by simply using the generic JSON Text Sequence processing.</t>
         <t>Applications encountering such a media type then can either simply use generic processing if all they need is a generic view of the JSON Text Sequence, or they can use generic JSON Text Sequence tools for initial parsing, and then can implement their own specific processing on top of that generic parsing tool.</t>
      </section>
      <section title="IANA Considerations" anchor="iana">
         <t>IANA has added the following "+json-seq" structured syntax suffix to its registry of structured syntax suffixes established by <xref target="RFC6838"/>:</t>
         <t>
            <list>
               <t>Name: JSON Text Sequence</t>
               <t>+suffix: +json-seq</t>
               <t>References: <xref target="RFC7464"/></t>
               <t>Encoding considerations: See <xref target="RFC7464"/></t>
               <t>Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +json-seq SHOULD be as specified for "application/json-seq". (At publication of this document, there is no fragment identification syntax defined for "application/json-seq".)<list>
                  <t>The syntax and semantics for fragment identifiers for a specific "xxx/yyy+json-seq" SHOULD be processed as follows:<list>
                        <t>For cases defined in +json-seq, where the fragment identifier resolves per the +json-seq rules, then process as specified in +json-seq.</t>
                        <t>For cases defined in +json-seq, where the fragment identifier does not resolve per the +json-seq rules, then process as specified in "xxx/yyy+json-seq".</t>
                        <t>For cases not defined in +json-seq, then process as specified in "xxx/yyy+json-seq".</t>
                     </list></t>
               </list></t>
               <t>Interoperability considerations: n/a</t>
               <t>Security considerations: See <xref target="RFC7464"/></t>
               <t>Contact: Applications and Real-Time Area Working Group (art@ietf.org)</t>
               <t>Author/Change controller: The Applications and Real-Time Area Working Group. IESG has change control over this registration.</t>
            </list>
         </t>
      </section>
   </middle>
   <back>
      <references title="Normative References">
         <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>
                  </address>
               </author>
               <date month="March" year="1997"/>
            </front>
            <seriesInfo name="RFC" value="2119"/>
         </reference>
         <reference  anchor='RFC6838' target='http://www.rfc-editor.org/info/rfc6838'>
            <front>
               <title>Media Type Specifications and Registration Procedures</title>
               <author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
               <author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
               <author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
               <date year='2013' month='January' />
               <abstract><t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t></abstract>
            </front>
            <seriesInfo name='BCP' value='13'/>
            <seriesInfo name='RFC' value='6838'/>
            <seriesInfo name='DOI' value='10.17487/RFC6838'/>
         </reference>
         <reference  anchor='RFC7464' target='http://www.rfc-editor.org/info/rfc7464'>
            <front>
               <title>JavaScript Object Notation (JSON) Text Sequences</title>
               <author initials='N.' surname='Williams' fullname='N. Williams'><organization /></author>
               <date year='2015' month='February' />
               <abstract><t>This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).</t></abstract>
            </front>
            <seriesInfo name='RFC' value='7464'/>
            <seriesInfo name='DOI' value='10.17487/RFC7464'/>
         </reference>
      </references>
      <references title="Non-Normative References">
         <reference anchor="RFC7195" target="http://www.rfc-editor.org/info/rfc7195">
            <front>
               <title>
                  Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)
               </title>
               <author initials="M." surname="Garcia-Martin" fullname="M. Garcia-Martin">
                  <organization/>
               </author>
               <author initials="S." surname="Veikkolainen" fullname="S. Veikkolainen">
                  <organization/>
               </author>
               <date year="2014" month="May"/>
               <abstract>
                  <t>
                     This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).
                  </t>
               </abstract>
            </front>
            <seriesInfo name="RFC" value="7195"/>
            <seriesInfo name="DOI" value="10.17487/RFC7195"/>
         </reference>
         <reference  anchor='RFC6839' target='http://www.rfc-editor.org/info/rfc6839'>
            <front>
               <title>Additional Media Type Structured Syntax Suffixes</title>
               <author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>
               <author initials='A.' surname='Melnikov' fullname='A. Melnikov'><organization /></author>
               <date year='2013' month='January' />
               <abstract><t>A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name.  This document defines several structured syntax suffixes for use with media type registrations.  In particular, it defines and registers the &quot;+json&quot;, &quot;+ber&quot;, &quot;+der&quot;, &quot;+fastinfoset&quot;, &quot;+wbxml&quot; and &quot;+zip&quot; structured syntax suffixes, and provides a media type structured syntax suffix registration form for the &quot;+xml&quot; structured syntax suffix.  This document  is not an Internet Standards Track specification; it is published for  informational purposes.</t></abstract>
            </front>
            <seriesInfo name='RFC' value='6839'/>
            <seriesInfo name='DOI' value='10.17487/RFC6839'/>
         </reference>
      </references>
      <!--
      <section title="Acknowledgements" anchor="acknowledgements">
         <t>Thanks for comments and suggestions provided by ...</t>
      </section>
      -->
   </back>
</rfc>
