draft-ietf-cdni-media-type-02.txt   draft-ietf-cdni-media-type-03.txt 
CDNI K. Ma CDNI K. Ma
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track September 29, 2015 Intended status: Informational September 29, 2015
Expires: April 1, 2016 Expires: April 1, 2016
CDNI Media Type Registration CDNI Media Type Registration
draft-ietf-cdni-media-type-02 draft-ietf-cdni-media-type-03
Abstract Abstract
This document defines the standard media type used by the Content This document defines the standard media type used by the Content
Delivery Network Interconnection (CDNI) protocol suite, including the Delivery Network Interconnection (CDNI) protocol suite, including the
registration procedure and recommended usage of the required payload- registration procedure and recommended usage of the required payload-
type parameter . type parameter .
Requirements Language
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 [RFC2119].
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.
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/.
skipping to change at page 2, line 14 skipping to change at page 2, line 9
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 and Scope . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2
2.1. CDNI Media Type . . . . . . . . . . . . . . . . . . . . . 3 2.1. CDNI Media Type . . . . . . . . . . . . . . . . . . . . . 2
2.2. CDNI Payload Type Parameter Registry . . . . . . . . . . 4 2.2. CDNI Payload Type Parameter Registry . . . . . . . . . . 4
3. Normative References . . . . . . . . . . . . . . . . . . . . 5 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Normative References . . . . . . . . . . . . . . . . . . 5
3.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction and Scope 1. Introduction and Scope
The CDNI working group is developing a set of protocols to enable the The CDNI working group is developing a set of protocols to enable the
interconnection of multiple CDNs, as discussed in [RFC6770]. The interconnection of multiple CDNs, as discussed in [RFC6770]. The
CDNI protocol suite consists of multiple HTTP-based interfaces, many CDNI protocol suite consists of multiple HTTP-based interfaces, many
of which transfer various JSON encoded payloads [RFC7159]. The main of which transfer various JSON encoded payloads [RFC7159]. The main
interfaces (i.e., CDNI Control interface, CDNI Footprint & interfaces (i.e., CDNI Control interface, CDNI Footprint &
skipping to change at page 3, line 43 skipping to change at page 3, line 35
to transfer large amounts of data which may overload unexpecting to transfer large amounts of data which may overload unexpecting
clients. The individual CDNI interface specifications provide clients. The individual CDNI interface specifications provide
more detailed analysis of security and privacy concerns, and more detailed analysis of security and privacy concerns, and
define the requirements for authentication, authorization, define the requirements for authentication, authorization,
confidentiality, integrity, and privacy for each interface. confidentiality, integrity, and privacy for each interface.
Interoperability considerations: Interoperability considerations:
The required ptype field is intended to fully describe the The required ptype field is intended to fully describe the
structure and parsing of CDNI messages, as enforced by the ptype structure and parsing of CDNI messages, as enforced by the ptype
registry expert reviewer. registry designated expert.
Published specification: RFCthis Published specification: RFCthis
Applications that use this media type: Applications that use this media type:
CDNI is intended for use between interconnected CDNs for sharing CDNI is intended for use between interconnected CDNs for sharing
configuration and logging data, as well as for issuing content configuration and logging data, as well as for issuing content
management and redirection requests. management and redirection requests.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
skipping to change at page 4, line 32 skipping to change at page 4, line 23
Restrictions on usage: Restrictions on usage:
This media type is intended only for use in CDNI protocol message This media type is intended only for use in CDNI protocol message
exchanges. exchanges.
Author: IETF CDNI working group Author: IETF CDNI working group
Change controller: IETF CDNI working group Change controller: IETF CDNI working group
Provisional registration: yes Provisional registration: no
2.2. CDNI Payload Type Parameter Registry 2.2. CDNI Payload Type Parameter Registry
The IANA is requested to create a new "CDNI Payload Type" registry. The IANA is requested to create a new "CDNI Payload Type" registry.
The "CDNI Payload Type" namespace defines the valid values for the The "CDNI Payload Type" namespace defines the valid values for the
required "ptype" parameter of the "application/cdni" media type. The required "ptype" parameter of the "application/cdni" media type. The
CDNI Payload Type is an ASCII string value, consisting of only CDNI Payload Type is an ASCII string value, consisting of only
visible (printing) characters, but excluding equal signs (=), double visible (printing) characters, but excluding equal signs (=), double
quotes ("), and semicolons (;), and not exceeding 256 characters in quotes ("), and semicolons (;), and not exceeding 256 characters in
length. length.
Additions to the CDNI Payload Type namespace conform to the "Expert ptype = 1*256(ptype-char)
Review" policy as defined in [RFC5226]. The expert review will ptype-char = %x21 / %23-3A / %x3C / %x3E-7E
verify that new type definitions do not duplicate existing type ; Includes ALPHA, DIGIT, and other printables
definitions (in name or functionality), prevent gratuitous additions ; Excludes equal signs (=), double quotes ("), semicolons (;)
to the namespace, and prevent any additions to the namespace which
would impair the interoperability of CDNI implementations. The
expert review will include review of a publicly available written
specification (preferably an RFC, though an RFC is not required).
The expert review will verify the following information is documented Additions to the CDNI Payload Type namespace will conform to the
in the written specification: "Specification Required" policy as defined in [RFC5226]. The
designated expert will verify that new type definitions do not
duplicate existing type definitions (in name or functionality),
prevent gratuitous additions to the namespace, and prevent any
additions to the namespace which would impair the interoperability of
CDNI implementations. The designated expert will review the
specification, even if it is a Standards Track RFC, to verify that it
contains the following information:
o The review will verify that the specification contains a o The review will verify that the specification contains a
reasonably defined purpose for the new payload type, where the reasonably defined purpose for the new payload type, where the
purpose is related to an existing or proposed CDNI interface and purpose is related to an existing or proposed CDNI interface and
does not duplicate the functionality of any existing CDNI protocol does not duplicate the functionality of any existing CDNI protocol
feature without specifying a rational reason (e.g., updating an feature without specifying a rational reason (e.g., updating an
obsolete feature), a method for detecting and handling conflicts obsolete feature), a method for detecting and handling conflicts
(e.g., a versioning system with prioritization matrix), and a (e.g., a versioning system with prioritization matrix), and a
suggested migration path (e.g., deprecation of the overlapped suggested migration path (e.g., deprecation of the overlapped
feature, or justification for co-existence). feature, or justification for co-existence).
skipping to change at page 5, line 41 skipping to change at page 5, line 35
The registry contains the Payload Type, and the specification The registry contains the Payload Type, and the specification
describing the Payload Type. The registry will initially be describing the Payload Type. The registry will initially be
unpopulated. unpopulated.
+--------------+---------------+ +--------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+--------------+---------------+ +--------------+---------------+
+--------------+---------------+ +--------------+---------------+
3. Normative References 3. References
3.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
3.2. Informative References
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>. November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[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>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
 End of changes. 11 change blocks. 
23 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/