idnits 2.17.1 draft-thomson-geopriv-held-beep-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2009) is 5400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Experimental RFC: RFC 5573 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-15 == Outdated reference: A later version (-15) exists of draft-ietf-geopriv-lis-discovery-11 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-deref-protocol-03 == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-07 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: January 8, 2010 July 7, 2009 7 A BEEP Binding for the HELD Protocol 8 draft-thomson-geopriv-held-beep-05 10 Status of This Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 8, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 A BEEP binding is described for HELD. This binding is more suitable 47 than the basic HTTP binding in scenarios where multiple messages are 48 sent between the same two parties. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The HELD BEEP Profile . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Channel Initialization . . . . . . . . . . . . . . . . . . 4 56 2.2. Message Exchange Pattern . . . . . . . . . . . . . . . . . 4 57 2.3. Error Handling . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. Asynchronous Message Exchange . . . . . . . . . . . . . . . 5 59 3. Location Dereference and the BEEP Binding . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 4.1. LIS Discovery and Authentication . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. BEEP Profile Registration . . . . . . . . . . . . . . . . . 7 64 5.2. URN sun-namespace registration for 65 'urn:ietf:params:xml:ns:geopriv:held:beep' . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 The HTTP binding for HELD [I-D.ietf-geopriv-http-location-delivery] 74 provides a basis for the protocol, which does not encumber 75 implementations with a complex protocol stack. However, some 76 applications require that a requester make multiple requests in 77 parallel to a Location Information Server (LIS). Where a requester 78 is able to retrieve location information for large numbers of 79 Targets, a more efficient protocol is useful. In these 80 circumstances, relying on HTTP is suboptimal. 82 The HTTP binding is not suitable in volume scenarios because HTTP 83 suffers from head-of-queue blocking. This prevents multiple requests 84 from being processed in parallel. In order to achieve higher 85 throughput, the requester must establish multiple TCP connections in 86 parallel. This causes HTTP to be unsuitable for applications where 87 multiple parallel requests are expected by increasing the overheads. 89 BEEP [RFC3080] provides a framing scheme that allows for parallel 90 requests. BEEP uses MIME [RFC2045] for its messages, which means 91 that no significant modifications are required to carry HELD 92 messages. This document describes a BEEP profile for HELD. 94 1.1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 This document covers the use of HELD as a location configuration 101 protocol and a location dereference protocol (see 102 [I-D.ietf-geopriv-lbyr-requirements]). For simplicity, the term 103 Location Information Server (LIS) is used to refer to the server role 104 for both protocols. LIS in place of Location Server (LS), which is 105 the more correct term for the location dereference protocol. 107 2. The HELD BEEP Profile 109 The BEEP profile for HELD is identified using the URN: 111 urn:ietf:params:xml:ns:geopriv:held:beep 113 This identifier is used in the BEEP "profile" element during channel 114 creation. 116 The HELD channel is a simple continuous channel that does not require 117 any state information. Requests and their respective responses are 118 always in the request-response form ("MSG"/"RPY"). 120 2.1. Channel Initialization 122 The HELD profile is started with a single "profile" request. No 123 additional parameters are required. When initiating a channel the 124 "profile" element is empty, as shown in the example below. 126 127 128 130 Similarly, the response to channel initialization is empty. 132 134 2.2. Message Exchange Pattern 136 The BEEP binding for HELD requires only the "MSG"/"RPY" message 137 exchange. Each "MSG" frame contains a HELD request; for example a 138 "locationRequest". Each "RPY" frame includes a response; for 139 example, a "locationResponse". 141 The following exchange demonstrates how a simple HELD location 142 request and response are encapsulated. The "C:" and "S:" prefixes on 143 lines are used following the convention in [RFC3080]. 145 C: MSG 1 7 . 544 125 146 C: Content-Type: application/held+xml 147 C: 148 C: 149 C: 150 C: END 151 S: RPY 1 7 . 1902 695 152 S: Content-Type: application/held+xml 153 S: 154 S: 155 S: 156 S: 157 S: 158 S: END 160 2.3. Error Handling 162 Consistent with the HTTP binding, the BEEP binding for HELD does not 163 use the "ERR" message to indicate errors at the HELD protocol level. 164 Errors in handling HELD Requests are indicated to the requester in a 165 "RPY" message. 167 Errors in the BEEP message that are unrelated to the HELD protocol, 168 such as MIME formatting problems, are indicated using the BEEP "ERR" 169 message. This "ERR" message MAY either be empty or it could include 170 textual feedback. 172 2.4. Asynchronous Message Exchange 174 A HELD request can take varying amounts of time to process. The 175 "responseTime" attribute in HELD is used to indicate an upper bound 176 on this time. BEEP channels are serial in nature and BEEP mandates 177 that the serving peer process requests in order. With these 178 constraints, in order to achieve any substantial throughput, multiple 179 BEEP channels would be necessary. This approach does not scale well 180 for larger numbers of requests as response times increase. 182 It is RECOMMENDED that for HELD on BEEP that both peers use 183 asynchronous BEEP channels [RFC5573]. Asynchronous BEEP enables the 184 use of a single channel for multiple requests without constraints on 185 how requests are processed or on the order of responses. 186 Asynchronous BEEP greatly increases the potential throughput of a 187 channel, particularly for profiles like HELD that could have widely 188 varying response times. Without asynchronous BEEP, multiple channels 189 MAY be used to increase throughput. 191 3. Location Dereference and the BEEP Binding 193 The HELD BEEP binding can be used for dereferencing of location URIs 194 ([I-D.ietf-geopriv-lbyr-requirements], 195 [I-D.winterbottom-geopriv-deref-protocol]). A location URI is 196 indicated in a "Request-URI" MIME header of the BEEP "MSG" frame. 198 The "Request-URI" header includes an absolute path and optional query 199 components. The folloring using ABNF [RFC5234] shows the format of 200 the "Request-URI" header: 202 Request-URI-Header = "Request-URI" ":" ( absolute-URI / "*" ) 203 ; absolute-URI from RFC 3986 205 The "Request-URI" header includes an absolute URI [RFC3986]. The 206 absolute URI indicates location URI that is being dereferenced, or 207 the string "*". A value of "*" indicates that the request is a 208 location configuration protocol request (i.e. no location URI is 209 being dereferenced). The header MAY be omitted for a location 210 configuration protocol request, and a value of "*" is inferred. 212 4. Security Considerations 214 TLS [RFC5246] MUST be used for HELD over BEEP unless confidentiality, 215 message integrity and authentication are assured through other means 216 (e.g. dedicated media). Section 4.1 includes guidelines on 217 authentication requirements. 219 4.1. LIS Discovery and Authentication 221 This profile is most suited to situations where a client and LIS 222 exchange a large number of requests over a prolonged period. It is 223 anticipated that the client and LIS are known to each other. 225 Based on this assumption, it is reasonable for the LIS and its 226 clients to have pre-existing configuration that is used instead of a 227 discovery process. In addition, authentication details and methods 228 can be pre-configured on both nodes. Therefore, no protocol 229 mechanisms are specified for arranging discovery and authentication 230 for this profile. 232 Regardless of the method used to determine the address of the LIS, a 233 client MUST authenticate the LIS. This prevents any LIS spoofing 234 attacks that could be used to provide falsified information or to 235 acquire information about the client (and in turn, their clients). 236 Authentication for the case where HELD is used as a location 237 configuration protocol is covered in 238 [I-D.ietf-geopriv-lis-discovery]. 240 If this profile is used for dereferencing location URIs, the 241 authenticated LIS identity MUST be used to determine whether the LIS 242 is authorized to serve particular location URIs. The client 243 authenticates the LIS for each location URI. Depending on the URI 244 scheme, the LIS identity is validated against the URI. If a LIS 245 cannot be identified as authoritative for a particular URI, clients 246 MUST NOT request information from that LIS for that URI. 248 For location URIs that include a host name, such as "https:" or 249 "pres:" URIs, the guidelines in Section 3.1 of [RFC2818] can be 250 applied to determine if LIS identity matches the URI. 252 It might also be necessary for the LIS to authenticate clients. Some 253 authorization decision is likely to be necessary in order for a 254 client to initiate a large volume of requests, which could represent 255 significant load on a LIS. 257 This document does not mandate any specific authentication method; 258 however, since TLS is required, the mandatory authentication methods 259 for TLS are assumed to be present. Alternative authentication 260 methods can be negotiated between the LIS and its clients. 262 5. IANA Considerations 264 5.1. BEEP Profile Registration 266 This section outlines the HELD BEEP binding in the form described in 267 [RFC3080]. 269 Profile Identification: urn:ietf:params:xml:ns:geopriv:held:beep 271 Messages exchanged during Channel Creation: none 273 Messages starting one-to-one exchanges: HELD request messages from 274 [I-D.ietf-geopriv-http-location-delivery] and extension documents. 276 Messages in positive replies: HELD request messages from 277 [I-D.ietf-geopriv-http-location-delivery] and extension documents. 279 Messages in negative replies: The HELD "error" message 281 Messages in one-to-many exchanges: none 283 Message Syntax: c.f., HELD [I-D.ietf-geopriv-http-location-delivery] 285 Message Semantics: c.f., HELD 286 [I-D.ietf-geopriv-http-location-delivery] 288 Contact Information: c.f., the "Author's Address" section of this 289 document 291 5.2. URN sun-namespace registration for 292 'urn:ietf:params:xml:ns:geopriv:held:beep' 294 This section registers a new XML namespace, 295 "urn:ietf:params:xml:ns:geopriv:held:beep", as per the guidelines in 296 [RFC3688]. 298 URI: urn:ietf:params:xml:ns:geopriv:held:beep 300 Registrant Contact: IETF, GEOPRIV working group, 301 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 303 XML: 305 BEGIN 306 307 309 310 311 HELD BEEP Binding 312 313 314

