draft-young-entity-category.xml

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-young-entity-category-07" submissionType="independent" category="info">
  <front>

    <title abbrev="Entity Category">
      The Entity Category SAML Attribute Types
    </title>

    <author initials="I.A." fullname="Ian A. Young" surname="Young" role="editor">
      <organization>Independent</organization>
      <address>
        <email>ian@iay.org.uk</email>
      </address>
    </author>

    <author fullname="Leif Johansson" initials="L." surname="Johansson">
      <organization>SUNET</organization>
      <address>
        <email>leifj@sunet.se</email>
      </address>
    </author>

    <author fullname="Scott Cantor" initials="S." surname="Cantor">
      <organization>Shibboleth Consortium</organization>
      <address>
        <email>cantor.2@osu.edu</email>
      </address>
    </author>

    <date/>

    <abstract>
      <t>
        This document describes a SAML entity attribute which can be used to
        assign category membership semantics to an entity, and a second attribute
        for use in claiming interoperation with or support for entities in such categories.
      </t>
      <t>
        This document is a product of the Research and Education Federations (REFEDS) Working Group process.
      </t>
    </abstract>

  </front>

  <middle>
    <section title="Introduction" anchor="introduction">
      <t>
        This document describes a SAML attribute, referred to here as the
        "entity category attribute", values of which represent entity types
        or categories. When used with the
        <xref target="SAML2MetadataAttr">SAML V2.0 Metadata Extension for Entity Attributes</xref>
        each such entity category attribute value represents a claim that the entity thus labelled
        meets the requirements of, and is asserted to be a member of, the indicated category.
      </t>

      <t>
        These category membership claims MAY be used by a relying party to provision policy
        for release of attributes from an identity provider, to influence user interface decisions
        such as those related to identity provider discovery, or for any other purpose.
        In general, the intended uses of any claim of membership in a given category will
        depend on the details of the category's definition, and will often be included as
        part of that definition.
      </t>

      <t>
        Entity category attribute values are URIs, and this document therefore does not specify a
        controlled vocabulary for assigning entity category values.  Category URIs may be defined 
        by any appropriate authority without any requirement for central registration.  It is anticipated that
        other specifications may provide management and discovery mechanisms for entity category
        attribute values.
      </t>

      <t>
        A second SAML attribute, referred to here as the "entity category support attribute",
        contains URI values which represent claims that an entity supports and/or interoperates with
        entities in a given category or categories. These values, defined in conjunction with
        specific entity category values, provide entities in a category with the means to identify
        peer entities that wish to interact with them in a fashion described by the category specification.
      </t>

      <t>
        This document does not specify any values either for the entity category attribute
        or for the entity category support attribute.
      </t>

      <section title="REFEDS Document Process">
        <t>
          The Research and Education Federations group (<xref target="REFEDS"/>)
          is the voice that articulates the mutual needs of research and education
          identity federations worldwide. It aims to represent the requirements of
          research and education in the ever-growing space of access and identity
          management.
        </t>
        <t>
          From time to time REFEDS
          will wish to publish a document in the Internet RFC series.  Such
          documents will be published as part of the RFC Independent Submission
          Stream <xref target="RFC4844"/>; however the REFEDS working group sign-off process will
          have been followed for these documents, as described in
          the <xref target="REFEDS.agreement">REFEDS Participant's Agreement</xref>.
        </t>
        <t>
          This document is a product of the REFEDS Working Group process.
        </t>
      </section>

    </section>

    <section title="Notation and Conventions">
      <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="BCP14">RFC 2119</xref>.
      </t>
    </section>

    <section title="Entity Category Attribute">
      <section anchor="cat-syntax" title="Syntax">
        <t>
          Entity category attribute values MUST be valid URIs. It is RECOMMENDED that http:-scheme
          or https:-scheme URIs are used, and further RECOMMENDED that an entity category URI
          resolves to a human-readable document defining the category.
        </t>

        <t>
          Authorities defining entity categories MUST produce a specification of the entity
          category and SHOULD make arrangement for the entity category URI to resolve to the
          specification in human readable form. 
        </t>

        <t>
          Authorities defining entity categories MAY use versioning of entity category URIs where 
          appropriate, in which case each version of the specification of the entity category 
          SHOULD clearly indicate the latest version of the entity category URI (and hence of the 
          specification). The specification SHOULD include a description of how the authority 
          defining the entity category implements governance for the specification in the case 
          when the specification may be updated.
        </t>

        <t>
          When used in SAML metadata or protocol elements, the entity category attribute MUST 
          be encoded as a SAML 2.0 Attribute element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri 
          and @Name http://macedir.org/entity-category.
        </t>

        <t>
          A SAML entity is associated with one or more categories by including the
          Attribute element described here in the entity's metadata through use of the
          <xref target="SAML2MetadataAttr"/> metadata extension, in which the
          Attribute element is contained within an mdattr:EntityAttributes
          element directly contained within an md:Extensions element directly
          contained within the entity's md:EntityDescriptor.
        </t>

        <t>
          The meaning of the entity category attribute is undefined by this specification if it
          appears anywhere else within a metadata instance, or within any other XML document.
        </t>

        <t>
          If the entity category attribute Attribute element appears more than once in the
          metadata for an entity, the combined set of associated attribute values SHOULD be
          interpreted by relying parties as if they all appeared within a single Attribute
          element.
        </t>
      </section>

      <section anchor="cat-semantics" title="Semantics">
        <t>
          The presence of the entity category attribute within an entity's entity attributes
          represents a series of claims (one for each attribute value) that the entity is
          a member of each named category.  The precise semantics of such a claim depend
          on the definition of the category itself.
        </t>

        <t>
          An entity may be claimed to be a member of more than one category. In this case, the entity
          is claimed to meet the requirements of each category independently unless otherwise
          specified by the category definitions themselves.
        </t>

        <t>
          The definition of the concept of a category is intentionally not addressed in this
          document, in order to leave it as general as possible.  However, to be useful,
          category definitions SHOULD include the following as appropriate:
          <list style="symbols">
            <t>
              A definition of the authorities who may validly assert
              membership in the category.  While membership in some categories may be
              self-asserted informally by an entity's owner, others may need to be
              validated by third parties such as the entity's home federation or other
              registrar.
            </t>
            <t>
              A set of criteria by which an entity's membership in the category can be
              objectively assessed.
            </t>
            <t>
              A definition of the processes by which valid authorities
              may determine that an entity meets the category's membership criteria.
            </t>
            <t>
              A description of the anticipated uses for category membership by relying parties.
            </t>
            <t>
              A statement indicating the applicability or otherwise of membership
              of the entity category to different SAML role descriptors, and any
              protocol support restrictions that may be relevant.
            </t>
          </list>
        </t>

        <t>
          Entity categories SHOULD NOT be used to indicate the certification
          status of an entity regarding its conformance to the requirements
          of an identity assurance framework.
          The <xref target="SAML2IDAssuranceProfile"/> extension SHOULD be used
          for this purpose.
        </t>

        <t>
          If significant changes are made to a category definition, the new version of
          the category SHOULD be represented by a different category URI
          so that the old and new versions can be distinguished by a relying party. It
          is for this reason that authorities defining entity categories MAY
          employ some form of versioning for entity category URI. When versioning is
          used each version of the entity category MUST be treated as a separate URI.
        </t>

        <t>
          No ordering relation is defined over entity category value URIs.
          Entity category attribute value URIs MUST be treated as opaque strings
          for the purpose of comparison. In particular, if the specification defining the
          entity category relies on versioning of the entity category URI, a relying
          party MUST NOT assume any particular ordering between different versions of
          the entity category. Any order between versions MUST be spelled out in the
          specification.
        </t>

      </section>

      <section title="Entity Category Example">
        <figure>
          <artwork><![CDATA[<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  entityID="https://service.example.com/entity">
  <md:Extensions>
    <mdattr:EntityAttributes
      xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
      <Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="http://macedir.org/entity-category">
        <AttributeValue
          >http://example.org/category/dog</AttributeValue>
        <AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
      </Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
  ...
</md:EntityDescriptor>]]></artwork>
        </figure>
      </section>
    </section>

    <section title="Entity Category Support Attribute">
      <section anchor="sup-syntax" title="Syntax">
        <t>
          Entity category support attribute values MUST be URIs.  It is RECOMMENDED that
          http:-scheme or https:-scheme URLs are used, and further RECOMMENDED that each
          such value resolves to a human-readable document defining the value's semantics.
          A given entity category value MAY be associated with multiple support values in
          order to allow for multiple forms of support, participation, or interoperation
          with entities in the category. The authoritiy defining the entity category and
          entity category support values MUST clearly describe the relationship between 
          (all versions of) the entity category URI and (all versions of) the entity 
          category support URIs as applicable in the entity category specification.
        </t>

        <t>
          The entity category support attribute MUST be encoded as a SAML 2.0 Attribute
          element with @NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri and
          @Name http://macedir.org/entity-category-support.
        </t>

        <t>
          Claims that a SAML entity implements support for one or more categories
          are represented by including the Attribute element described here in the entity's metadata
          through use of the <xref target="SAML2MetadataAttr"/> metadata extension, in
          which the Attribute element is contained within an mdattr:EntityAttributes
          element directly contained within an md:Extensions element directly
          contained within the entity's md:EntityDescriptor.
        </t>

        <t>
          The meaning of the entity category support attribute is undefined by this
          specification if it appears anywhere else within a metadata instance, or within
          any other XML document.
        </t>

        <t>
          If the entity category support attribute Attribute element appears more than once in the
          metadata for an entity, the combined set of associated attribute values SHOULD be
          interpreted by relying parties as if they all appeared within a single Attribute
          element.
        </t>
      </section>

      <section anchor="sup-semantics" title="Semantics">
        <t>
          The presence of the entity category support attribute within an entity's entity
          attributes represents a series of claims (one for each attribute
          value) that the entity supports peer entities in a category in a particular
          fashion. The precise semantics of such a claim depend on the definition of the
          category support identifier itself.
          Category support claims will often be defined to be self-asserted.
        </t>

        <t>
          An entity may be claimed to support more than one category. In this case, the entity
          is claimed to meet the support requirements of each category independently unless otherwise
          specified by the category definitions themselves.
        </t>

        <t>
          The definition of the concept of "support" for a category is intentionally not
          addressed in this document, in order to leave it as general as possible.  It is
          assumed that entity category definitions MAY define one or more support values
          signifying particular definitions for "support" by peers as motivated by use
          cases arising from the definition of the category itself.
        </t>

        <t>
          A common case is expected to be the definition of a single support value
          whose URI is identical to that defined for the category itself.
        </t>

        <t>
          If significant changes are made to a category support definition, the new version
          SHOULD be represented by a different category support URI so that the old and new 
          versions can be distinguished by a relying party. It is for this reason that 
          authorities defining entity categories support MAY employ some form of versioning. 
          When versioning is used each version of the entity category support URI MUST be treated 
          as a separate URI.
        </t>

        <t>
          No ordering relation is defined over entity category URIs.
          Entity category attribute support value URIs MUST be treated as opaque strings
          for the purpose of comparison. In particular, if the specification defining the
          entity category support values relies on versioning, a relying
          party MUST NOT assume any particular ordering between different versions of
          the entity category support URI. Any order between versions MUST be spelled 
          out in the specification.
        </t>

      </section>

      <section title="Entity Category Support Example">
        <figure>
          <artwork><![CDATA[<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  entityID="https://idp.example.edu/entity">
  <md:Extensions>
    <mdattr:EntityAttributes
      xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
      <Attribute xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        Name="http://macedir.org/entity-category-support">
        <AttributeValue
          >http://example.org/category/dog/basic</AttributeValue>
        <AttributeValue
          >http://example.org/category/dog/advanced</AttributeValue>
        <AttributeValue>urn:oid:1.3.6.1.4.1.21829</AttributeValue>
      </Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
  ...
</md:EntityDescriptor>]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
        The presence of the entity category attribute within an entity's entity attributes
        represents a series of claims (one for each attribute value) that the entity is
        a member of the named categories.  Before accepting and acting on such claims, any
        relying party needs to establish, at a level of assurance sufficient for the
        intended use, a chain of trust concluding that the claim is justified.
      </t>

      <t>
        Some of the elements in such a chain of trust might include:
        <list style="symbols">
          <t>
            The integrity of the metadata delivered to the relying party, as for example
            assured by a digital signature.
          </t>
          <t>
            If the entity category attribute is carried within a signed assertion, the assertion
            itself must be evaluated.
          </t>
          <t>
            The policies and procedures of the immediate source of the metadata;
            in particular, any procedures the immediate source has with regard to aggregation
            of metadata from other sources.
          </t>
          <t>
            The policies and procedures implemented by agents along the publication path from
            the original metadata registrar: this may be determined either by examination of
            the published procedures of each agent in turn, or may be simplified if the
            entity metadata includes publication path metadata in mdrpi:PublicationPath
            elements as described in
            <xref target="SAML2MetadataRPI"/> section 2.3.1.
          </t>
          <t>
            The policies and procedures implemented by the original metadata registrar.
            The registrar's identity may be known implicitly, or may be determined
            from the entity metadata if it includes an mdrpi:RegistrationInfo element
            and corresponding @registrationAuthority attribute as described in
            <xref target="SAML2MetadataRPI"/> section 2.1.1.
          </t>
          <t>
            The definition of the category itself; in particular, any statements it makes about
            whether membership of the category may be self-asserted, or may only be asserted
            by particular authorities.
          </t>
        </list>
      </t>
      <t>
        Although entity category support attribute values will often be defined as self-asserted
        claims by the containing entity, the provenance of the metadata remains
        relevant to a relying party's decision to accept a claim of support as legitimate,
        and the specific definition of a support claim will influence the assurance
        required to act on it.
      </t>

      <t>
        The conclusion that a claim of category membership or support is justified and
        should be acted upon may require a determination of the origin of the claim.
        This may not be necessary if the immediate source of the metadata is trusted to such
        an extent that the trust calculation is essentially delegated to it.
      </t>

      <t>
        In many cases, a claim will be included in an entity's metadata by the
        original metadata registrar on behalf of the entity's owner, and the mdrpi:RegistrationInfo
        element's @registrationAuthority attribute is available to carry the registrar's identity.
        However, any agent that is part of the chain of custody between the original registrar and the final
        relying party may have added, removed or transformed claims according to local policy.
        For example, an agent charged with redistributing metadata may remove claims it regards
        as untrustworthy, or add others which were not already present if they have value to
        its intended audience.
      </t>

    </section>
  </middle>

  <back>
    <references title="Normative References">

      <reference anchor="BCP14">
        <front>
          <title>
            Key words for use in RFCs to Indicate Requirement Levels
          </title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner">
            <organization>Harvard University</organization>
            <address><email>sob@harvard.edu</email></address>
          </author>
          <date month="March" year="1997"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
        <format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
        <format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
      </reference>

      <reference anchor="SAML2MetadataAttr"
        target="http://wiki.oasis-open.org/security/SAML2MetadataAttr">
        <front>
          <title>SAML V2.0 Metadata Extension for Entity Attributes</title>
          <author fullname="Scott Cantor" role="editor" initials="S." surname="Cantor"/>
          <date day="3" month="August" year="2009"/>
        </front>
        <format type="PDF" target="http://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-attr-cs-01.pdf"/>
      </reference>

      <reference anchor="SAML2MetadataRPI"
        target="http://wiki.oasis-open.org/security/SAML2MetadataDRI">
        <front>
          <title>SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0</title>
          <author surname="La Joie" initials="C." role="editor" fullname="Chad La Joie"/>
          <date day="3" month="April" year="2012"/>
        </front>
        <format type="PDF" target="http://docs.oasis-open.org/security/saml/Post2.0/saml-metadata-rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.pdf"/>
      </reference>

    </references>

    <references title="Informative References">

      <reference anchor='RFC4844'>
        <front>
          <title>The RFC Series and RFC Editor</title>
          <author initials='L.' surname='Daigle' fullname='L. Daigle'>
            <organization />
          </author>
          <author>
            <organization>Internet Architecture Board</organization>
          </author>
          <date year='2007' month='July' />
        </front>
        <seriesInfo name='RFC' value='4844' />
        <format type='TXT' octets='38752' target='http://www.rfc-editor.org/rfc/rfc4844.txt' />
      </reference>

      <reference anchor="REFEDS" target="http://www.refeds.org/">
        <front>
          <title>REFEDS Home Page</title>
          <author>
            <organization>Research and Education Federations</organization>
          </author>
          <date/>
        </front>
      </reference>

      <reference anchor="REFEDS.agreement" target="https://refeds.org/about/refeds-participants-agreement">
        <front>
          <title>REFEDS Participant's Agreement</title>
          <author>
            <organization>Research and Education Federations</organization>
          </author>
          <date/>
        </front>
      </reference>

      <reference anchor="SAML2IDAssuranceProfile"
        target="https://wiki.oasis-open.org/security/SAML2IDAssuranceProfile">
        <front>
          <title>SAML V2.0 Identity Assurance Profiles Version 1.0</title>
          <author fullname='RL "Bob" Morgan' role="editor" initials="RL" surname="Morgan"/>
          <author fullname="Paul Madsen" role="editor" initials="P" surname="Madsen"/>
          <author fullname="Scott Cantor" role="editor" initials="S." surname="Cantor"/>
          <date day="5" month="November" year="2010"/>
        </front>
        <format type="PDF" target="http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile-cs-01.pdf"/>
      </reference>

    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        This work has been a collaborative effort within the REFEDS and MACE-Dir
        communities. Special thanks to (in no particular order):
        <list style="symbols">
          <t>RL 'Bob' Morgan</t>

          <t>Ken Klingenstein</t>

          <t>Keith Hazelton</t>

          <t>Steven Olshansky</t>

          <t>Mikael Linden</t>

          <t>Nicole Harris</t>

          <t>Tom Scavo</t>
        </list>
      </t>
    </section>

    <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">

      <section title="Since draft-young-entity-category-05" anchor="changes.since.draft-young-entity-category-05">
        <t>
           Recommendation on versioning and language on requirements for entity category specification.
        </t>
      </section>

      <section title="Since draft-young-entity-category-04" anchor="changes.since.draft-young-entity-category-04">
        <t>
          No substantive changes.
        </t>
      </section>

      <section title="Since draft-young-entity-category-03" anchor="changes.since.draft-young-entity-category-03">
        <t>
          Additional improvements in response to IETF Gen-Art review:
          <list style="symbols">
            <t>
              <xref target="cat-semantics"/>:
              additional SHOULD language recommending that category definitions
              include applicability information for particular SAML role
              descriptors.
            </t>
            <t>
              <xref target="cat-semantics"/>:
              added an informative reference to <xref target="SAML2IDAssuranceProfile"/>
              and language recommending its use over entity categories
              where appropriate.
            </t>
          </list>
        </t>
      </section>

      <section title="Since draft-young-entity-category-02" anchor="changes.since.draft-young-entity-category-02">
        <t>
          Fix link to the <xref target="REFEDS.agreement">REFEDS Participant's Agreement</xref>.
        </t>
        <t>Clarifications in response to IETF Gen-Art review:
          <list style="symbols">
            <t>
              <xref target="introduction"/>: make explicit the fact that we don't specify any values of either
              attribute in this document.
            </t>
            <t>
              <xref target="cat-syntax"/>, <xref target="sup-syntax"/>:
              clarify that it is possible for attribute values to appear within multiple Attribute
              elements, and that this SHOULD be regarded as equivalent to combining them within a single
              Attribute element.
            </t>
            <t>
              <xref target="cat-semantics"/>, <xref target="sup-semantics"/>:
              clarify the expectation that categories are independent unless their
              definitions say otherwise.
            </t>
            <t>
              <xref target="cat-semantics"/>, <xref target="sup-semantics"/>:
              If significant changes are made to a category definition, the new version of
              the category SHOULD be represented by a different category URI
              <spanx style="strong">so that the old and new versions can be distinguished by a relying party</spanx>.
            </t>
            <t>
              <xref target="cat-semantics"/>, <xref target="sup-semantics"/>:
              <spanx style="strong">No ordering relation is defined over
              entity category value URIs.</spanx>
              Entity category attribute value URIs MUST be treated as opaque strings
              <spanx style="strong">for the purpose of comparison</spanx>.
            </t>
          </list>
        </t>
      </section>

      <section title="Since draft-young-entity-category-01" anchor="changes.since.draft-young-entity-category-01">
        <t>Changes from REFEDS consultation process:
          <list style="numbers">
            <t>
              Simplify title from "The Entity Category SAML Entity Metadata Attribute Types" to
              "The Entity Category SAML Attribute Types".
            </t>
            <t>
              Clarify the use of <xref target="SAML2MetadataRPI"/> in <xref target="Security"/> by
              indicating the elements and attributes to be used, and the sections of <xref target="SAML2MetadataRPI"/>
              in which they are defined.
            </t>
            <t>
              Remove any implication that category and category support claims are necessarily
              being made "by" the entity itself.
            </t>
            <t>
              Clarify that the origin of a category membership or support claim may not always be
              the original registrar.
            </t>
          </list>
        </t>
        <t>
          Grammar fix in Abstract.
        </t>
        <t>
          Change the reference anchor for the SAML <xref target="SAML2MetadataRPI"/> extension, as it now more
          commonly known as RPI than its original DRI abbreviation.
        </t>
      </section>

      <section title="Since draft-young-entity-category-00" anchor="changes.since.draft-young-entity-category-00">
        <t>
          Update affiliations for Leif Johansson and Scott Cantor.
        </t>
        <t>
          Remove authors from acknowledgements.
        </t>
        <t>
          Reorganize some of the introductory boilerplate sections.
        </t>
      </section>

      <section title="Since draft-macedir-entity-category" anchor="changes.since.draft-macedir-entity-category">
        <t>
          Adopted as base for draft-young-entity-category-00.
        </t>
        <t>
          Changed ipr from "pre5378Trust200902" to "trust200902" and
          submission type from IETF to independent.
        </t>
        <t>
          Designate Ian Young as editor for this version. Set more general
          affiliation.
        </t>
        <t>
          Modernised reference to <xref target="BCP14">RFC 2119</xref> and moved
          that reference to the introduction.
        </t>
        <t>
          Adjusted layout of examples so that they don't exceed the RFC standard
          line length.
        </t>
        <t>
          Minor typographical nits but (intentionally) no substantive
          content changes.
        </t>
      </section>

    </section>

  </back>
</rfc>