idnits 2.17.1 draft-daviel-http-geo-header-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 554. 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 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 (December 7, 2007) is 5986 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 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. 'WGS-84' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' -- Obsolete informational reference (is this intentional?): RFC 2731 (Obsoleted by RFC 5791) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Vancouver Webpages 3 December 7, 2007 4 Expires: Jun 7, 2008 5 Intended status: Standards Track 7 Geographic extensions for HTTP transactions 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 1, 2008. 34 Abstract 36 This memo describes a method of adding simple geographic position or 37 region information to HTTP transactions using extension headers. It 38 allows location-based services on the World Wide Web, without the 39 additional overhead of geographic query requests and possibly 40 graphical input. Extension headers transmit predefined or detected 41 position information to reflect a location that the requesting agent 42 is interested in. This information may be used by a server to 43 present appropriate position-dependent responses, such as search 44 engine results or weather maps. 46 1. Introduction 47 Dec. 2007 (Expires Jun 2008) 49 Many resources on the World-Wide-Web are associated with a particular 50 place on the Earth's surface. HTML documents may contain geo tags as 51 described in [RFC2731],[1] but more information with geographic data 52 is stored in databases (e.g. "yellow pages"). Resource discovery on 53 the Web has thus far focused on document title and open-text keyword 54 searching, in the case of yellow pages postcodes or map selection are 55 also used. However, resource discovery based on geographic criteria 56 is not widespread because it calls for extensive user-input in terms 57 of graphical selection. Mobile devices especially will make use of 58 geographic search but can only with difficulty specify the required 59 location data (e.g. due to small displays or limited keypads). On 60 the other hand, mobile devices often integrate a GPS receiver or can 61 make benefit of network based positioning. It may be beneficial to 62 facilitate automatic, but user- driven use of geographic information 63 on the Web. A specification for standardized transmission of 64 position data will allow advanced search modes, more user-friendly 65 web pages (e.g. bus schedules in conjunction with nearest stations) 66 and new location based services which are currently not available on 67 the World-Wide-Web (e.g. local advertising at small scale). By 68 including geographic extension headers in HTTP requests, it is 69 possible to tailor responses to the location of the requestor, in the 70 same way that the language of the response may be tailored by using 71 the Accept-Language header [RFC2616]. 73 2. Example Usage 75 An example of a commonly used resource on the World-Wide-Web is a 76 weather map, used by a traveling person. Such a service usually 77 covers different regions. On a map, the traveler could select the 78 current position and even store it using cookie methodology 79 [RFC2965]. However, when moving to another region the cookie will 80 represent invalid location information. 82 Beside using cookies, this service is also able to process specific 83 position information. It announces this capability by sending the 84 following header: "Vary: Geo-Position". A browser can use this 85 header if it is connected to a positioning source such as GPS or has 86 preconfigured data (see region codes, section 3.3). Once the user 87 decides to send position information in this specific case or in 88 general, each request to this service includes another header 89 representing the current position, e.g. "Geo-Position: 90 48.541;-123.843". In this case, the server may tailor the weather 91 map to Vancouver Island without further input. 93 Other services may include positioning metadata such as accuracy and 94 other parameters for identifying a nearby or distant object. 96 Dec. 2007 (Expires Jun 2008) 98 3. Implementation 100 3.1 Geographic Position 102 A request MAY include a geographic position using an HTTP extension 103 header. The identifier "Geo-Position" is used for this purpose. 104 Latitude, longitude and altitude are separated by a semicolon. Other 105 values are given as key-value-pairs (e.g. hdn=130), separated by a 106 whitespace. Latitude and longitude are mandatory and MUST be 107 included in each geo-position request. Optional key-value-pairs: 109 epu - estimated position uncertainty 110 hdn - heading clockwise from true north 111 spd - speed 113 Latitude (degrees north of the equator) and longitude (degrees east 114 of the prime meridian on the [WGS-84] spheroid) values shall be 115 expressed as decimal fractions of degrees. Whole degrees of latitude 116 shall be represented by a decimal number ranging from 0 through 90. 117 Whole degrees of longitude shall be represented by a decimal number 118 ranging from 0 through 180. When a decimal fraction of a degree is 119 specified, it MUST be separated from the whole number of degrees by a 120 decimal point (the period character, "."). The number of decimal 121 places given should reflect the precision of the position 122 determination method or be reduced in order to reflect privacy issues 123 (see section 5) 125 Latitudes north of the equator MAY be specified by a plus sign (+), 126 or by the absence of a minus sign (-), preceding the designating 127 degrees. Latitudes south of the equator MUST be designated by a 128 minus sign (-) preceding the digits designating degrees. Latitudes 129 on the equator MUST be designated by a latitude value of 0. 131 Longitudes east of the prime meridian MAY be specified by a plus sign 132 (+), or by the absence of a minus sign (-), preceding the designating 133 degrees. Longitudes west of the prime meridian MUST be designated by 134 a minus sign (-) preceding the digits designating degrees. 135 Longitudes on the prime meridian MUST be designated by a longitude 136 value of 0. A point on the 180th meridian shall be taken as 180 137 degrees West, and shall include a minus sign. 139 Any spatial address with a latitude of +90 (90) or -90 degrees will 140 specify a position at the true north or true south poles, 141 respectively. The component for longitude may have any legal value. 143 Altitude is expressed as a signed decimal number of metres above 144 datum, which is [WGS-84]. Decimal places (if required) MUST be 146 Dec. 2007 (Expires Jun 2008) 148 separated by a decimal point ("."). Points having zero or positive 149 elevation MAY omit the plus sign. 151 The estimated position uncertainty states the quality of the 152 submitted position (latitude, longitude, altitude). It is expressed 153 in metres, and describes a circle or sphere of 95% positioning 154 probability. 156 Heading is expressed in decimal degrees clockwise from true north. 158 Speed is given in metres per second. 160 If a parameter is intended to be transmitted but the value cannot be 161 ascertained due to technical reasons, it shall be given as "N/A" 162 (without quotes). 164 3.1.1 Examples 166 (Host headers [RFC2616] are for exemplification only) 168 Host: maps.example.com 169 Geo-Position: -10;+60 171 requests for a map at position 10 degrees south, 60 degrees east. It 172 must be assumed that a more precise position is not available. 174 Host: weather.example.com 175 Geo-Position: -10.28;60.84;120 epu=50 177 requests for a weather forecast for instance at position 10.28000 178 degrees south, 60.84000 degrees east, 120 metres above datum 179 ([WGS-84]) with a 95%-confidence boundary of 50 metres (radius). 181 Host: tourism.example.com 182 Geo-Position: -10.28;60.84 epu=50 hdn=45 184 requests for information about an object in north-east direction from 185 the given position (e.g. the city hall on a place). 187 Host: traffic.example.com 188 Geo-Position: -10.28;60.84 epu=50 hdn=45 spd=15 190 requests for traffic congestion reports for the area at the given 191 position but traffic in north-east direction only. The service may 192 assume an average speed for further area selections. 194 3.2 Negotiation 196 Dec. 2007 (Expires Jun 2008) 198 Use of negotiation is RECOMMENDED. 200 A geo-enabled server implicitly uses server-driven negotiation as 201 described in [RFC2616]. For proper operation of HTTP caches, a Vary 202 header SHOULD be send by the server to indicate that it will serve 203 different content for requests with different values of the specified 204 headers, and that a cache should not re-use a cached response unless 205 a new request has matching headers. 207 A geo-enabled server SHOULD send appropriate Vary headers to indicate 208 which client Geo headers will cause a tailored response to be 209 generated. 211 A Vary header MAY be used as a means for a server to announce to a 212 client that it will accept geo headers, triggering a filter dialogue 213 (section 3.4). 215 3.2.1 Examples 217 Vary: Geo-Position 219 indicates that a server will serve different content in response to 220 different values of Geo-Position header sent by the client. 222 Vary: Geo-Country, Geo-A1 224 indicates that a server will serve different content in response to 225 to different values of either Geo-Country or Geo-A1 (national 226 subdivision) headers. 228 3.3 Region Codes 230 Instead of position (or even additionally), a client may name an 231 administrative area it is interested in. The identifier "Geo- 232 Country" is used to specify a country code from [ISO3166-1]. The 233 identifiers "Geo-A1", "Geo-LMK" etc. are used to specify a civic 234 address or region [PIDF-LO] 236 They are used as extension headers. As an example, 238 Geo-Country: CA 239 Geo-A1: ON 241 requests a resource tailored to Ontario, Canada. 243 3.4 User Filters 245 While a geo position header in an HTTP request directs the server to 247 Dec. 2007 (Expires Jun 2008) 249 return information pertaining to a particular position, the server 250 may infer that the position requested is the current location of the 251 client. In order to protect the privacy of users against inadvertent 252 leakage of their personal location information, a user must be able 253 to control what information is sent to servers. 255 A Web browser, client or geo-enabling proxy MUST implement a 256 mechanism for filtering geographic information sent to servers 257 ([RFC3693]). It may maintain a list of trusted sites to which 258 position data may be sent, or it may maintain a list of regular 259 expressions which is applied to requested URLs. Position data sent 260 to remote servers must be filtered using rules based on this list. 261 The user MUST be provided with tools to maintain this list. 263 Such a list might contain fields for "address of web site", 264 "allow/block", "precision", "auth" and "secure". The browser will 265 send the current position in request headers providing that the site 266 address is listed and allowed. Position information would be sent to 267 the defined precision. If the "secure" field is present, then the 268 browser will only send position information using an encrypted 269 protocol ([3],[RFC4346]). If the "auth" field is present, then the 270 browser will only send position information during an authenticated 271 HTTP session (one in which an Authorization header is sent) 272 ([RFC2617]). 274 If the client receives an HTTP response containing a Vary header 275 which specifies a Geo header, and if the site is not in the filter 276 list, the browser should open a dialogue with the user to ask them 277 whether position data should be sent. The agent may ask, for 278 instance, whether position data should be sent once, always, or never 279 and will save this information appropriately. It may also ask for 280 optional data to be sent. 282 Fuzzing of position information (decreasing its precision) may 283 typically be done by rounding or reducing the number of decimal 284 places in latitude and longitude. In order to avoid a "line 285 crossing" effect, where the exact position of a moving client may be 286 deduced as, for example, 43.13000 at the instant its declared 287 coordinate changes from 43.12 to 43.13, it is recommended that a 288 random offset be added before truncation. 290 The filter may support a default setting for unlisted sites, for 291 instance to use a 10km precision for secure sites and to block 292 insecure sites. The installation value of such a default setting 293 must be chosen to minimize privacy impact. It should not send more 294 precise positions than may typically derived from the client Internet 295 address, such as a metropolitan area or university campus. 297 Dec. 2007 (Expires Jun 2008) 299 3.4.1 Disposition of Location Information 301 Location information MUST NOT be forwarded to another entity by the 302 server to which it was sent (the entity that has satisfied the user's 303 privacy filter). For instance, if alpha.example.com is trusted but 304 redirects an HTTP request to beta.example.com, a Geo-Position header 305 must not be sent to beta.example.com unless that site is also 306 trusted. 308 3.5 Proxy 310 Geo headers may be generated directly in a client, such as a geo- 311 enabled Web browser, or may be added by a geo-enabled HTTP proxy 312 agent, allowing a standard browser to be used. The proxy agent may 313 be included on the same platform as the client, as might be the case 314 where location data is available from an integral GPS receiver. 315 Alternatively, the proxy agent may be external, as might be the case 316 where location data is determined by wireless triangulation from a 317 number of fixed base stations. If location data is added by an 318 external proxy agent, the user MUST be able to filter such data. 320 Geo extension headers are end-to-end header fields and should be 321 transmitted to the ultimate destination of the declaration (the 322 server). They should be forwarded and ignored by non-geo-enabled 323 proxy agents. 325 4. Formal Syntax 327 The syntax uses augmented BNF, described in [RFC2616]. 329 DIGIT = %x30-39 ; 0-9 330 UCASE = %x41-5A ; A-Z 331 PLUS = %x2B ; + 332 MINUS = %x2D ; - 333 DECIMAL = %x2E ; . 334 CRLF = %x0D.%x0A ; return, linefeed 335 SIGN = MINUS / PLUS 337 country = 2UCASE ; [ISO3166-1] 338 latitude = [ SIGN ] 1*2DIGIT [ DECIMAL 1*DIGIT ] ; -90 - 90 339 longitude = [ SIGN ] 1*3DIGIT [ DECIMAL 1*DIGIT ] ; -180 - 180 340 altitude = [ SIGN ] 1*DIGIT [ DECIMAL 1*DIGIT ] ; metres 341 uncertainty = 1*DIGIT [ DECIMAL 1*DIGIT ] ; metres 342 heading = 1*3DIGIT [ DECIMAL 1*DIGIT ] ; 0-360 343 speed = 1*DIGIT [ DECIMAL 1*DIGIT ] ; metre/sec. 345 Dec. 2007 (Expires Jun 2008) 347 lat = latitude 348 lon = longitude 349 alt = altitude 350 epu = "epu" "=" uncertainty *LWS 351 hdn = "hdn" "=" heading *LWS 352 spd = "spd" "=" speed *LWS 354 Vary = "Vary" ":" ( "*" | 1#field-name ) 355 region-header = "Geo-Country:" country-code CRLF 356 position-header = "Geo-Position:" LWS 357 lat;lon[;alt] *( epu | hdn | spd ) CRLF 359 response-header = accept-header 360 request-header = [ region-header ] [ position-header ] 362 4.1 Terminology 364 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 365 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 366 document are to be interpreted as described in [RFC2119]. 368 5. Security Considerations 370 This draft raises certain issues of privacy. The position 371 information sent in a request is a qualification of the HTTP request, 372 and does not necessarily represent the actual position of the 373 requesting agent. However, if geo extensions are added to an HTTP 374 request, the server may infer the location of the person making the 375 request. If a Geo-Position extension is given to a high degree of 376 accuracy for a request made from a fixed location such as a private 377 residence, the server may be able to uniquely identify the street 378 address. If no controls are implemented, it would be possible to 379 identify a person's location and perhaps identity from their general 380 Web browsing activity. 382 In cases where a portion of the data path from client to server 383 includes an unencrypted link, it may be possible for data including 384 position information to be intercepted by a third party. This third 385 party may be able to determine the location of the mobile device, and 386 may be able to associate the mobile device with a particular person 387 visually based on location data. This association may exacerbate the 388 loss of privacy inherent in using an unencrypted wireless data path. 390 5.1 Encryption 392 It is suggested that, where possible, HTTP requests including geo 394 Dec. 2007 (Expires Jun 2008) 396 headers be encrypted using an encryption scheme such as SSL or TLS 397 [3],[RFC4346]. This mechanism provides a degree of trust in the 398 identity of the server, and guards against disclosure of possibly 399 sensitive position information by proxy agents, firewalls or 400 recording devices. 402 Another mechanism which may be used to protect the privacy of the 403 user is to use a trusted proxy agent such as Squid [4]. Use of a 404 proxy which does not forward the client address will prevent an 405 untrusted server from tracking the position of a particular client by 406 address, though tracking by cookies [RFC2965] may be possible if 407 these are enabled, or by "web bugs" [5]. 409 6. IANA considerations 411 The message header fields below should be added to the permanent 412 registry (see [RFC3864]). 414 6.1. Geo-Position 416 Header field name: Geo-Position Applicable protocol: http Status: 417 standard Author/Change controller: IETF Specification document: this 418 specification (Section 3.2) 420 6.2. Geo-Country 422 Header field name: Geo-Country Applicable protocol: http Status: 423 standard Author/Change controller: IETF Specification document: this 424 specification (Section 3.3) 426 7. Internationalization considerations 428 Geo-Position, Geo-Velocity and Geo-Country values are defined using 429 US-ASCII. 431 8. References 432 8.1 Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC2616] Fielding, Gettys, Mogul, Frystyk, Masinter, 438 Leach, Berners-Lee, "Hypertext Transfer Protocol 439 HTTP/1.1", RFC 2616, June 1999. 441 [RFC3864] Klyne, Nottingham, Mogul, "Registration 442 Procedures for Message Header Fields", BCP 90, 443 RFC 3864, September 2004. 445 Dec. 2007 (Expires Jun 2008) 447 [WGS-84] United States Department of Defense; DoD WGS-1984 - Its 448 Definition and Relationships with Local Geodetic Systems; 449 Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 450 7-R-138-R; CV, KV; 452 [ISO3166-1] International Organization For Standardiza- 453 tion, "Codes for the representation of names 454 of countries and their subdivisions - Part 1: 455 Country codes", Standard ISO 3166-1:2006, 456 November 2006. 458 10.2 Informative References 460 [1] Daviel, Kaegi, "Geographic registration of HTML 461 documents", Internet Draft draft-daviel-html-geo-tag-08, 462 Sept. 2007 464 [3] Frier, Karlton, Kocher, "The SSL 3.0 Protocol", 465 November 1996. 467 [4] Wessels, Claffy, "ICP and the Squid web cache", IEEE 468 Journal on Selected Areas in Communication, 469 April 1998. 471 [5] Smith, "The Web Bug FAQ", November 1999. 473 [RFC2731] Kunze, "Encoding Dublin Core Metadata in HTML", 474 RFC 2731, December 1999. 476 [RFC2965] Kristol, Montulli, "HTTP State Management 477 Mechanism", RFC 2965, October 2000. 479 [RFC4346] Dierks, Rescorla, "The Transport Layer Security 480 (TLS) Protocol", RFC 4346, April 2006. 482 [RFC2617] Franks, Hallam-Baker et al., "HTTP Authentication: Basic 483 and Digest Access Authentication", RFC 2617. June 1999 485 [RFC3693] Cuellar, Morris et al., "Geopriv Requirements", RFC 3693, 486 February 2004 488 [PIDF-LO] M. Thomson, J. Winterbottom, 489 Revised Civic Location Format for PIDF-LO, 490 draft-ietf-geopriv-revised-civic-lo-07, December 2007 492 9. Acknowledgments 493 Dec. 2007 (Expires Jun 2008) 495 Rohan Mahy and Patrik Faltstrom of Cisco Systems, for semantics. 497 10. Authors' Addresses 499 Andrew Daviel, BSc. 500 Vancouver Webpages, Box 357 501 185-9040 Blundell Rd 502 Richmond BC 503 V6Y 1K3 504 Canada 506 Tel. (604)-377-4796 507 Fax. (604)-270-8285 508 advax@triumf.ca 510 Felix A. Kaegi 511 Dipl.Informatik Ing. ETH (M.Sc.) 512 Friedensgasse 51 513 CH-4056 Basel 514 SWITZERLAND 516 Phone +41 61 383 10 01 517 Fax +41 79 625 27 41 518 skype felix_kaegi 519 felix.kaegi@gmail.com 521 Martin Kofahl 522 University Rostock 523 Geodesy and Geoinformatics 524 D-18051 Rostock 525 GERMANY 527 Phone +49 381 498 3212 528 Fax +49 381 498 3202 529 m.kofahl@gmx.net 531 Dec. 2007 (Expires Jun 2008) 533 Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementers or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights that may cover technology that may be required to implement 553 this standard. Please address the information to the IETF at ietf- 554 ipr@ietf.org. 556 Disclaimer of Validity 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 560 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 561 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 562 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Copyright Statement 566 Copyright (C) The IETF Trust (2007). 568 This document is subject to the rights, licenses and restrictions 569 contained in BCP 78, and except as set forth therein, the authors 570 retain all their rights. 572 Acknowledgment 573 Funding for the RFC Editor function is currently provided by the 574 Internet Society.