< draft-wilde-json-seq-suffix-01.txt		draft-wilde-json-seq-suffix-03.txt >
	Network Working Group E. Wilde		Network Working Group E. Wilde
	Internet-Draft CA Technologies		Internet-Draft CA Technologies
	Intended status: Experimental November 28, 2016		Intended status: Informational December 31, 2016
	Expires: June 1, 2017		Expires: July 4, 2017
	A Media Type Structured Syntax Suffix for JSON Text Sequences		A Media Type Structured Syntax Suffix for JSON Text Sequences
	draft-wilde-json-seq-suffix-01		draft-wilde-json-seq-suffix-03
	Abstract		Abstract
	Structured Syntax Suffixes for media types allow other media types to		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		build on them and make it explicit that they are built on an existing
	media type as their foundation. This specification defines and		media type as their foundation. This specification defines and
	registers "+json-seq" as a structured syntax suffix for JSON Text		registers "+json-seq" as a structured syntax suffix for JSON Text
	Sequences.		Sequences.
	Note to Readers		Note to Readers
			[[ The RFC Editor is requested to remove this section at publication.
			]]
	This draft should be discussed on the ietf mailing list		This draft should be discussed on the ietf mailing list
	(<https://www.ietf.org/mailman/listinfo/ietf>).		(<https://www.ietf.org/mailman/listinfo/ietf>).
	Online access to all versions and files is available on GitHub		Online access to all versions and files is available on GitHub
	(<https://github.com/dret/I-D/tree/master/json-seq-suffix>).		(<https://github.com/dret/I-D/tree/master/json-seq-suffix>).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 45 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 1, 2017.		This Internet-Draft will expire on July 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. The "+json-seq" Structured Syntax Suffix . . . . . . . . . . 2		3. The "+json-seq" Structured Syntax Suffix . . . . . . . . . . 3
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	6.1. Normative References . . . . . . . . . . . . . . . . . . 4		6.1. Normative References . . . . . . . . . . . . . . . . . . 4
	6.2. Non-Normative References . . . . . . . . . . . . . . . . 5		6.2. Informative References . . . . . . . . . . . . . . . . . 5
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	Media Type Structured Syntax Suffixes [RFC6838] were introduced as a		Media Type Structured Syntax Suffixes [RFC6838] were introduced as a
	way for a media type to signal that is based on another media type as		way for a media type to signal that it is based on another media type
	its foundation. Some structured syntax suffixes were registered		as its foundation. Some structured syntax suffixes were registered
	initially [RFC6839], including "+json" for the widely popular JSON		initially [RFC6839], including "+json" for the widely popular JSON
	Format [RFC7159] format.		Format [RFC7159].
	JSON Text Sequences [RFC7464] is a new specification in the JSON		JSON Text Sequences [RFC7464] is a recent specification in the JSON
	space that defines how a sequence of multiple JSON texts can be		space that defines how a sequence of multiple JSON texts can be
	represented in one representation. Since this specification can be		represented in one representation. This document defines and
	used as the foundation for other formats, this specification defines		registers the "+json-seq" structured syntax suffix in the Structured
	and registers the "+json-seq" structured syntax suffix.		Syntax Suffix Registry.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. The "+json-seq" Structured Syntax Suffix		3. The "+json-seq" Structured Syntax Suffix
	The use case for the "+json-seq" structured syntax suffix is the same		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		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		JSON Text Sequence of a media type leads to a meaningful result, by
	simply using the generic JSON Text Sequence processing.		simply using the generic JSON Text Sequence processing.
	Applications encountering such a media type can then either simply		Applications encountering such a media type can then either simply
	use generic processing if all they need is a generic view of the JSON		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		Text Sequence, or they can use generic JSON Text Sequence tools for
	initial parsing, and then can implement their own specific processing		initial parsing, and then can implement their own specific processing
	on top of that generic parsing tool.		on top of that generic parsing tool.
	4. IANA Considerations		4. IANA Considerations
	IANA has added the following "+json-seq" structured syntax suffix to		Structured Syntax Suffixes are registered within the "Structured
	its registry of structured syntax suffixes established by [RFC6838]:		Syntax Suffix Registry" maintained at
			<https://www.iana.org/assignments/media-type-structured-suffix>.
			IANA is requested to register the "+json-seq" structured syntax
			suffix in accordance with [RFC6838].
	Name: JSON Text Sequence		Name: JSON Text Sequence
	+suffix: +json-seq		+suffix: +json-seq
	References: [RFC7464]		References: [RFC7464], RFC [[ RFC Editor, please insert assigned
			RFC number. ]]
	Encoding considerations: See [RFC7464] Section 2.2		Encoding considerations: See [RFC7464] Section 2.2
	Fragment identifier considerations: The syntax and semantics of		Fragment identifier considerations: The syntax and semantics of
	fragment identifiers specified for +json-seq SHOULD be as		fragment identifiers specified for +json-seq SHOULD be as
	specified for "application/json-seq". (At publication of this		specified for "application/json-seq". (At publication of this
	document, there is no fragment identification syntax defined for		document, there is no fragment identification syntax defined for
	"application/json-seq".)		"application/json-seq".)
	The syntax and semantics for fragment identifiers for a		The syntax and semantics for fragment identifiers for a
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 12 ¶
	identifier does not resolve per the +json-seq rules, then		identifier does not resolve per the +json-seq rules, then
	process as specified in "xxx/yyy+json-seq".		process as specified in "xxx/yyy+json-seq".
	For cases not defined in +json-seq, then process as		For cases not defined in +json-seq, then process as
	specified in "xxx/yyy+json-seq".		specified in "xxx/yyy+json-seq".
	Interoperability considerations: n/a		Interoperability considerations: n/a
	Security considerations: See [RFC7464] Section 3		Security considerations: See [RFC7464] Section 3
	Contact: Applications and Real-Time Area Working Group		Contact: Applications and Real-Time Area Discussion
	(art@ietf.org)		(art@ietf.org), or any IESG designated successor.
	Author/Change controller: The Applications and Real-Time Area		Author/Change controller: The Applications and Real-Time Area
	Working Group. IESG has change control over this registration.		Working Group. IESG has change control over this registration.
	5. Security Considerations		5. Security Considerations
	All "Security Considerations" (Section 3) of RFC 7464 [RFC7464]		All the security considerations of JSON Text Sequences [RFC7464]
	apply. They are as follows:		apply. They are as follows:
	All the security considerations of JSON [RFC7159] apply. This format		All the security considerations of JSON [RFC7159] apply. This format
	provides no cryptographic integrity protection of any kind.		provides no cryptographic integrity protection of any kind.
	As usual, parsers must operate on input that is assumed to be		As usual, parsers must operate on input that is assumed to be
	untrusted. This means that parsers must fail gracefully in the face		untrusted. This means that parsers must fail gracefully in the face
	of malicious inputs.		of malicious inputs.
	Note that incremental JSON text parsers can produce partial results		Note that incremental JSON text parsers can produce partial results
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 14 ¶
	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type		[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	Specifications and Registration Procedures", BCP 13,		Specifications and Registration Procedures", BCP 13,
	RFC 6838, DOI 10.17487/RFC6838, January 2013,		RFC 6838, DOI 10.17487/RFC6838, January 2013,
	<http://www.rfc-editor.org/info/rfc6838>.		<http://www.rfc-editor.org/info/rfc6838>.
	[RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text		[RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text
	Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,		Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
	<http://www.rfc-editor.org/info/rfc7464>.		<http://www.rfc-editor.org/info/rfc7464>.
	6.2. Non-Normative References		6.2. Informative References
	[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type		[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
	Structured Syntax Suffixes", RFC 6839,		Structured Syntax Suffixes", RFC 6839,
	DOI 10.17487/RFC6839, January 2013,		DOI 10.17487/RFC6839, January 2013,
	<http://www.rfc-editor.org/info/rfc6839>.		<http://www.rfc-editor.org/info/rfc6839>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <http://www.rfc-editor.org/info/rfc7159>.		2014, <http://www.rfc-editor.org/info/rfc7159>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Thanks for comments and suggestions provided by Allan Doyle, Sean		Thanks for comments and suggestions provided by Ben Campbell, Allan
	Leonard, and Alexey Melnikov.		Doyle, Warren Kumari, Sean Leonard, Alexey Melnikov, Brian Raymor,
			and Peter Yee.
	Author's Address		Author's Address
	Erik Wilde		Erik Wilde
	CA Technologies		CA Technologies
	Email: erik.wilde@dret.net		Email: erik.wilde@dret.net
	URI: http://dret.net/netdret/		URI: http://dret.net/netdret/
End of changes. 17 change blocks.
	23 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/