One document matched: draft-thomson-geopriv-held-beep-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2045 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3080 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3080.xml">
<!ENTITY RFC3490 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3958 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml">
<!ENTITY RFC3986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY RFC4346 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC4395 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.winterbottom-geopriv-lis2lis-req PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-lis2lis-req.xml">
<!ENTITY I-D.winterbottom-geopriv-held-lis2lis-bcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-held-lis2lis-bcp.xml">
]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="full3978" docName="draft-thomson-geopriv-held-beep-01.txt">
<front>
<title abbrev="HELD over BEEP">
A BEEP Binding for the HELD Protocol
</title>
<author initials="M." surname="Thomson"
fullname="Martin Thomson">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<author initials="J." surname="Winterbottom"
fullname="James Winterbottom">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2938</phone>
<email>james.winterbottom@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<date month="November" year="2007"/>
<area>Application</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>BEEP</keyword>
<keyword>HELD</keyword>
<keyword>LIS</keyword>
<abstract>
<t>A BEEP binding is described for HELD. This binding is more suitable than the basic HTTP binding in scenarios where multiple messages are sent between the same two parties.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The HTTP binding for <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> provides a basis for the protocol, which does not encumber implementations with a complex protocol stack. However, some applications require that a requester make multiple requests in parallel to a Location Information Server (LIS). <xref target="I-D.winterbottom-geopriv-lis2lis-req"/> and <xref target="I-D.winterbottom-geopriv-held-lis2lis-bcp"/> describe use cases and an application of HELD where HTTP is suboptimal.
</t>
<t>The HTTP binding is not suitable in volume scenarios because HTTP suffers from head-of-queue blocking. This prevents multiple requests from being processed in parallel. In order to achieve higher throughput, the requester must establish multiple TCP connections in parallel. This causes HTTP to be unsuitable for applications where multiple parallel requests are expected by increasing the overheads.
</t>
<t><xref target="RFC3080">BEEP</xref> provides a framing scheme that allows for parallel requests. BEEP uses <xref target="RFC2045">MIME</xref> for its messages, which means that no significant modifications are required to carry HELD messages. This document describes a BEEP profile for HELD.
</t>
<section anchor="terminology" title="Terminology">
<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>
<section anchor="profile" title="The HELD BEEP Profile">
<t>The BEEP profile for HELD is identified as:
<list><t>urn:ietf:params:xml:ns:geopriv:held:beep</t></list>
This identifier is used in the BEEP <spanx style="verb">profile</spanx> element during channel creation.
</t>
<t>The HELD channel is a simple continuous channel that does not require any state information. Requests and their respective responses are always in the request-response form (<spanx style="verb">MSG</spanx>/<spanx style="verb">RPY</spanx>).
</t>
<section title="Channel Initialization">
<figure>
<preamble>The HELD profile is started with a single <spanx style="verb">profile</spanx> request. No additional parameters are required. When initiating a channel the <spanx style="verb">profile</spanx> element MUST be empty, as shown in the example below.
</preamble>
<artwork><![CDATA[
<start number="1" serverName="lis.example.com">
<profile uri="urn:ietf:params:xml:ns:geopriv:held:beep"/>
</start>
]]></artwork>
<postamble>The <spanx style="verb">serverName</spanx> attribute on the <spanx style="verb">start</spanx> message serves the same purpose as the <xref target="RFC2616">HTTP</xref> <spanx style="verb">Host</spanx> header in informing the server of the name it is known by.
</postamble>
</figure>
<figure>
<preamble>Similarly, the response to channel initialization MUST be empty.
</preamble>
<artwork><![CDATA[
<profile uri="urn:ietf:params:xml:ns:geopriv:held:beep"/>
]]></artwork>
</figure>
</section>
<section title="Message Exchange Pattern">
<t>The BEEP binding for HELD requires only the <spanx style="verb">MSG</spanx>/<spanx style="verb">RPY</spanx> message exchange. Each <spanx style="verb">MSG</spanx> frame contains a request, which may be either a <spanx style="verb">locationRequest</spanx>, <spanx style="verb">createContext</spanx> or <spanx style="verb">updateContext</spanx>. Each <spanx style="verb">RPY</spanx> frame includes a response, either a PIDF-LO (i.e. <spanx style="verb">presence</spanx>), or a <spanx style="verb">contextResponse</spanx>.
</t>
<figure>
<preamble>The following exchange demonstrates how a simple HELD location request and response are encapsulated. The <spanx style="verb">C:</spanx> and <spanx style="verb">S:</spanx> prefixes on lines are used following the convention in <xref target="RFC3080"/>.
</preamble>
<artwork><![CDATA[
C: MSG 1 7 . 544 125
C: Content-Type: application/held+xml
C:
C: <?xml version="1.0"?>
C: <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
C: END
S: RPY 1 7 . 1902 695
S: Content-Type: application/held+xml
S:
S: <?xml version="1.0"?>
S: <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
S: <!-- PIDF-LO contents not shown -->
S: </locationResponse>
S: END
]]></artwork>
</figure>
</section>
<section title="Error Handling">
<t>The HELD BEEP binding does not use the BEEP <spanx style="verb">ERR</spanx> message to indicate errors at the HELD protocol level. Errors in handling HELD Requests are indicated to the requester in a <spanx style="verb">RPY</spanx> message.
</t>
<t>Errors in the BEEP message that are unrelated to the HELD protocol, such as MIME formatting problems, are indicated using the BEEP <spanx style="verb">ERR</spanx> message.
</t>
</section>
</section>
<section anchor="uri" title="The "held+beep:" URI">
<t>A new URI form is defined to describe a BEEP binding instance. The <spanx style="verb">held+beep:</spanx> URI includes server, port and an identifier that can be used to construct a location reference. The <spanx style="verb">held+beep:</spanx> URI is constructed as shown in <xref target="uri-abnf"/> using <xref target="RFC4234">ABNF</xref> and the definitions for URI components from <xref target="RFC3986"/>.
</t>
<figure anchor="uri-abnf" title="The "held+beep:" URI">
<artwork type="abnf"><![CDATA[
; all undefined items are specified in RFC 3986
HB-URI = "held+beep" ":" hier-part [ "?" query ]
hier-part = "//" authority path-abempty / path-absolute
/ path-rootless / path-empty
authority = host ":" port
]]></artwork>
</figure>
<t>There is no well-known port for this binding; therefore, the port component of the URI MUST be included.
</t>
<section title="Location By-Reference and the BEEP Binding">
<t>The <spanx style="verb">path</spanx> and <spanx style="verb">query</spanx> components of the <spanx style="verb">held+beep:</spanx> URI are used in a similar fashion to the analagous components in <xref target="RFC2616">HTTP/1.1</xref>. These components can be conveyed for each request by including them in the MIME headers for each request.
</t>
<t>The <spanx style="verb">Request-URI</spanx> header includes an absolute path and optional query components. The header is shown in <xref target="req-uri"/>, using <xref target="RFC4234">ABNF</xref>.
</t>
<figure anchor="req-uri" title="The Request-URI Header">
<artwork type="abnf"><![CDATA[
Request-URI-Header = "Request-URI" ":" Request-URI
; Request-URI from RFC 2616
]]></artwork>
</figure>
<t>This header is modelled on the <spanx style="verb">Request-URI</spanx> field in <xref target="RFC2616">HTTP/1.1</xref> and it follows the same rules. See Section 5.1.2 of <xref target="RFC2616"/> for details on how to use this header. A value of <spanx style="verb">*</spanx> implies that no location URI is being used, this value should be assumed when the header is omitted. A value of <spanx style="verb">*</spanx> is assumed if a <spanx style="verb">held+beep:</spanx> URI does not contain path or query elements.
</t>
</section>
</section>
<section anchor="discovery" title="LIS Discovery and Authentication for BEEP">
<t>This profile is most suited to situations where a client and LIS exchange a large number of requests over a prolonged period. It is anticipated that the client and LIS are known to each other.
</t>
<t>Based on this assumption, it is reasonable for the LIS and its clients to have pre-existing configuration that makes discovery unnecessary. In addition, authentication details and methods can be pre-configured on both nodes. This section outlines how discovery can be performed for a LIS that supports the BEEP binding.
</t>
<!--
<section title="S-NAPTR Discovery">
<t>In discovering a BEEP-enabled LIS, the client needs to discover the IP address of the LIS host and the TCP port that the LIS service uses. The discovery methods described in <xref target="I-D.thomson-geopriv-lis-discovery"/> are applicable to discovering a BEEP-enabled LIS. The <spanx style="verb">held+beep:</spanx> URI type is used to represent a HELD service that supports the BEEP binding (see <xref target="uri"/>).
</t>
<t>Unlike in <xref target="I-D.thomson-geopriv-lis-discovery"/>, where a URI is required, this BEEP binding does not necessarily require a full URI. This creates an alternative method of DNS discovery based on <xref target="RFC3958">Straightforward NAPTR (S-NAPTR)</xref>. If the LIS discovery Dynamic Delegation Discovery Service (DDDS) application is used, a terminal "s" flag MAY be used. If an "s" flag is used, the corresponding <spanx style="verb">held+beep:</spanx> URI is constructed with no path information.
</t>
<t>This document registers a new protocol tag for a BEEP enabled LIS. The <spanx style="verb">HELD+BEEP</spanx> Application Protocol tag. The terminal record for this application protocol type is an <xref target="RFC2782">SRV record</xref>. Domain discovery can be applied in the same way as described in <xref target="I-D.thomson-geopriv-lis-discovery"/>.
</t>
<figure>
<preamble>The following example shows the BEEP and HTTP bindings for the <spanx style="verb">example.com</spanx> LIS. This resolves to port 8773 of the host at <spanx style="verb">lis.example.com</spanx>, or the URI <spanx style="verb">held+beep://lis.example.com:8773</spanx>:
</preamble>
<artwork><![CDATA[
example.com.
;; order pref flags
IN NAPTR 100 10 "u" "LIS:HELD" ( ; service
"!*.!https://lis.example.com/!" ; regex
. ; replacement
)
IN NAPTR 100 10 "s" "LIS:HELD+BEEP" ( ; service
"" ; regex
lis.example.com. ; replacement
)
lis.example.com.
;; order pref port host
IN SRV 100 10 8773 lis.example.com.
]]></artwork>
</figure>
</section>
<section title="Authentication"></section>
-->
<t>Regardless of the method used to determine the address of the LIS, a client MUST authenticate the LIS. This prevents any LIS spoofing attacks that could be used to acquire information about the client (and in turn, their clients).
</t>
<t>For persistent connections, it is RECOMMENDED that the LIS also authenticate clients. Some authorization decision is likely to be necessary in order for a client to initiate a large volume of requests, which could represent significant load on a LIS.
</t>
<t>This document does not mandate any specific authentication method; however, since TLS MUST be implemented, the mandatory methods in <xref target="RFC4346"/> are assumed to be present. Alternative authentication methods can be negotiated between the LIS and its clients.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t><xref target="RFC4346">TLS</xref> SHOULD be used for HELD over BEEP unless confidentiality, message integrity and authentication are assured through other means (e.g. dedicated media). It is RECOMMENDED that BEEP peers establish a TLS connection immediately, rather than relying on the TLS tuning profile in BEEP.
</t>
<!--
<t>Discovery using DDDS is subject to the same limitations and considerations outlined in <xref target="I-D.thomson-geopriv-lis-discovery"/>. However, the discovery process is less applicable to the scenarios in which this binding is considered appropriate, namely where pre-arranged relationships between LIS and client are relied upon.
</t>
-->
</section>
<section anchor="iana" title="IANA Considerations">
<section title="BEEP Profile Registration">
<t>This section outlines the HELD BEEP binding in the form described in <xref target="RFC3080"/>.
<list style="hanging">
<t hangText="Profile Identification:">urn:ietf:params:xml:ns:geopriv:held:beep</t>
<t hangText="Messages exchanged during Channel Creation:">none</t>
<t hangText="Messages starting one-to-one exchanges:">HELD request messages from <xref target="I-D.ietf-geopriv-http-location-delivery"/> and extension documents.</t>
<t hangText="Messages in positive replies:">HELD request messages from <xref target="I-D.ietf-geopriv-http-location-delivery"/> and extension documents.</t>
<t hangText="Messages in negative replies:">The HELD <spanx style="verb">error</spanx> message</t>
<t hangText="Messages in one-to-many exchanges:">none</t>
<t hangText="Message Syntax:">c.f., <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref></t>
<t hangText="Message Semantics:">c.f., <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref></t>
<t hangText="Contact Information:">c.f., the "Author's Address" section of this document</t>
</list></t>
</section>
<section title="URN sun-namespace registration for 'urn:ietf:params:xml:ns:geopriv:held:beep'">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:beep</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:held:beep</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t>XML:
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD BEEP Binding</title>
</head>
<body>
<h1>Namespace for HELD BEEP Binding Profile</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:beep</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section anchor="iana-uri" title="Registration of the "held+beep:" URI Scheme">
<t>This section registers the <spanx style="verb">held+beep:</spanx> URI scheme with the IANA, following the guidelines in <xref target="RFC4395"/>.
<list style="hanging">
<t hangText="URI scheme name:">held+beep</t>
<t hangText="Status:">permanent</t>
<t hangText="URI scheme syntax:">See <xref target="uri-abnf"/> in <xref target="uri"/>.</t>
<t hangText="URI scheme semantics:">A held+beep URI defines a means of accessing a LIS, or it can be used to convey a location URI, see <xref target="uri"/>.</t>
<t hangText="Encoding considerations:">A held+beep URI is not designed to include internationalized text, it is created and consumed by automated processes only. <xref target="RFC3490">Internationalized domain names</xref> can be included in the authority part of the URI, but path components are not intended for user entry.</t>
<t hangText="Applications/protocols that use this URI scheme name:">The held+beep URI is used by Location Information Servers (LIS) as a means of describing a service, or as a location reference.</t>
<t hangText="Interoperability considerations:">No specific considerations.</t>
<t hangText="Security considerations:">No specific considerations.</t>
<t hangText="Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="References:">RFCXXXX (this document), RFCXXXX (HELD)</t>
</list>
</t>
</section>
<section anchor="iana-ap" title="Registration of a LIS Application Protocol Tag for HELD over BEEP">
<t>This section registers a new S-NAPTR Application Protocol tag for the BEEP binding of the <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> protocol, as mandated by <xref target="RFC3958"/>.
<list style="hanging">
<t hangText="Application Service Tag:">HELD+BEEP</t>
<t hangText="Intended Usage:">Identifies the HELD protocol over BEEP</t>
<t hangText="Applicable Service Tag(s):">LIS</t>
<t hangText="Terminal NAPTR Record Type(s):">S</t>
<t hangText="Defining Publication:">RFC&rfc.number;</t>
<t hangText="Related Publications:"><xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref></t>
<t hangText="Contact Information:">The authors of this document</t>
<t hangText="Author/Change Controller:">The IESG</t>
</list>
</t>
</section>
<!-- There actually wasn't a section on registering the S-NAPTR protocol -->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2045;
<!-- &RFC2782; -->
&RFC3080;
&RFC3958;
&RFC4346;
&I-D.ietf-geopriv-http-location-delivery;
<!-- &I-D.thomson-geopriv-lis-discovery; -->
&RFC4234;
&RFC3986;
&RFC2616;
&RFC2119;
</references>
<references title="Informative References">
&RFC3490;
&RFC3688;
&RFC4395;
&I-D.winterbottom-geopriv-lis2lis-req;
&I-D.winterbottom-geopriv-held-lis2lis-bcp;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:33 |