Media Types with Multiple Suffixes
draft-ietf-mediaman-suffixes-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (mediaman WG) | |
|---|---|---|---|
| Authors | Manu Sporny , Amy Guy | ||
| Last updated | 2022-02-16 (Latest revision 2021-12-01) | ||
| Replaces | draft-w3cdidwg-media-types-with-multiple-suffixes | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | AD is watching | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Murray Kucherawy | ||
| Send notices to | (None) |
draft-ietf-mediaman-suffixes-00
MEDIAMAN M.S. Sporny
Internet-Draft A.G. Guy
Intended status: Standards Track Digital Bazaar
Expires: 25 May 2022 November 2021
Media Types with Multiple Suffixes
draft-ietf-mediaman-suffixes-00
Abstract
This document updates RFC 6838 "Media Type Specifications and
Registration Procedures" to describe how to interpret subtypes with
multiple suffixes.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 May 2022.
Copyright Notice
Copyright (c) 2021 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Sporny & Guy Expires 25 May 2022 [Page 1]
Internet-Draft Media Types with Multiple Suffixes November 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. Media Types with Multiple Suffixes . . . . . . . . . . . . . 2
2.1. Processing Multiple Suffixes . . . . . . . . . . . . . . 3
3. Normative References . . . . . . . . . . . . . . . . . . . . 3
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
As written, RFC 6838 [RFC6838] permits the registration of media type
subtype names which contain any number of occurrences of the "+"
character. RFC 6838 defines the characters following the final "+"
to be a structured syntax suffix, but does not define anything
further about how to interpret subtype names containing more than one
"+" character.
This document updates RFC 6838 to clarify how to interpret subtype
names containing more than one "+" character as subtypes with
multiple suffixes.
As registration of media types which use a structured suffix has
become widely supported, this enables further specialization of media
types that build on already registered and well-defined media types
which themselves use a structured suffix.
1.1. Conventions Used in This Document
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] when they
appear in ALL CAPS. They may also appear in lower or mixed case as
plain English words, without any normative meaning.
2. Media Types with Multiple Suffixes
The following paragraphs are additions to RFC 6838.
Media types MAY be registered with more than one suffix appended to
the base subtype name. The suffixes MUST be interpreted as ordered.
Valid media type names containing a structured suffix are built from
right to left (not left to right). Characters on the left-most side
of the left-most "+" in a subtype name specify the base subtype name.
Characters to the right of each "+" in a subtype name denote
additional structured syntax specifier suffixes.
Sporny & Guy Expires 25 May 2022 [Page 2]
Internet-Draft Media Types with Multiple Suffixes November 2021
Media types with more than one suffix MUST be registered according to
the procedure defined in [RFC6838]. A new base subtype name MUST
only be registered with suffix combinations that are already
registered in their own right.
For example, a media type that uses the two suffixes "+svg+xml" is
only permitted insofar as "svg+xml" is already registered. In this
case, the suffix "+svg" does not need to be registered individually,
but "+xml" and "svg+xml" MUST be registered.
2.1. Processing Multiple Suffixes
Registered subtypes have clear processing rules. In cases where
specific handling of the exact media type is not required, receivers
of the media type MAY do generic processing on the underlying
representation according to their ability to process any subset of
the suffix(es) from right to left inclusive. In other words, an
application can choose to ignore the base subtype name and left-most
"+" from a media type with multiple suffixes, and process according
to the remaining media type suffix(es). An application can ignore as
many of the left-most suffixes as necessary to achieve a media type
that can be processed.
For example, for the media type "application/did+ld+json", the
following are all valid subtypes with their own individually
specified processing rules:
did+ld+json
ld+json
json
Thus applications can choose to process the underlying representation
according any of the following valid media types:
application/did+ld+json
application/ld+json
application/json
3. 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,
<https://www.rfc-editor.org/info/rfc2119>.
Sporny & Guy Expires 25 May 2022 [Page 3]
Internet-Draft Media Types with Multiple Suffixes November 2021
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
Appendix A. Acknowledgements
The editors would like to thank the following individuals for
feedback on the specification (in alphabetical order): Martin J.
Duerst, Ivan Herman, Graham Klyne, Murray S. Kucherawy, Manu Sporny,
Ted Thibodeau Jr.
Authors' Addresses
Manu Sporny
Digital Bazaar
203 Roanoke Street W.
Blacksburg, VA 24060
United States of America
Email: msporny@digitalbazaar.com
URI: http://manu.sporny.org/
Amy Guy
Digital Bazaar
203 Roanoke Street W.
Blacksburg, VA 24060
United States of America
Email: rhiaro@digitalbazaar.com
URI: https://rhiaro.co.uk/
Sporny & Guy Expires 25 May 2022 [Page 4]