Namespace for HELD BEEP Binding Profile

315

urn:ietf:params:xml:ns:geopriv:held:beep

316 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 317 with the RFC number for this specification.]] 318

See RFCXXXX.

319 320 321 END 323 6. Acknowledgements 325 Thanks to Francis Brosnan Blazquez for sharing his BEEP expertise in 326 reviewing this document. 328 7. References 330 7.1. Normative References 332 [RFC2045] Freed, N. and N. 333 Borenstein, "Multipurpose 334 Internet Mail Extensions 335 (MIME) Part One: Format of 336 Internet Message Bodies", 337 RFC 2045, November 1996. 339 [RFC2818] Rescorla, E., "HTTP Over 340 TLS", RFC 2818, May 2000. 342 [RFC3080] Rose, M., "The Blocks 343 Extensible Exchange 344 Protocol Core", RFC 3080, 345 March 2001. 347 [RFC3986] Berners-Lee, T., Fielding, 348 R., and L. Masinter, 349 "Uniform Resource 350 Identifier (URI): Generic 351 Syntax", STD 66, RFC 3986, 352 January 2005. 354 [RFC5234] Crocker, D. and P. 355 Overell, "Augmented BNF 356 for Syntax Specifications: 357 ABNF", STD 68, RFC 5234, 358 January 2008. 360 [RFC5246] Dierks, T. and E. 361 Rescorla, "The Transport 362 Layer Security (TLS) 363 Protocol Version 1.2", 364 RFC 5246, August 2008. 366 [RFC5573] Thomson, M., "Asynchronous 367 Channels for the Blocks 368 Extensible Exchange 369 Protocol (BEEP)", 370 RFC 5573, June 2009. 372 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 373 J., Thomson, M., and B. 374 Stark, "HTTP Enabled 375 Location Delivery (HELD)", 376 draft-ietf-geopriv-http- 377 location-delivery-15 (work 378 in progress), June 2009. 380 [I-D.ietf-geopriv-lis-discovery] Thomson, M. and J. 381 Winterbottom, "Discovering 382 the Local Location 383 Information Server (LIS)", 384 draft-ietf-geopriv-lis- 385 discovery-11 (work in 386 progress), May 2009. 388 [RFC2119] Bradner, S., "Key words 389 for use in RFCs to 390 Indicate Requirement 391 Levels", BCP 14, RFC 2119, 392 March 1997. 394 7.2. Informative References 396 [RFC3688] Mealling, M., "The IETF 397 XML Registry", BCP 81, 398 RFC 3688, January 2004. 400 [I-D.winterbottom-geopriv-deref-protocol] Winterbottom, J., 401 Tschofenig, H., 402 Schulzrinne, H., Thomson, 403 M., and M. Dawson, "An 404 HTTPS Location 405 Dereferencing Protocol 406 Using HELD", draft- 407 winterbottom-geopriv- 408 deref-protocol-03 (work in 409 progress), February 2009. 411 [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., 412 "Requirements for a 413 Location-by-Reference 414 Mechanism", draft-ietf- 415 geopriv-lbyr-requirements- 416 07 (work in progress), 417 February 2009. 419 Authors' Addresses 421 Martin Thomson 422 Andrew 423 PO Box U40 424 Wollongong University Campus, NSW 2500 425 AU 427 Phone: +61 2 4221 2915 428 EMail: martin.thomson@andrew.com 429 URI: http://www.andrew.com/ 431 James Winterbottom 432 Andrew 433 PO Box U40 434 Wollongong University Campus, NSW 2500 435 AU 437 Phone: +61 2 4221 2938 438 EMail: james.winterbottom@andrew.com 439 URI: http://www.andrew.com/