<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-asap-siptrunkingcapability-link-05" number="9409" ipr="trust200902" xml:lang="en" obsoletes="" updates="" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2023-07-14T16:17:56" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-asap-siptrunkingcapability-link-05" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9409" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="'sip-trunking-capability' Link Type">The 'sip-trunking-capability' Link Relation Type</title>
    <seriesInfo name="RFC" value="9409" stream="IETF"/>
    <author initials="K." surname="Inamdar" fullname="Kaustubh Inamdar">
      <organization showOnFrontPage="true">Unaffiliated</organization>
      <address>
        <email>kaustubh.ietf@gmail.com</email>
        <uri/>
      </address>
    </author>
    <author initials="S." surname="Narayanan" fullname="Sreekanth Narayanan">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <email>sreenara@cisco.com</email>
        <uri/>
      </address>
    </author>
    <author initials="D." surname="Engi" fullname="Derek Engi">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <city>Ann Arbor</city>
          <region>MI</region>
          <country>United States of America</country>
        </postal>
        <phone>+1 919 392 7966</phone>
        <email>deengi@cisco.com</email>
        <uri/>
      </address>
    </author>
    <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street>7200-12 Kit Creek Rd.</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 919 392 3266</phone>
        <email>gsalguei@cisco.com</email>
        <uri/>
      </address>
    </author>
    <date month="07" year="2023"/>
    <area>art</area>
    <workgroup>asap</workgroup>
    <keyword>SIP</keyword>
    <keyword>Session Initiation Protocol</keyword>
    <keyword>automatic peering</keyword>
    <keyword>WebFinger</keyword>
    <keyword>capability set</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
      This Informational document defines the 'sip-trunking-capability' link relation type that may be used by an enterprise telephony Session Initiation Protocol (SIP) network to retrieve a SIP trunking capability set document, which contains the capabilities and configuration requirements of an Internet Telephony Service Provider (ITSP). These technical requirements allow for seamless peering between SIP-based enterprise telephony networks and the ITSP.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9409" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-sip-trunking-capability">The 'sip-trunking-capability' Link Relation Type</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-usage">Example Usage</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
      RFC 8288 <xref target="RFC8288" format="default" sectionFormat="of" derivedContent="RFC8288"/> defines a way to indicate relationships between
   resources on the Web. This document specifies the 'sip-trunking-capability' link
   relation type according to the rules of RFC 8288.  Links with this relationship type can be used to exchange capability information between potential peer devices. In the event that systems require additional parameters and configuration to negotiate communication, a well-known URI can be utilized to deliver information to potential peers, including machine-readable instructions and parameters needed for peering.
      </t>
      <t indent="0" pn="section-1-2">
      The 'sip-trunking-capability' link relation type may be used on web resources hosted by ITSPs to provide a structured and detailed capability set document.  The capability set document <xref target="I-D.ietf-asap-sip-auto-peer" format="default" sectionFormat="of" derivedContent="SIP-AUTO-PEER"/> encapsulates a set of characteristics of an ITSP, which when retrieved by enterprise telephony network devices allows for automated establishment of SIP <xref target="RFC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/> trunking between the two telephony networks.
      </t>
    </section>
    <section anchor="link-type" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-the-sip-trunking-capability">The 'sip-trunking-capability' Link Relation Type</name>
      <t indent="0" pn="section-2-1">
         A capability set document is hosted via web resources by the ITSP.  A unique location of the document can be preconfigured and provided to each peer by the ITSP, or a centrally published resource can be used that dynamically generates the capability set document based on one or more Uniform Resource Identifiers (URIs) <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/> determined by the peering device.  The capability set document describes the configuration parameters required to successfully establish SIP trunking between an enterprise and an ITSP network.  The capability set document is composed of structured and machine-readable parameters that can be converted into configuration data to meet the communication requirements of the ITSP.  The need for an enterprise telephony network to obtain a capability set document from an ITSP is documented in "Automatic Peering for SIP Trunks" <xref target="I-D.ietf-asap-sip-auto-peer" format="default" sectionFormat="of" derivedContent="SIP-AUTO-PEER"/>.  
      </t>
    </section>
    <section anchor="examples" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-example-usage">Example Usage</name>
      <t indent="0" pn="section-3-1">
            This section provides an example of possible use of the 'sip-trunking-capability' relation type.  The enterprise network device solicits the location of the capability set document from the well-known URI hosted by the ITSP using the WebFinger protocol <xref target="RFC7033" format="default" sectionFormat="of" derivedContent="RFC7033"/>. The following examples include line breaks and indentation for clarity.
      </t>
      <artwork name="" type="" align="left" alt="" pn="section-3-2">

   GET /.well-known/webfinger?
      resource=acct%3Atrunkent1456%40example.com&amp;
      rel=sip-trunking-capability
      HTTP/1.1
   Host: ssp1.example.com

</artwork>
      <t indent="0" pn="section-3-3">
            The location of the capability set document is returned to the network device in the "href" attribute. 
      </t>
      <artwork name="" type="" align="left" alt="" pn="section-3-4">

   HTTP/1.1 200 OK
   Access-Control-Allow-Origin: *
   Content-Type: application/jrd+json
   {
      "subject" : "acct:trunkent1456@example.com",
      "links" :
      [
         {
            "rel" : "sip-trunking-capability",
            "href" : "https://capserver.ssp1.example.com/capdoc.json"
         }
      ]
   }

