<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='no'?>
<?rfc linkmailto='no'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc comments='yes'?>
<?rfc inline='yes'?>
<?rfc-ext parse-xml-in-artwork='yes' ?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc ipr='trust200902' docName='draft-ietf-appsawg-media-type-suffix-regs-04'
     category='bcp' updates='3023'>
  <front>
    <title abbrev='Additional Media Type Suffixes'>Additional Media Type Structured Syntax Suffixes</title>
    <author initials='T.' surname='Hansen' fullname='Tony Hansen'>
      <organization>AT&amp;T Laboratories</organization>
      <address>
        <postal>
          <street>200 Laurel Ave. South</street>
          <city>Middletown</city>
          <region>NJ</region>
          <code>07748</code>
          <country>USA</country>
        </postal>
        <email>tony+sss@maillennium.att.com</email>
      </address>
    </author>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization>Isode Ltd</organization>
      <address>
        <postal>
          <street>5 Castle Business Village</street>
          <street>36 Station Road</street>
          <city>Hampton</city>
          <region>Middlesex</region>
          <code>TW12 2BX</code>
          <country>UK</country>
        </postal>
        <email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
    <date />
    <area>Applications</area>
    <abstract>
      <t>
	A content media type name sometimes includes partitioned
	meta-information distinguish by a Structured Syntax, to permit noting an
	attribute of the media as a suffix to the name.
	This document defines several Structured Syntax Suffixes for use with media type registrations.
	In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml"
	and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration.
      </t>
    </abstract>
  </front>
  <middle>
    <section title='Introduction'>
      <t>
	<xref target='RFC3023'/> created the +xml suffix convention that can be used when
	defining names for media types whose representation uses XML underneath. That is,
	they could have been successfully
	parsed as if the media type had been application/xml in addition to their being parsed
	as their media type that is using the +xml suffix.
	<xref target='I-D.ietf-appsawg-media-type-regs'/> defines the Message Type Structured Syntax
	Suffixes registry to be used for such Structured Syntax Suffixes.
      </t>
      <t>
	A variety of Structured Syntax Suffixes have already been used in some media type registrations,
	in particular "+json", "+der", "+fastinfoset" and "+wbxml".
	This document defines and registers these Structured Syntax Suffixes in the
	Structured Syntax Suffix registry, along with "+ber" and "+zip".
	In addition, this document updates the "+xml" Structured Syntax Suffix registration.
	<!--
	    <a>dssc+der</a>

	    <a href="/assignments/media-types/application/soap+fastinfoset">soap+fastinfoset</a>

	    <a href="/assignments/media-types/application/vnd.collection+json">vnd.collection+json</a>
	    <a href="/assignments/media-types/application/vnd.hal+json">vnd.hal+json</a>
	    <a href="/assignments/media-types/application/vnd.oftn.l10n+json">vnd.oftn.l10n+json</a>

	    <a href="/assignments/media-types/application/vnd.nokia.conml+wbxml">vnd.nokia.conml+wbxml</a>
	    <a href="/assignments/media-types/application/vnd.nokia.landmark+wbxml">vnd.nokia.landmark+wbxml</a>
	    <a href="/assignments/media-types/application/vnd.nokia.pcd+wbxml">vnd.nokia.pcd+wbxml</a>
	    <a href="/assignments/media-types/application/vnd.syncml.dm+wbxml">vnd.syncml.dm+wbxml</a>
	    <a href="/assignments/media-types/application/vnd.wv.csp+wbxml">vnd.wv.csp+wbxml</a>

	    -->
      </t>
      <t>
	Discussion of this document should occur in the Apps Area Working Group (apps-discuss@ietf.org).
	[RFC Editor note: remove this paragraph.]
      </t>
      <t>
	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 <xref target='RFC2119'/>.
      </t>
    </section>
    <section title='When to Use these Structured Syntax Suffixes'>
      <t>
	Each of the Structured Syntax Suffixes defined in this document is appropriate for
	use when the media type identifies the semantics of the protocol payload. That is,
	knowing the semantics of the specific media type provides for more specific processing
	of the content than that afforded by generic processing of the underlying representation.
      </t>
      <t>
	At the same time, using the suffix allows receivers of the media types to do generic
	processing of the underlying representation in cases where
	<list hangIndent='0'>
	  <t>they do not need to perform special handling of the particular semantics of the
	    exact media type, and,
	  </t>
	  <t>there is no special knowledge needed by such a generic processor in order to
	    parse that underlying representation other than what would be needed to parse
	    any example of that underlying representation.
	  </t>
	</list>
      </t>
    </section>
    <section title='Initial Structured Syntax Suffix Definitions'>
      <section title='The +json Structured Syntax Suffix' anchor='json'>
	<t>
	  <xref target='RFC4627'/> defines the "application/json" media type.
	  The suffix "+json" MAY be used with any media type whose representation follows that established
	  for "application/json".
	  The Message Type Structured Syntax Suffix registration form follows.
	  See <xref target='I-D.ietf-appsawg-media-type-regs'/> for definitions of each of the registration
	  form headings.
	  <list style='hanging' hangIndent='20'>
	    <t hangText='Name:'>
	      JavaScript Object Notation (JSON)
	    </t>
	    <t hangText='+suffix:'>
	      +json
	    </t>
	    <t hangText='References:'>
	      <xref target='RFC4627'/>
	    </t>
	    <t hangText='Encoding considerations:'>
	      Per <xref target='RFC4627'/>, JSON is allowed to be represented using UTF-8, UTF-16, or UTF-32.
	      When JSON is written in UTF-8, JSON is 8bit compatible (<xref target='RFC2045'/>).
	      When JSON is written in UTF-16 or UTF-32, JSON is binary (<xref target='RFC2045'/>).
	    </t>
	    <t hangText='Fragment identifier considerations:'>
        <list hangIndent='0'>
		<t>
		  The syntax and semantics of fragment identifiers specified for +json
		  SHOULD be as specified for "application/json".
		  (At publication of this document, there is no fragment identification syntax
		  defined for "application/json".)
		</t>
		<t>
		  The syntax and semantics for fragment identifiers for a specific
		  "xxx/yyy+json" SHOULD be processed as follows:
		  <list>
		    <t>For cases defined in +json, where the fragment identifier resolves per
		      the +json rules, then as specified in +json.
		    </t>
		    <t>
		      For cases defined in +json, where the fragment identifier does not resolve per
		      the +json rules, then as specified in "xxx/yyy+json".
		    </t>
		    <t>
		      For cases not defined in +json, then as specified in "xxx/yyy+json".
		    </t>
		  </list>
		</t>
	      </list>
	    </t>
	    <t hangText='Interoperability considerations:'>
	      n/a
	    </t>
	    <t hangText='Security considerations:'>
	      See <xref target='RFC4627'/>
	    </t>
	    <t hangText='Contact:'>
	      Apps Area Working Group (apps-discuss@ietf.org)
	    </t>
	    <t hangText='Author/Change controller:'>
	      The Apps Area Working Group has change control over this registration.
	    </t>
	  </list>
	</t>
      </section>

      <section title='The +ber Structured Syntax Suffixes' anchor='ber'>
	<t>
	  The ITU defined the Basic Encoding Rules (BER)
	  message transfer syntax in <xref target='ITU.X690.2008'/>.
	  The suffix "+ber" MAY be used with any media type
	  whose representation follows the BER message transfer syntax.
	  The Message Type Structured Syntax Suffix registration form for +ber follows:
	  <list style='hanging' hangIndent='20'>
	    <t hangText='Name:'>
	      Basic Encoding Rules (BER) message transfer syntax
	    </t>
	    <t hangText='+suffix:'>
	      +ber
	    </t>
	    <t hangText='References:'>
	      <xref target='ITU.X690.2008'/>
	    </t>
	    <t hangText='Encoding considerations:'>
	      BER is a binary encoding.
	    </t>
      <t hangText='Fragment identifier considerations:'>
        <list hangIndent='0'>
          <t>
            At publication of this document, there is no fragment identification syntax
            defined for +ber.
          </t>
          <t>
            The syntax and semantics for fragment identifiers for a specific
            "xxx/yyy+ber" SHOULD be processed as follows:
            <list>
              <t>
                For cases defined in +ber, where the fragment identifier resolves per
                the +ber rules, then as specified in +ber.
              </t>
              <t>
                For cases defined in +ber, where the fragment identifier does not resolve per
                the +ber rules, then as specified in "xxx/yyy+ber".
              </t>
              <t>
                For cases not defined in +ber, then as specified in "xxx/yyy+ber".
              </t>
            </list>
          </t>
        </list>
      </t>
      <t hangText='Interoperability considerations:'>
	      n/a
	    </t>
	    <t hangText='Security considerations:'>
	      Each individual media type registered with a +ber suffix can
	      have additional security considerations.
	    </t>
	    <t>
	      BER has a type-length-value structure, and it is easy to
	      construct malicious content with invalid length fields that can cause buffer
	      overrun conditions.
	    </t>
	    <t>
	      Some BER schema allow for arbitrary levels of nesting, which may
	      make it possible to construct malicious content that will cause a stack
	      overflow.
	    </t>
	    <t>
	      Interpreters of the BER structures should be aware of these issues
	      and should take appropriate measures to guard against buffer overflows
	      and stack overruns in particular and malicious content in general.
	    </t>
	    <t hangText='Contact:'>
	      Apps Area Working Group (apps-discuss@ietf.org)
	    </t>
	    <t hangText='Author/Change controller:'>
	      The Apps Area Working Group has change control over this registration.
	    </t>
	  </list>
	</t>
      </section>
      <section title='The +der Structured Syntax Suffixes' anchor='der'>
	<t>
	  The ITU defined the Distinguished Encoding Rules (DER)
	  message transfer syntax in <xref target='ITU.X690.2008'/>.
	  The suffix "+der" MAY be used with any media type
	  whose representation follows the DER message transfer syntax.
	  The Message Type Structured Syntax Suffix registration form for +der follows:
	  <list style='hanging' hangIndent='20'>
	    <t hangText='Name:'>
	      Distinguished Encoding Rules (DER) message transfer syntax
	    </t>
	    <t hangText='+suffix:'>
	      +der
	    </t>
	    <t hangText='References:'>
	      <xref target='ITU.X690.2008'/>
	    </t>
	    <t hangText='Encoding considerations:'>
	      DER is a binary encoding.
	    </t>
      <t hangText='Fragment identifier considerations:'>
        <list hangIndent='0'>
          <t>
            At publication of this document, there is no fragment identification syntax
            defined for +der.
          </t>
          <t>
            The syntax and semantics for fragment identifiers for a specific
            "xxx/yyy+der" SHOULD be processed as follows:
            <list>
              <t>
                For cases defined in +der, where the fragment identifier resolves per
                the +der rules, then as specified in +der.
              </t>
              <t>
                For cases defined in +der, where the fragment identifier does not resolve per
                the +der rules, then as specified in "xxx/yyy+der".
              </t>
              <t>
                For cases not defined in +der, then as specified in "xxx/yyy+der".
              </t>
            </list>
          </t>
        </list>
      </t>
      <t hangText='Interoperability considerations:'>
	      n/a
	    </t>
	    <t hangText='Security considerations:'>
	      Each individual media type registered with a +der suffix can
	      have additional security considerations.
	    </t>
	    <t>
	      DER has a type-length-value structure, and it is easy to
	      construct malicious content with invalid length fields that can cause buffer
	      overrun conditions.
	    </t>
	    <t>
	      Some DER schema allow for arbitrary levels of nesting, which may
	      make it possible to construct malicious content that will cause a stack
	      overflow.
	    </t>
	    <t>
	      Interpreters of the DER structures should be aware of these issues
	      and should take appropriate measures to guard against buffer overflows
	      and stack overruns in particular and malicious content in general.
	    </t>
	    <t hangText='Contact:'>
	      Apps Area Working Group (apps-discuss@ietf.org)
	    </t>
	    <t hangText='Author/Change controller:'>
	      The Apps Area Working Group has change control over this registration.
	    </t>
	  </list>
	</t>
      </section>

      <section title='The +fastinfoset Structured Syntax Suffix' anchor='fastinfoset'>
	<t>
	  The ITU defined the Fast Infoset document format as a binary representation of the XML Information Set in
	  <xref target='ITU.X891.2005'/>.
	  These documents further define the "application/fastinfoset" media type.
	  The suffix "+fastinfoset" MAY be used with any media type whose representation
	  follows that established for "application/fastinfoset".
	  The Message Type Structured Syntax Suffix registration form follows:
	  <list style='hanging' hangIndent='20'>
	    <t hangText='Name:'>
	      Fast Infoset document format
	    </t>
	    <t hangText='+suffix:'>
	      +fastinfoset
	    </t>
	    <t hangText='References:'>
	      <xref target='ITU.X891.2005'/>
	    </t>
	    <t hangText='Encoding considerations:'>
	      Fast Infoset is a binary encoding. The binary, quoted-printable and base64 content-transfer-encodings
	      are suitable for use with Fast Infoset.
	    </t>
	    <t hangText='Fragment identifier considerations:'>
        <list hangIndent='0'>
		<t>
		  The syntax and semantics of fragment identifiers specified for +fastinfoset
		  SHOULD be as specified for "application/fastinfoset".
		  (At publication of this document, there is no fragment identification syntax
		  defined for "application/fastinfoset".)
		</t>
		<t>
		  The syntax and semantics for fragment identifiers for a specific
		  "xxx/yyy+fastinfoset" SHOULD be processed as follows:
		  <list>
		    <t>For cases defined in +fastinfoset, where the fragment identifier resolves per
		      the +fastinfoset rules, then as specified in +fastinfoset.
		    </t>
		    <t>
		      For cases defined in +fastinfoset, where the fragment identifier does not resolve per
		      the +fastinfoset rules, then as specified in "xxx/yyy+fastinfoset".
		    </t>
		    <t>
		      For cases not defined in +fastinfoset, then as specified in "xxx/yyy+fastinfoset".
		    </t>
		  </list>
		</t>
	      </list>
	    </t>
	    <t hangText='Interoperability considerations:'>
	      n/a
	    </t>
	    <t hangText='Security considerations:'>
	      There are no security considerations inherent in Fast Infoset. Each individual media type
	      registered with a +fastinfoset suffix can have additional security considerations.
	    </t>
	    <t hangText='Contact:'>
	      Apps Area Working Group (apps-discuss@ietf.org)
	    </t>
	    <t hangText='Author/Change controller:'>
	      The Apps Area Working Group has change control over this registration.
	    </t>
	  </list>
	</t>
      </section>

      <section title='The +wbxml Structured Syntax Suffix' anchor='wbxml'>
	<t>
	  The WAP Forum has defined the WAP Binary XML (WBXML) document format
	  as a binary representation of XML in <xref target='WBXML'/>.
	  This document further defines the "application/vnd.wap.wbxml" media type.
	  The suffix "+wbxml" MAY be used with any media type whose representation
	  follows that established for "application/vnd.wap.wbxml".
	  The Message Type Structured Syntax Suffix registration form follows:
	  <list style='hanging' hangIndent='20'>
	    <t hangText='Name:'>
	      WAP Binary XML (WBXML) document format
	    </t>
	    <t hangText='+suffix:'>
	      +wbxml
	    </t>
	    <t hangText='References:'>
	      <xref target='WBXML'/>
	    </t>
	    <t hangText='Encoding considerations:'>
	      WBXML is a binary encoding.
	    </t>
	    <t hangText='Fragment identifier considerations:'>
	      <list hangIndent='0'>
		<t>
		  The syntax and semantics of fragment identifiers specified for +wbxml
		  SHOULD be as specified for "application/vnd.wap.wbxml".
		  (At publication of this document, there is no fragment identification syntax
		  defined for "application/vnd.wap.wbxml".)
		</t>
		<t>
		  The syntax and semantics for fragment identifiers for a specific
		  "xxx/yyy+wbxml" SHOULD be processed as follows:
		  <list>
		    <t>For cases defined in +wbxml, where the fragment identifier resolves per
		      the +wbxml rules, then as specified in +wbxml.
		    </t>
		    <t>
		      For cases defined in +wbxml, where the fragment identifier does not resolve per
		      the +wbxml rules, then as specified in "xxx/yyy+wbxml".
		    </t>
		    <t>
		      For cases not defined in +wbxml, then as specified in "xxx/yyy+wbxml".
		    </t>
		  </list>
		</t>
	      </list>
	    </t>
	    <t hangText='Interoperability considerations:'>
	      n/a
	    </t>
	    <t hangText='Security considerations:'>
	      There are no security considerations inherent in WBXML.
	      Each individual media type registered with a +wbxml suffix can have additional security considerations.
	    </t>
	    <t hangText='Contact:'>
	      Apps Area Working Group (apps-discuss@ietf.org)
	    </t>
	    <t hangText='Author/Change controller:'>
	      The Apps Area Working Group has change control over this registration.
	    </t>
	  </list>
	</t>
      </section>

      <section title='The +zip Structured Syntax Suffix' anchor='zip'>
	<t>
	  The ZIP format is a public domain, cross-platform, interoperable file storage and transfer format, originally defined
	  by PKWARE, Inc.;
	  it supports compression and encryption and is used as the underlying representation by a variety of file formats.
	  The media type "application/zip" has been registered for such files.
	  The suffix "+zip" MAY be used with any media type whose representation follows that established for "application/zip".
	  The Message Type Structured Syntax Suffix registration form follows:
	  <list style='hanging' hangIndent='20'>
	    <t hangText='Name:'>
	      ZIP file storage and transfer format
	    </t>
	    <t hangText='+suffix:'>
	      +zip
	    </t>
	    <t hangText='References:'>
	      <xref target='ZIP'/>
	    </t>
	    <t hangText='Encoding considerations:'>
	      ZIP is a binary encoding.
	    </t>
	    <t hangText='Fragment identifier considerations:'>
	      <list hangIndent='0'>
		<t>
		  The syntax and semantics of fragment identifiers specified for +zip
		  SHOULD be as specified for "application/zip".
		  (At publication of this document, there is no fragment identification syntax
		  defined for "application/zip".)
		</t>
		<t>
		  The syntax and semantics for fragment identifiers for a specific
		  "xxx/yyy+zip" SHOULD be processed as follows:
		  <list>
		    <t>For cases defined in +zip, where the fragment identifier resolves per
		      the +zip rules, then as specified in +zip.
		    </t>
		    <t>
		      For cases defined in +zip, where the fragment identifier does not resolve per
		      the +zip rules, then as specified in "xxx/yyy+zip".
		    </t>
		    <t>
		      For cases not defined in +zip, then as specified in "xxx/yyy+zip".
		    </t>
		  </list>
		</t>
	      </list>
	    </t>
	    <t hangText='Interoperability considerations:'>
	      n/a
	    </t>
	    <t hangText='Security considerations:'>
	      ZIP files support two forms of encryption: Strong Encryption and AES 128-bit, 192-bit and 256-bit encryption;
	      see the specification for further details.
	      Each individual media type registered with a +zip suffix can have additional security considerations.
	    </t>
	    <t hangText='Contact:'>
	      Apps Area Working Group (apps-discuss@ietf.org)
	    </t>
	    <t hangText='Author/Change controller:'>
	      The Apps Area Working Group has change control over this registration.
	    </t>
	  </list>
	</t>
      </section>
    </section>
    <section title='IANA Considerations'>
      <t>
	See the Message Type Structured Syntax Suffix registration forms in <xref target='json'/> - <xref target='zip'/>.
      </t>
      <t>
	The existing Structured Syntax Suffix registration for "+xml" is modified to include the following
	<list style='hanging' hangIndent='20'>
	  <t hangText='Fragment identifier considerations:'>
	    <list hangIndent='0'>
	      <t>
		The syntax and semantics of fragment identifiers specified for +xml
		SHOULD be as specified for "application/xml".
		(At publication of this document, the fragment identification syntax
		considerations for "application/xml" are defined in <xref target='RFC3023'/>, sections 5 and 7.)
	      </t>
	      <t>
		The syntax and semantics for fragment identifiers for a specific
		"xxx/yyy+xml" SHOULD be processed as follows:
		<list>
		  <t>For cases defined in +xml, where the fragment identifier resolves per
		    the +xml rules, then as specified in +xml.
		  </t>
		  <t>
		    For cases defined in +xml, where the fragment identifier does not resolve per
		    the +xml rules, then as specified in "xxx/yyy+xml".
		  </t>
		  <t>
		    For cases not defined in +xml, then as specified in "xxx/yyy+xml".
		  </t>
		</list>
	      </t>
	    </list>
	  </t>
	</list>
      </t>
    </section>

    <section title='Security Considerations'>
      <t>
	See the Security considerations sections found in the Message Type Structured Syntax
	Suffix registration forms from <xref target='json'/> - <xref target='wbxml'/>.
      </t>

      <t>
  When updating a +&lt;suffix&gt; registration, care should be taken to review all
  previously-registered xxx/yyy+&lt;suffix&gt; media types as to whether they
  might be affected by the updated +&lt;suffix&gt; registration.
  Because the generic fragment identifier processing rules take precedence over media-type-specific rules,
  introducing new or changing existing definitions may break the existing registrations of specific
  media types, as well as particular implementations of applications that process affected media types.
  Such changes can introduce interoperability and security issues.
      </t>

      <t>
  When updating the fragment identifier processing rules for a specific media type, care should be taken
  to review the generic fragment identifier processing rules for the +&lt;suffix&gt; registration and
  not introduce any conflicts. Because the generic fragment identifier processing rules take precedence
  over media-type-specific rules, such conflicting processing requirements should be ignored by
  an implementation, but such conflicts can introduce interoperability and security issues.       
      </t>
      
    </section>
  </middle>

  <back>
    <references title='Normative References'>
      <?rfc include='reference.RFC.4627' ?>
      <reference anchor="ITU.X690.2008">
	<front>
	  <title>Recommendation ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules:
	    Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and
	    Distinguished encoding rules (DER)</title>
	  <author>
	    <organization>International Telecommunications Union</organization>
	  </author>
	  <date month="November" year="2008" />
	</front>
	<seriesInfo name="ITU-T" value="Recommendation X.690" />
	<!-- http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf -->
      </reference>

      <reference anchor="ITU.X891.2005">
	<front>
	  <title>Recommendation ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications of ASN.1: Fast infoset</title>
	  <author>
	    <organization>International Telecommunications Union</organization>
	  </author>
	  <date month="May" year="2005" />
	</front>
	<seriesInfo name="ITU-T" value="Recommendation X.891" />
	<!-- http://www.itu.int/rec/T-REC-X.891-200505-I/en -->
      </reference>

      <reference anchor="WBXML">
	<front>
	  <title>Binary XML Content Format Specification</title>
	  <author>
	    <organization>Open Mobile Alliance</organization>
	  </author>
	  <date month='July' year='2001'/>
	</front>
	<seriesInfo name='OMA' value='Wireless Access Protocol WAP-192-WBXML-20010725-a'/>
      </reference>

      <reference anchor="ZIP">
	<front>
	  <title>APPNOTE.TXT - .ZIP File Format Specification</title>
	  <author>
	    <organization>PKWARE, Inc.</organization>
	    <address>
	      <uri>http://www.pkware.com/documents/casestudies/APPNOTE.TXT</uri>
	      <!-- http://www.iana.org/assignments/media-types/application/zip -->
	    </address>
	  </author>
	  <date month='September' year='2007'/>
	</front>
	<seriesInfo name='PKWARE' value='.ZIP File Format Specification - Version 6.3.2'/>
      </reference>
      <?rfc include='reference.RFC.2045' ?>
      <?rfc include='reference.RFC.2119' ?>
      <?rfc include='reference.RFC.3023' ?>
    </references>

    <references title='Informative References'>
      <?rfc include='reference.I-D.ietf-appsawg-media-type-regs' ?>
    </references>
    <section title="Change History">
      <t>This section is to be removed before publication.
	<list style='hanging' hangIndent='20'>
    <t hangText='draft-ietf-appsawg-media-type-suffix-regs-03'>
      Added generic fragment idenfier rules to +ber/+der to make them consistant with other registrations.
      <vspace/>
      Added some warning about how adding/changing fragment identifier rules for a +suffix
      can affect fragment identifier processing rules for previously registered xxx/yyy+suffix media types.
      <vspace/>

    </t>
    <t hangText='draft-ietf-appsawg-media-type-suffix-regs-02'>
	    Added BER/DER security considerations.
	    <vspace/>
	    Reworked fragment identifier wording some more.
	    <vspace/>

	  </t>
	  <t hangText='draft-ietf-appsawg-media-type-suffix-regs-01'>
	    Reordered the sections.
	    <vspace/>
	    Cleaned up some MUSTard.
	    <vspace/>
	    Fixed some references.
	    <vspace/>
	    Added encoding considerations.
	    <vspace/>
	    Reworked fragment identifier wording.
	  </t>
	  <t hangText='draft-ietf-appsawg-media-type-suffix-regs-00'>
	    Added the fragment identifier consideration sections.
	    <vspace/>
	    Added a note about +xml fragment identifier considerations.
	  </t>
	  <t hangText='draft-hansen-media-type-suffix-regs-02'>
	    Added +zip.
	    <vspace/>
	    Fixed up the ISO document references.
	    <vspace/>
	    Minor changes.
	  </t>
	  <t hangText='draft-hansen-media-type-suffix-regs-01'>
	    Added +ber.
	    <vspace/>
	    Minor changes.
	  </t>
	</list>
      </t>
    </section>
  </back>
</rfc>
