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
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/