idnits 2.17.1 draft-json-seq-suffix-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations: See [3]' ) ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2016) is 2747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft CA Technologies 4 Intended status: Standards Track September 19, 2016 5 Expires: March 23, 2017 7 A Media Type Structured Syntax Suffix for JSON Text Sequences 8 draft-json-seq-suffix-00 10 Abstract 12 Structured Syntax Suffixes for media types allow other media types to 13 build on them and make it explicit that they are built on an existing 14 media type as their foundation. This specification defines and 15 registers "json-seq" as a structured syntax suffix for JSON Text 16 Sequences. 18 Note to Readers 20 This draft should be discussed on the art mailing list [1]. 22 Online access to all versions and files is available on github [2]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 23, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Using +json-seq . . . . . . . . . . . . . . . . . . . . . . . 2 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 5.2. Non-Normative References . . . . . . . . . . . . . . . . 4 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1. Introduction 69 Media Type Structured Syntax Suffixes [2] were introduced as a way of 70 how a media type can signal that it is based on another media type as 71 its foundation. Some structured syntax suffixes were registered 72 initially [5], including "+json" for the widely popular JSON Format 73 [4] format. 75 JSON Text Sequences [3] is a new specification in the JSON space that 76 defines how a sequence of multiple JSON texts can be represented in 77 one representation. Since this specification can be used as the 78 foundation for other formats, this specification defines and 79 registers the "+json-seq" structured syntax suffix. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 [1]. 87 3. Using +json-seq 89 The use case for the "+json-seq" structured syntax suffix is the same 90 as for "+json": It SHOULD be used by media types when parsing the 91 JSON Text Sequence of a media type leads to a meaningful result, by 92 simply using the generic JSON Text Sequence processing. 94 Applications encountering such a media type then can either simply 95 use generic processing if all they need is a generic view of the JSON 96 Text Sequence, or they can use generic JSON Text Sequence tools for 97 initial parsing, and then can implement their own specific processing 98 on top of that generic parsing tool. 100 4. IANA Considerations 102 IANA has added the following "+json-seq" structured syntax suffix to 103 its registry of structured syntax suffixes established by [2]: 105 Name: JSON Text Sequence 107 +suffix: +json-seq 109 References: [3] 111 Encoding considerations: See [3] 113 Fragment identifier considerations: The syntax and semantics of 114 fragment identifiers specified for +json-seq SHOULD be as 115 specified for "application/json-seq". (At publication of this 116 document, there is no fragment identification syntax defined for 117 "application/json-seq".) 119 The syntax and semantics for fragment identifiers for a 120 specific "xxx/yyy+json-seq" SHOULD be processed as follows: 122 For cases defined in +json-seq, where the fragment 123 identifier resolves per the +json-seq rules, then process as 124 specified in +json-seq. 126 For cases defined in +json-seq, where the fragment 127 identifier does not resolve per the +json-seq rules, then 128 process as specified in "xxx/yyy+json-seq". 130 For cases not defined in +json-seq, then process as 131 specified in "xxx/yyy+json-seq". 133 Interoperability considerations: n/a 135 Security considerations: See [3] 137 Contact: Applications and Real-Time Area Working Group 138 (art@ietf.org) 140 Author/Change controller: The Applications and Real-Time Area 141 Working Group. IESG has change control over this registration. 143 5. References 145 5.1. Normative References 147 [1] Bradner, S., "Key words for use in RFCs to Indicate 148 Requirement Levels", RFC 2119, March 1997. 150 [2] Freed, N., Klensin, J., and T. Hansen, "Media Type 151 Specifications and Registration Procedures", BCP 13, 152 RFC 6838, DOI 10.17487/RFC6838, January 2013, 153 . 155 [3] Williams, N., "JavaScript Object Notation (JSON) Text 156 Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015, 157 . 159 5.2. Non-Normative References 161 [4] Garcia-Martin, M. and S. Veikkolainen, "Session 162 Description Protocol (SDP) Extension for Setting Audio and 163 Video Media Streams over Circuit-Switched Bearers in the 164 Public Switched Telephone Network (PSTN)", RFC 7195, 165 DOI 10.17487/RFC7195, May 2014, 166 . 168 [5] Hansen, T. and A. Melnikov, "Additional Media Type 169 Structured Syntax Suffixes", RFC 6839, 170 DOI 10.17487/RFC6839, January 2013, 171 . 173 Author's Address 175 Erik Wilde 176 CA Technologies 178 Email: erik.wilde@dret.net 179 URI: http://dret.net/netdret/