idnits 2.17.1 draft-mayrhofer-geo-uri-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (January 02, 2007) is 6324 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 4234 (ref. '3') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4395 (ref. '4') (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mayrhofer 3 Internet-Draft enum.at 4 Expires: July 6, 2007 C. Spanring 5 OIR-ID 6 January 02, 2007 8 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 9 draft-mayrhofer-geo-uri-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 6, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies an Uniform Resource Identifier (URI) for 43 geographic locations using the 'geo' scheme name. A 'geo' URI 44 provides latitude, longitude and optionally altitude of a location in 45 a simple, human-readable form. The 'geo' URI is not tied to a 46 specific application or protocol. 48 Table of Contents 50 1. Changes & Supplemental Information . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Registration of the 'geo' URI Scheme . . . . . . . . . . 4 57 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 4 60 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 4 61 4.4.1. Component Description . . . . . . . . . . . . . . . . 5 62 4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 5 63 4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 5 64 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 5 65 4.6. Applications/protocols That Use This URI Scheme . . . . . 6 66 4.7. Interopability Considerations . . . . . . . . . . . . . . 6 67 4.8. Security Considerations . . . . . . . . . . . . . . . . . 6 68 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 6 70 4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Use of 'geo' URIs . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. URI Construction . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. URI Dereference . . . . . . . . . . . . . . . . . . . . . 8 75 5.3. URI Operations . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Examples and Use Cases . . . . . . . . . . . . . . . . . . . . 9 78 6.1. Plain 'geo' URI . . . . . . . . . . . . . . . . . . . . . 9 79 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.3. Header Field . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.4. Web Mapping Services . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 8.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 11 87 8.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 11 88 8.3. Malicious Locations . . . . . . . . . . . . . . . . . . . 11 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 95 Intellectual Property and Copyright Statements . . . . . . . . . . 13 97 1. Changes & Supplemental Information 99 [Note to editors: This section is to be removed before publication - 100 XML source available on request] 101 o draft-mayrhofer-geo-uri-00 102 * initial draft 104 A supplemental web site for the development of this draft and the 105 'geo' URI in general has been set up at 107 2. Introduction 109 An increasing number of Internet protocols and data formats are being 110 enriched by specifications on how to add information about geographic 111 location to them. In most cases, latitude as well as longitude are 112 added as attributes to existing data structures. However, all those 113 methods are specific to a certain application, data format or 114 protocol, and don't provide a generic way to protocol independent 115 location identification. 117 Over the past few years, emerging location aware applications and 118 location based services were observable on the Internet. Most 119 Internet search engines and a vivid open source mapping community 120 brought an enormous momentum into location aware technology. A wide 121 range of tools and data formerly available to professionals only were 122 provided free of charge for everyday use on the mass market. 124 The 'geo' Uniform Resorce Identifier (URI) [1] scheme is another step 125 into that direction and aims to facilitate, support and standardize 126 part of the interaction with geospatial services and applications. 127 Accessing information about or trigger further services based on a 128 particular place on earth shouldn't be any harder than writing an 129 email by clicking on a 'mailto:' link. 131 A Uniform Resource Identifier (URI) is a compact sequence of 132 characters that identifies an abstract or physical resource. This 133 document specifies the 'geo' URI scheme for identifying geographic 134 locations in the WGS84 [5] reference system, independent of any 135 specific application, data format or protocol. 137 'Geo' URIs identify a geographic location by the textual 138 representation of the location's spatial coordinates in either two or 139 3 dimensions (latitude, longitude, and optionally altitude). An 140 optional query string contains additional parameters. 142 The provision of civic addresses (street, city, country, etc.) to 143 identify locations is out of scope for the 'geo' URI scheme. 145 3. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [2]. 151 4. IANA Registration of the 'geo' URI Scheme 153 This section contains information required for the URI scheme 154 registration, following the guidelines in section 5.4 of RFC 4395 155 [4]. 157 4.1. URI Scheme Name 159 geo 161 4.2. Status 163 permanent 165 4.3. URI Scheme Syntax 167 The syntax of the 'geo' URI scheme is specified below in Augmented 168 Backus-Naur Form (ABNF) [3]: 170 geo-URI = geo-scheme ":" geo-path [ "?" geo-query ] 171 geo-scheme = "geo" 172 geo-path = geo-location 173 geo-query = query 175 geo-location = latitude "," longitude [ "," altitude ] 177 latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] 178 longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] 179 altitude = [ "-" ] *DIGIT [ "." *DIGIT ] 181 The 'query' component is specified in secion 3.4 of RFC 3986. 183 4.4. URI Scheme Semantics 185 Generally, data contained in a 'geo' URI describes the geographic 186 coordinates of the identified location, and contains an optional 187 query string. 189 Note: In order to achieve high user acceptance it seems inevitable to 190 adopt commonly known GPS parameters (latitude, longitude, altitude) 191 where possible. 193 4.4.1. Component Description 195 The "latitude", "longitude", "altitude" and "query" components as 196 specified in the URI scheme syntax ( Section 4.3) are to be used as 197 follows: 199 o The "latitude" component MUST contain the decimal latitude of the 200 identified location in the reference system WGS84. 201 o The "longitude" componont MUST contain the decimal longitude of 202 the identified location in the reference system WGS84. 203 o If present, the OPTIONAL "altitude" component MUST contain the 204 WGS84 decimal altitude of the identified location in meters 205 (elevation above mean seal level). 207 If the altitude of the location is unknown, the "altitude" component 208 MUST NOT be present in the URI. Specifically, unknown altitude MUST 209 NOT be represented by setting the 'altitude' component to "0" (or any 210 other arbitrary value). 212 The number of decimal places indicates the precision of the value. 213 As one degree equals 111319.45m at the equator (40075.004km / 360 214 degrees), five decimal places (0.00001 degree) correspond to roughly 215 one meter, which seem to provide sufficient accuracy for civil use. 217 4.4.2. URI Comparison 219 Two 'geo' URIs MUST be considered equal when their 'longitude', 220 'latitude' and 'altitude' values are mathematically identical, and 221 their decoded 'query' strings match. 223 An URI with undefined (missing) 'altitude' value MUST NOT be 224 considered identical to an URI with an 'altitude' value, even if the 225 remaining components 'latitude', 'longitude' and 'query' match. 227 4.4.3. Interpretation of Undefined Altitude 229 A consumer of an 'geo' URI with undefined 'altitude' MAY assume that 230 the URI refers to the location on earth's surface at the given 231 'latitude' and 'longitude' coordinate. 233 4.5. Encoding Considerations 235 The 'geo-location' path component of the 'geo' URI (see Section 4.3) 236 uses a comma (",") as a delimiter for subcomponents. This delimiter 237 MUST NOT be percent encoded. 239 It is RECOMMENDED that for readability the contents of 'latitude', 240 'longitude' and 'altitude' subcomponents are never percent encoded. 242 Contents of the 'query' component is to be encoded according to RFC 243 3986. 245 4.6. Applications/protocols That Use This URI Scheme 247 The 'geo' URI provides resource identification independent of a 248 specific application or protocol. Examples of potential protocol 249 mappings and use cases can be found in Section 6. 251 4.7. Interopability Considerations 253 While the interpretation of 'latitude', 'longitude' and 'altitude' is 254 quite clear, the interpretation of the 'query' component may vary by 255 application or protocol to which a 'geo' URI is being mapped. 256 Consumers MUST ignore unknown query parameters they encounter while 257 authors of 'geo' URIs SHOULD only use well known parameters in the 258 'query' component. 260 To reduce interopability issues, it might be neccessary to create a 261 registry of query parameters. 263 4.8. Security Considerations 265 See Section 8 of [insert reference to this document] 267 4.9. Contact 269 Christian Spanring (mailto:spanring@oir.at, http://spanring.eu/), 270 Alexander Mayrhofer (mailto:alexander.mayrhofer@enum.at, 271 http://nona.net/) 273 4.10. Author/Change controller 275 The 'geo' URI scheme is registered under the IETF part of the URI 276 tree. As such, change control is up to the IETF. 278 4.11. References 280 The 'geo' URI is specified in [insert reference to this document]. 282 5. Use of 'geo' URIs 284 5.1. URI Construction 286 The production of a 'geo' URI involves the following steps: 288 1. Aquire coordinates of the location to be identified: latitude, 289 longitude, and optionally altitude. 290 2. If coordinates are given in degrees/minutes/seconds, transform 291 them to their respective decimal representation. 292 3. Ensure that coordinates are represented in the correct reference 293 system / units as described in Section 4.4.1. Transform 294 coordinates if neccessary. 295 4. Round coordinate values to a sensible number of decimal places, 296 according to the presumed accuracy of the data source used. 297 5. Remove abundant leading zero's from values, keeping at least one 298 digit in the integer part. Make sure that negative values have a 299 minus sign, while positive values don't have a sign. 300 6. concatenate prepared latitude, longitude, optionally altitude 301 strings with the subcomponent delimiter ",", not adding any 302 whitespace or other characters. 303 7. prepend the result with the string 'geo:' (the URI scheme and 304 delimiter) 305 8. if the final URI is to include a 'query' component, add the 306 component delimiter "?" to the end of the result, followed by the 307 encoded query string. 309 The following example constructs a 'geo' URI from the location 310 message of a Global Positioning System (GPS) receiver: 312 1. Aquire coordinates (data split in two lines): 314 $GPGGA,124951.000,4812.0556,N,01622.1729,E,1, 315 05,3.3,192.4,M,43.4,M,,0000*5D 316 latitude = 48 degrees, 12.0556 minutes north. 317 longitude = 16 degrees, 22.1729 minutes east. 318 altitude = 192.4 meters (using a geoid height of 43.4 meters) 319 Horizontal Dilution of Precision (HDOP) = 3.3 (corresponds to 320 about 10 meters) 322 2. Transform into decimal values: 324 latitude = +48.2009266666 degrees 325 longitude = +16.3695483333 degrees 326 altitude = 192.4 meters 328 3. Reference system: longitude and latitude values are already given 329 in WGS84, altitude already refers to mean sea level (according to 330 the geoid correction value of 43.4 meters) 331 4. Round values: 333 latitude = +48.20093 degrees 334 longitude = +016.36955 degrees 335 altitude = 192 meters 336 (five decimal rougly correlate to about one meter on the equator. 337 This is more precise than the indicated HDOP of about 10 meters). 339 5. Remove abundant stuff: 341 latitude = 48.200927 342 longitude = 16.369548 343 altitude = 192 345 6. Concatenate: 347 48.200927,16.369548,192 349 7. Prepend with URI scheme name and delimiter: 351 geo:48.200927,16.369548,192 353 8. In this example, no query component is to be added. 355 5.2. URI Dereference 357 A consumer of a 'geo' URI has to perform the following operation for 358 dereference: 360 1. Validate the 'geo' URI against the syntax specification 361 (Section 4.3). URIs which do not match the syntax SHOULD NOT be 362 used (see note below). 363 2. Remove the URI scheme and the URI delimiter ("geo:") from the 364 beginning of the string. 365 3. If the string contains a query delimiter ("?"), split off the 366 'query' component and the query delimiter 367 4. Split the remaining string into subcomponents, using the comma 368 (",") as the delimiter 369 5. Use the first subcomponent as latitude, the second one as 370 longitude. If a thrid subcomponent is present, use it as 371 altitude. 373 Note: An application MAY use URIs which contain whitespace in the 374 'geo-location' component by stripping it off before the dereference 375 process. 377 5.3. URI Operations 379 Currently, just one operation on a 'geo' URI is defined - location 380 retrieval: In that operation, a client uses the data from the URI to 381 retrieve the geographical location to which the URI refers to. 383 A client may then, though, use this location information for various 384 purposes: 386 A web browser may rewrite that information into the URI of a web 387 mapping service of the user's choice, and display a map of the 388 location 389 A navigational device such as a Global Positioning System (GPS) 390 receiver may offer the user to start navigation to the location. 391 Examples of such uses can be found in Section 6. 393 6. Examples and Use Cases 395 6.1. Plain 'geo' URI 397 The following 3-dimensional 'geo' URI example references to the 398 bottom of the stairs leading to the Karlskirche in Vienna, Austria: 400 402 A user could type the data extracted from this URI into a electronic 403 navigation device, or even use it to locate the identified location 404 on a paper map. 406 6.2. Hyperlink 408 'geo' URIs could (like any other URI scheme) also be embedded as 409 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 410 with such a hyperlink could look like: 412

one of Vienna's most popular sights is the Karlskirche 415 6.3. Header Field 417 Many protocols support the use of arbitrary URI schemes, for example 418 in their header Fields. A Session Initiation Protocol (SIP) [7] 419 REGISTER request could contain a 'Contact' header with a 'geo' URI, 420 to reflect the geographic location to be used to contact the 421 registering entity physically: 423 REGISTER sip:geoaware.example.com SIP/2.0 424 Via: SIP/2.0/UDP mypc.example.org:5060;branch=z9hG4bKnashds7 425 Max-Forwards: 70 426 To: Joe Geo 427 From: Joe Geo ;tag=456248 428 Call-ID: aaafafff-84230@7afagggdd 429 CSeq: 42 REGISTER 430 Contact: 431 Contact: 433 6.4. Web Mapping Services 435 A rather common method for accessing geographic information on the 436 Internet are web mapping services (WMS) [6]. An image containing a 437 map is delivered by a mapserver as response to a WMS request. WMS 438 requests usually contain a bounding box (enclosing rectangle), the 439 spatial reference system (e.g. 'EPSG:4326' for WGS84), displayed 440 layers (e.g. roads, borders), image dimensions and image format (e.g. 441 'image/png'): 443 http://map.example.org/maps/wms.cgi?BBOX=16,48,18,50&SRS=EPSG:4326 \ 444 &LAYERS=roads,borders&WIDTH=400&HEIGHT=400&FORMAT=image/png 446 A location identified by a 'geo' URI could be used to support input 447 parameters in terms of a center point of a WMS request. Query 448 parameters could be used to reflect the requested type of service, 449 eg. a 'geo' URI could be mapped to a WMS request as follows: 451 geo:48.20833,16.37278,171?service=wms&scale=5000&layers=roads,borders 452 \ &height=400&width=400&format=image/png 454 A bounding box can be calculated by given scale, height and width. 455 In our case, based on an output scale of 1:5000 and 400px image 456 height and width the bounding box width and height is 0.00634 457 degrees. A 'geo' URI is limited to one spatial reference system, 458 thus 'SRS=EPSG:4326' is a constant parameter in WMS transformations. 459 The resulting WMS request could look like: 461 http://map.example.org/maps/wms.cgi?BBOX=16.05690,47.89167, \ 462 16.69142,48.52619&SRS= EPSG:4326&LAYERS=roads,borders&WIDTH=400 \ 463 &HEIGHT=400&FORMAT=image/png 465 7. IANA Considerations 467 This document requests assignment of the 'geo' URI scheme in the IETF 468 part of the URI scheme tree, according to the guidelines in BCP 115 469 (RFC 4395) [4]. The definitions required for the assignment are 470 contained in Section 4. 472 8. Security Considerations 474 Because the 'geo' URI is not tied to any specific protocol, and 475 identifies a physical location rather than a network resource, most 476 of the general security considerations on URIs (Section 7 of RFC 477 3986) do not apply. However, the following (additional) issues 478 apply: 480 8.1. Invalid Locations 482 The URI syntax (Section 4.3) makes it possible to construct valid 483 'geo' URIs which don't identify a valid location on earth. 484 Applications MUST NOT use URIs which such invalid values, and SHOULD 485 warn the user when such URIs are encountered. 487 An example of such an invalid URI would be (latitude 488 "beyond" north pole). 490 8.2. Location Privacy 492 Location information about individuals is an extremely sensitive 493 topic, especially when location is combined with Personally 494 Identifyable Information (PII). 496 In cases where location information about individuals is used in a 497 publicly available 'geo' URI, the explicit consent of the individual 498 is REQUIRED. 500 8.3. Malicious Locations 502 As with other URI schemes, the information provisioned in 'geo' URIs 503 cannot be trusted unless some kind of trust relation with the author 504 of a URI is in place. Applications of the 'geo' URI SHOULD consider 505 methods of validating and protecting URIs. 507 9. References 509 9.1. Normative References 511 [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 512 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 513 January 2005. 515 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 516 Levels", BCP 14, RFC 2119, March 1997. 518 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 519 Specifications: ABNF", RFC 4234, October 2005. 521 9.2. Informative References 523 [4] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 524 Registration Procedures for New URI Schemes", BCP 115, RFC 4395, 525 February 2006. 527 [5] National Imagery and Mapping Agency, "Department of Defense 528 World Geodetic System 1984, Third Edition", NIMA TR8350.2, 529 January 2000. 531 [6] Open GIS Consortium Inc., "Web Map Service Implementations 532 Specification, Version 1.1.1", OGC 01-068r3, January 2002. 534 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 535 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 536 Session Initiation Protocol", RFC 3261, June 2002. 538 Authors' Addresses 540 Alexander Mayrhofer 541 enum.at GmbH 542 Karlsplatz 1/9 543 Wien A-1010 544 Austria 546 Phone: +43 1 5056416 34 547 Email: alexander.mayrhofer@enum.at 548 URI: http://www.enum.at/ 550 Christian Spanring 551 OIR-Informationsdienste GmbH 552 Franz-Josefs-Kai 27 553 Wien A-1010 555 Phone: +43 1 5338747 36 556 Email: spanring@oir.at 557 URI: http://www.oir.at/ 559 Full Copyright Statement 561 Copyright (C) The IETF Trust (2007). 563 This document is subject to the rights, licenses and restrictions 564 contained in BCP 78, and except as set forth therein, the authors 565 retain all their rights. 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 570 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 571 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 572 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Intellectual Property 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org. 599 Acknowledgment 601 Funding for the RFC Editor function is provided by the IETF 602 Administrative Support Activity (IASA).