</artwork>
      <t indent="0" pn="section-3-5">
         The ITSP may use an authentication framework such as OAuth 2.0 <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749"/> to determine the identity of the enterprise telephony network to provide the appropriate capability set document.
      </t>
    </section>
    <section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">IANA has registered the 'sip-trunking-capability' link relation under the "Link Relation Types" registry as follows:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-4-2">
        <dt pn="section-4-2.1">Relation Name:</dt>
        <dd pn="section-4-2.2">sip-trunking-capability</dd>
        <dt pn="section-4-2.3">Description:</dt>
        <dd pn="section-4-2.4">Refers to a capability set document that defines parameters or configuration requirements for automated peering and communication-channel negotiation of the Session Initiation Protocol (SIP).</dd>
        <dt pn="section-4-2.5">Reference:</dt>
        <dd pn="section-4-2.6">RFC 9409</dd>
      </dl>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
            The 'sip-trunking-capability' relation type is not known to introduce any new security issues not already discussed in RFC 8288 for generic use of web-linking mechanisms.  However, it is recommended to exercise caution when publishing potentially sensitive capability information over unencrypted or unauthenticated channels. Additional security recommendations are outlined in the capability set document definition. See the <xref target="I-D.ietf-asap-sip-auto-peer" sectionFormat="bare" section="Security Considerations" relative="#name-security-considerations" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-asap-sip-auto-peer-07#name-security-considerations" derivedContent="SIP-AUTO-PEER"/> section in "Automatic Peering for SIP Trunks" <xref target="I-D.ietf-asap-sip-auto-peer" format="default" sectionFormat="of" derivedContent="SIP-AUTO-PEER"/>.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-asap-sip-auto-peer" to="SIP-AUTO-PEER"/>
    <references pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC8288" target="https://www.rfc-editor.org/info/rfc8288" quoteTitle="true" derivedAnchor="RFC8288">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</t>
              <t indent="0">It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8288"/>
          <seriesInfo name="DOI" value="10.17487/RFC8288"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" quoteTitle="true" derivedAnchor="RFC3261">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
            <author fullname="A. Johnston" initials="A." surname="Johnston"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="R. Sparks" initials="R." surname="Sparks"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="E. Schooler" initials="E." surname="Schooler"/>
            <date month="June" year="2002"/>
            <abstract>
              <t indent="0">This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3261"/>
          <seriesInfo name="DOI" value="10.17487/RFC3261"/>
        </reference>
        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986" quoteTitle="true" derivedAnchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t indent="0">A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t indent="0">The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC7033" target="https://www.rfc-editor.org/info/rfc7033" quoteTitle="true" derivedAnchor="RFC7033">
          <front>
            <title>WebFinger</title>
            <author fullname="P. Jones" initials="P." surname="Jones"/>
            <author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="J. Smarr" initials="J." surname="Smarr"/>
            <date month="September" year="2013"/>
            <abstract>
              <t indent="0">This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7033"/>
          <seriesInfo name="DOI" value="10.17487/RFC7033"/>
        </reference>
        <reference anchor="I-D.ietf-asap-sip-auto-peer" target="https://datatracker.ietf.org/doc/html/draft-ietf-asap-sip-auto-peer-07" quoteTitle="true" derivedAnchor="SIP-AUTO-PEER">
          <front>
            <title>Automatic Peering for SIP Trunks</title>
            <author fullname="Kaustubh Inamdar" initials="K." surname="Inamdar">
              <organization showOnFrontPage="true">Unaffiliated</organization>
            </author>
            <author fullname="Sreekanth Narayanan" initials="S." surname="Narayanan">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Cullen Fluffy Jennings" initials="C. F." surname="Jennings">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date day="13" month="January" year="2023"/>
            <abstract>
              <t indent="0">This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-asap-sip-auto-peer-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
            This document resulted from the discussions in the ASAP Working Group, especially the detailed and thoughtful comments of <contact fullname="Paul Jones"/>, <contact fullname="Marc Petit-Huguenin"/>, <contact fullname="Mark Nottingham"/>, <contact fullname="Cullen Jennings"/>, <contact fullname="Jonathan Rosenberg"/>, <contact fullname="Jon Peterson"/>, <contact fullname="Chris Wendt"/>, <contact fullname="Jean Mahoney"/>, and <contact fullname="Murray Kucherawy"/>. Additional thanks to <contact fullname="Joe Clarke"/>, <contact fullname="Tim Bray"/>, <contact fullname="Christopher Wood"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="David Dong"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>, and <contact fullname="Lars Eggert"/> for their reviews and feedback.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="K." surname="Inamdar" fullname="Kaustubh Inamdar">
        <organization showOnFrontPage="true">Unaffiliated</organization>
        <address>
          <email>kaustubh.ietf@gmail.com</email>
          <uri/>
        </address>
      </author>
      <author initials="S." surname="Narayanan" fullname="Sreekanth Narayanan">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <email>sreenara@cisco.com</email>
          <uri/>
        </address>
      </author>
      <author initials="D." surname="Engi" fullname="Derek Engi">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <city>Ann Arbor</city>
            <region>MI</region>
            <country>United States of America</country>
          </postal>
          <phone>+1 919 392 7966</phone>
          <email>deengi@cisco.com</email>
          <uri/>
        </address>
      </author>
      <author initials="G." surname="Salgueiro" fullname="Gonzalo Salgueiro">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street>7200-12 Kit Creek Rd.</street>
            <city>Research Triangle Park</city>
            <region>NC</region>
            <code>27709</code>
            <country>United States of America</country>
          </postal>
          <phone>+1 919 392 3266</phone>
          <email>gsalguei@cisco.com</email>
          <uri/>
        </address>
      </author>
    </section>
  </back>
</rfc>
