1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc8091.txt b/doc/rfc/rfc8091.txt
new file mode 100644
index 0000000..1be87e8
--- /dev/null
+++ b/doc/rfc/rfc8091.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          E. Wilde
+Request for Comments: 8091                               CA Technologies
+Category: Informational                                    February 2017
+ISSN: 2070-1721
+
+
+     A Media Type Structured Syntax Suffix for JSON Text Sequences
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8091.
+
+Copyright Notice
+
+   Copyright (c) 2017 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
+   described in the Simplified BSD License.
+
+
+
+
+
+Wilde                         Informational                     [Page 1]
+
+RFC 8091      JSON Text Sequences Structured Syntax Suffix February 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  The "+json-seq" Structured Syntax Suffix  . . . . . . . . . .   2
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5
+
+1.  Introduction
+
+   Media type structured syntax suffixes [RFC6838] were introduced as a
+   way for a media type to signal that it is based on another media type
+   as its foundation.  Some structured syntax suffixes were registered
+   initially [RFC6839], including "+json", for the widely popular JSON
+   format [RFC7159].
+
+   JSON text sequences [RFC7464] is a recent specification in the JSON
+   space that defines how a sequence of multiple JSON texts can be
+   represented in one representation.  This document defines and
+   registers the "+json-seq" structured syntax suffix in the "Structured
+   Syntax Suffix Registry".
+
+2.  Terminology
+
+   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].
+
+3.  The "+json-seq" Structured Syntax Suffix
+
+   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.
+
+   Applications encountering such a media type can then 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 implement their own specific processing on
+   top of that generic parsing tool.
+
+
+
+
+
+
+Wilde                         Informational                     [Page 2]
+
+RFC 8091      JSON Text Sequences Structured Syntax Suffix February 2017
+
+
+4.  IANA Considerations
+
+   Structured Syntax Suffixes are registered within the "Structured
+   Syntax Suffix Registry" maintained at
+   <https://www.iana.org/assignments/media-type-structured-suffix>.
+
+   IANA has registered the "+json-seq" structured syntax suffix in
+   accordance with [RFC6838].
+
+      Name: JSON Text Sequence
+
+      +suffix: +json-seq
+
+      References: [RFC7464], RFC 8091
+
+      Encoding considerations: See [RFC7464] Section 2.2
+
+      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".)
+
+         The syntax and semantics for fragment identifiers for a
+         specific "xxx/yyy+json-seq" SHOULD be processed as follows:
+
+            For cases defined in +json-seq, where the fragment
+            identifier resolves per the +json-seq rules, then process as
+            specified in +json-seq.
+
+            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".
+
+            For cases not defined in +json-seq, then process as
+            specified in "xxx/yyy+json-seq".
+
+      Interoperability considerations: n/a
+
+      Security considerations: See [RFC7464] Section 3
+
+      Contact: Applications and Real-Time Area Discussion
+      (art@ietf.org), or any IESG-designated successor.
+
+      Author/Change controller: The Applications and Real-Time Area
+      Working Group.  IESG has change control over this registration.
+
+
+
+
+
+Wilde                         Informational                     [Page 3]
+
+RFC 8091      JSON Text Sequences Structured Syntax Suffix February 2017
+
+
+5.  Security Considerations
+
+   All the security considerations of JSON text sequences [RFC7464]
+   apply.  They are as follows:
+
+   All the security considerations of JSON [RFC7159] apply.  This format
+   provides no cryptographic integrity protection of any kind.
+
+   As usual, parsers must operate on input that is assumed to be
+   untrusted.  This means that parsers must fail gracefully in the face
+   of malicious inputs.
+
+   Note that incremental JSON text parsers can produce partial results
+   and later indicate failure to parse the remainder of a text.  A
+   sequence parser that uses an incremental JSON text parser might treat
+   a sequence like '<RS>"foo"<LF>456<LF><RS>' as a sequence of one
+   element ("foo"), while a sequence parser that uses a non-incremental
+   JSON text parser might treat the same sequence as being empty.  This
+   effect, and texts that fail to parse and are ignored, can be used to
+   smuggle data past sequence parsers that don't warn about JSON text
+   failures.
+
+   Repeated parsing and re-encoding of a JSON text sequence can result
+   in the addition (or stripping) of trailing LF bytes from (to)
+   individual sequence element JSON texts.  This can break signature
+   validation.  JSON has no canonical form for JSON texts, therefore
+   neither does the JSON text sequence format.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13,
+              RFC 6838, DOI 10.17487/RFC6838, January 2013,
+              <http://www.rfc-editor.org/info/rfc6838>.
+
+   [RFC7464]  Williams, N., "JavaScript Object Notation (JSON) Text
+              Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
+              <http://www.rfc-editor.org/info/rfc7464>.
+
+
+
+
+
+
+Wilde                         Informational                     [Page 4]
+
+RFC 8091      JSON Text Sequences Structured Syntax Suffix February 2017
+
+
+6.2.  Informative References
+
+   [RFC6839]  Hansen, T. and A. Melnikov, "Additional Media Type
+              Structured Syntax Suffixes", RFC 6839,
+              DOI 10.17487/RFC6839, January 2013,
+              <http://www.rfc-editor.org/info/rfc6839>.
+
+   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
+              2014, <http://www.rfc-editor.org/info/rfc7159>.
+
+Acknowledgements
+
+   Thanks for comments and suggestions provided by Ben Campbell, Allan
+   Doyle, Warren Kumari, Sean Leonard, Alexey Melnikov, Brian Raymor,
+   and Peter Yee.
+
+Author's Address
+
+   Erik Wilde
+   CA Technologies
+
+   Email: erik.wilde@dret.net
+   URI:   http://dret.net/netdret/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wilde                         Informational                     [Page 5]
+