idnits 2.17.1 draft-ietf-geopriv-geo-uri-00.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.i 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 '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 and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2009) is 5442 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) == Unused Reference: 'RFC3261' is defined on line 578, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV -- Geographic A. Mayrhofer 3 Location/Privacy Working Group nic.at 4 Internet-Draft C. Spanring 5 Expires: December 4, 2009 OIR-ID 6 June 2, 2009 8 A Uniform Resource Identifier for Geographic Locations ('geo' URI) 9 draft-ietf-geopriv-geo-uri-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 4, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document specifies an Uniform Resource Identifier (URI) for 58 geographic locations using the 'geo' scheme name. A 'geo' URI 59 identifies a physical location by latitude, longitude and optionally 60 altitude in a compact, simple, human-readable, and protocol 61 independent way. 63 Table of Contents 65 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. IANA Registration of 'geo' URI Scheme . . . . . . . . . . . . 7 72 4.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 7 75 4.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 7 76 4.4.1. Component Description . . . . . . . . . . . . . . . . 8 77 4.4.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 8 78 4.4.3. Interpretation of Undefined Altitude . . . . . . . . . 8 79 4.5. Encoding Considerations . . . . . . . . . . . . . . . . . 9 80 4.6. Applications/protocols That Use This URI Scheme . . . . . 9 81 4.7. Interopability Considerations . . . . . . . . . . . . . . 9 82 4.8. Security Considerations . . . . . . . . . . . . . . . . . 9 83 4.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 4.10. Author/Change controller . . . . . . . . . . . . . . . . . 10 85 4.11. References . . . . . . . . . . . . . . . . . . . . . . . . 10 87 5. URI Operations . . . . . . . . . . . . . . . . . . . . . . . . 10 89 6. Use Cases and Examples . . . . . . . . . . . . . . . . . . . . 10 90 6.1. Plain 'geo' URI Example . . . . . . . . . . . . . . . . . 10 91 6.2. Hyperlink . . . . . . . . . . . . . . . . . . . . . . . . 10 92 6.3. 'geo' URI in 2-dimensional barcode . . . . . . . . . . . . 11 94 7. GML Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 7.1. 'geo' URI without altitude to GML 'Point' . . . . . . . . 12 96 7.2. 'geo' URI with Altitude to GML 'Point' . . . . . . . . . . 12 97 7.3. GML 'Point' without Altitude to 'geo' URI . . . . . . . . 12 98 7.4. GML 'Point' with Altitude to 'geo' URI . . . . . . . . . . 13 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 103 9.1. Invalid Locations . . . . . . . . . . . . . . . . . . . . 14 104 9.2. Location Privacy . . . . . . . . . . . . . . . . . . . . . 14 106 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 114 1. Change Log 116 [Note to editors: This section is to be removed before publication - 117 XML source available on request] 119 draft-ietf-geopriv-geo-uri-00 120 o submitted as WG item 121 o changed IPR text because of text used from RFC 4395 122 o added considerations for comparing +180/-180 longitude URIs 123 o some editorial changes 125 draft-mayrhofer-geopriv-geo-uri-01 126 o added terminology text about WGS-84 (credits Carl Reed) 127 o removed "resolution" / "uncertainty" text 128 o added considerations regarding poles 129 o added text about invalid URIs 131 draft-mayrhofer-geopriv-geo-uri-00 132 o Initial version under new name, reverting to "plain" lat/lon 133 scheme, with the "tiling" scheme moved to seperate draft 134 (potentially published as "draft-mayrhofer-geopriv-geotile-uri"). 135 refer to draft-mayrhofer-geo-uri-01 for the history of this 136 document. 137 o Added GML mapping section 139 draft-mayrhofer-geo-uri-01 140 o removed parameters 142 draft-mayrhofer-geo-uri-00 143 o initial draft 145 2. Introduction 147 An increasing number of Internet protocols and data formats are 148 extended by specifications for adding spatial (geographic) location. 149 In most cases, latitude as well as longitude of simple points are 150 added as new attributes to existing data structures. However, all 151 those methods are very specific to a certain data format or protocol, 152 and don't provide a protocol independent, compact and generic way to 153 refer to a physical geographic location. 155 Over the past few years, fast emerging location aware applications 156 and location based services were observable on the Internet. Most 157 web search engines use geographic information, and a vivid open 158 source mapping community brought an enormous momentum into location 159 aware technology. A wide range and former to professionals exclusive 160 tools and data were provided free of charge for an everyday use on 161 the mass market. 163 The 'geo' URI scheme is another step into that direction and aims to 164 facilitate, support and standardize the problem of location 165 identification in geospatial services and applications. Accessing 166 information about or trigger further services based on a particular 167 place on earth shouldn't be any harder for users than clicking on a 168 'mailto:' link and write an email straight away. 170 According to [RFC3986], a Uniform Resource Identifier (URI) is "a 171 compact sequence of characters that identifies an abstract or 172 physical resource". The 'geo' URI scheme defined in this document 173 identifies geographic locations (a physical resource) in the World 174 Geodetic System 1984 (WGS-84) [WGS84] reference system. 176 'Geo' URIs identify a geographic location using a textual 177 representation of the location's spatial coordinates in either two or 178 three dimensions (latitude, longitude, and optionally altitude). 179 Such URIs are independent from a specific protocol, application, or 180 data format, and can be used in any other protocol or data format 181 that supports inclusion of arbitrary URIs. 183 The definition of the URI scheme is strictly focused on the most 184 simplest representation of a spatial location - a single point. The 185 provision of more complex geometries or locations described by civic 186 addresses is out of scope of this document. 188 Note: The choice of WGS-84 is based on the widespread availability of 189 Global Positioning System (GPS) devices, which use the WGS-84 190 reference system. It is anticipated that such devices serve as one 191 of the primary data sources for authoring 'geo' URIs, hence the 192 adoption of the native GPS reference system for the URI scheme. 193 Also, many other data formats for representing geographic locations 194 use the WGS-84 reference system, which makes transposing from and to 195 such data formats less error prone (no re-projection involved). 197 3. Terminology 199 Geographic locations in this document are defined using WGS 84 (World 200 Geodetic System 1984), equivalent to the OGP Surveying and 201 Positioning Committee EPSG code 4326 (2 dimensions) and 4979 (3 202 dimensions). This document does not assign responsibilities for 203 coordinate transformations from and to other Spatial Reference 204 Systems. 206 A 2-dimensional WGS-84 coordinate value is here represented as a 207 comma-delimited latitude/longitude pair, measured in decimal degrees 208 (un-projected). A 3-dimensional WGS-84 coordinate value is here 209 represented by appending a comma-delimited altitude value in meters 210 to such pairs. 212 Latitudes range from -90 to 90 and longitudes range from -180 to 180. 213 Coordinates in the Southern and Western hemispheres as well as 214 altitudes below the WGS-84 reference geoid are signed negative with a 215 leading dash. 217 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 218 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 219 document are to be interpreted as described in RFC 2119 [RFC2119]. 221 4. IANA Registration of 'geo' URI Scheme 223 This section contains the fields required for the URI scheme 224 registration, following the guidelines in section 5.4 of [RFC4395]. 226 4.1. URI Scheme Name 228 geo 230 4.2. Status 232 permanent 234 4.3. URI Scheme Syntax 236 The syntax of the 'geo' URI scheme is specified below in Augmented 237 Backus-Naur Form (ABNF) [RFC4234]: 239 geo-URI = geo-scheme ":" geo-path 240 geo-scheme = "geo" 241 geo-path = geo-location 243 geo-location = latitude "," longitude [ "," altitude ] 245 latitude = [ "-" ] 1*2DIGIT [ "." *DIGIT ] 246 longitude = [ "-" ] 1*3DIGIT [ "." *DIGIT ] 247 altitude = [ "-" ] *DIGIT [ "." *DIGIT ] 249 4.4. URI Scheme Semantics 251 Data contained in a 'geo' URI identifies a physical resource: A 252 spatial location on earth in the WGS-84 references system, identified 253 by the geographic coordinates encoded in the URI. 255 4.4.1. Component Description 257 The "latitude", "longitude" and "altitude" components as specified in 258 the URI scheme syntax ( Section 4.3) are to be used as follows: 259 o The "latitude" component MUST contain the latitude of the 260 identified location in decimal degrees in the reference system 261 WGS-84. 262 o The "latitude" component MUST contain the latitude of the 263 identified location in decimal degrees in the reference system 264 WGS-84. 265 o If present, the OPTIONAL "altitude" component MUST contain the 266 WGS-84 altitude of the identified location in meters. 268 If the altitude of the location is unknown, the "altitude" component 269 MUST NOT be present in the URI. Specifically, unknown altitude MUST 270 NOT be represented by setting the 'altitude' component to "0" (or any 271 other arbitrary value). 273 The "longitude" components of coordinate values reflecting the poles 274 (latitude set to -90 or 90 degrees) SHOULD be set to "0", although 275 consumers of "geo" URIs MUST accept such URIs with any longitude 276 value between -180 and 180. 278 'geo' URIs with longitude values outside the range of -180 to 180 279 decimal degrees or with latitude values outside the range of -90 to 280 90 degrees MUST be considered invalid. 282 4.4.2. URI Comparison 284 Two 'geo' URIs are equal when their 'longitude', 'latitude' and 285 'altitude' values are mathematically identical. Where the 'latitude' 286 component of a 'geo' URI is set to either 90 or -90 degrees, the 287 'longitude' component MUST be ignored in comparison operations. A 288 'longitude' component of 180 degrees MUST be considered equal a 289 'longitude' component of -180 degrees for the purpose of URI 290 comparison. 292 An URI with undefined (missing) 'altitude' value MUST NOT be 293 considered equal to an URI containing an 'altitude' value, even if 294 the remaining values 'latitude' and 'longitude' are equivalent. 296 4.4.3. Interpretation of Undefined Altitude 298 A consumer of a 'geo' URI with undefined 'altitude' MAY assume that 299 the URI refers to the respective location on earth's physical surface 300 at the given 'latitude' and 'longitude' coordinate. 302 However, as defined above, altitudes are relative to the WGS-84 303 reference geoid rather than earth's surface. Hence, an altitude 304 value of 0 MUST NOT be interpreted as "on earth's surface". 306 4.5. Encoding Considerations 308 The 'geo-location' path component of the 'geo' URI (see Section 4.3) 309 uses a comma (",") as a delimiter for subcomponents. This delimiter 310 MUST NOT be percent encoded. 312 It is RECOMMENDED that for readability the contents of 'latitude', 313 'longitude' and 'altitude' subcomponents are never percent encoded. 315 4.6. Applications/protocols That Use This URI Scheme 317 As many other URI scheme definitions, the 'geo' URI provides resource 318 identification independent of a specific application or protocol. 319 Examples of potential protocol mappings and use cases can be found in 320 Section 6. 322 4.7. Interopability Considerations 324 As with any other new URI scheme, the 'geo' URI requires support in 325 client applications. Users of applications which are not aware of 326 the 'geo' scheme are likely unable to make direct use of the 327 information in the URI. However, the simple structure of the 'geo' 328 URI would even allow manual dereference by users. 330 Poorly authored 'geo' URI instances could contain whitespace and 331 values with leading plus signs ("+"), which is not allowed according 332 to the ABNF. Clients SHOULD, however, try to dereference such URIs 333 after removing such whitespace and plus signs. 335 This specification does not define any URI parameters nor a query 336 component. Future revisions might define such parameters, using the 337 ";" and "?" characters to delimit parameter and query components from 338 the path component specified above. Clients MUST be prepared to 339 encounter such 'geo' URI instances, and MUST reduce the URI to the 340 components specified in Section 4.3 before they dereference the URI. 342 4.8. Security Considerations 344 See Section 9 of [insert reference to this document] 346 4.9. Contact 348 Christian Spanring (mailto:cspanring@gmail.at, http://spanring.eu/ ), 349 Alexander Mayrhofer (mailto:alexander.mayrhofer@nic.at, 350 http://timatio.com/ ) 352 4.10. Author/Change controller 354 The 'geo' URI scheme is registered under the IETF part of the URI 355 tree. As such, change control is up to the IETF. 357 4.11. References 359 RFC XXXX [change to RFC number once assigned] 361 5. URI Operations 363 Currently, just one operation on a 'geo' URI is defined - location 364 dereference: In that operation, a client dereferences the URI by 365 extracting the geographical coordinates from the URI path component 366 ('geo-path' in the ABNF). Further use of those coordinates is then 367 up to the application processing the URI, and might depend on the 368 context of the URI. 370 An application may then use this location information for various 371 purposes, for example: 373 o A web browser could use that information to open a web mapping 374 service of the user's choice, and display a map of the location 376 o A navigational device such as a Global Positioning System (GPS) 377 receiver could offer the user to start navigation to the location. 379 6. Use Cases and Examples 381 6.1. Plain 'geo' URI Example 383 The following 3-dimensional 'geo' URI example references to the 384 office location of one of the authors in Vienna, Austria: 386 geo:48.2010,16.3695,183 388 A user could type the data extracted from this URI into a electronic 389 navigation device, or even use it to locate the identified location 390 on a paper map. 392 6.2. Hyperlink 394 'geo' URIs (like any other URI scheme) could also be embedded as 395 hyperlinks in web pages. A Hyper Text Markup Language (HTML) snippet 396 with such a hyperlink could look like: 398

one of Vienna's popular sights is the Karlskirche. 401 A web brower could extract the coordinates from the HTML snippet, and 402 offer the user various options (based on configuration, context), for 403 example: 405 o display a small map thumbnail when the mouse pointer hovers over 406 the link 408 o switch to a mapping service of the user's choice once the link is 409 selected 411 o Locate nearby resources, for example by comparing the 'geo' URI 412 with locations extracted from GeoRSS feeds the user has subscribed 413 to. 415 o Convert the coordinates to a format suitable for uploading to a 416 navigation device 418 6.3. 'geo' URI in 2-dimensional barcode 420 Due to it's short length, a 'geo' URI could easily be encoded in 421 2-dimensional barcodes. Such barcodes could be printed on business 422 cards, flyers, paper maps and subsequently used by mobile devices, 423 for example as follows: 425 1. User identifies such a barcode on a flyer, uses the camera on his 426 mobile phone to photograph and decode the barcode 428 2. The mobile phone dereferences the 'geo' URI, and offers the user 429 to calculate a navigation route to the identified location. 431 3. Using the builtin GPS, the user follows the navgiation 432 instructions from his phone to reach the destination 434 7. GML Mappings 436 The Geographic Markup Language (GML) by the Open Geospatial 437 Consortium (OGC) is a set of XML schemas to represent geographical 438 features. Since GML is widely accepted, this document includes 439 instructions on how to transpose 'geo' URIs from and to GML 440 documents. 442 A 'geo' URI can be authored from a GML "point", and any 'geo' URI can 443 be mapped to a GML "point". For the following sections, "%lat%", 444 "%lon%" and "%alt%" are placeholders for latitude, longitude, and 445 altitude values. Mappings are defined as follows: 447 7.1. 'geo' URI without altitude to GML 'Point' 449 An instance of the 'geo' URI without the altitude element is mapped 450 to a two-dimensional GML "Point" as follows: 452 'geo' URI: 454 geo:%lat%,%lon% 456 GML document: 458 459 462 %lat% %lon% 463 465 7.2. 'geo' URI with Altitude to GML 'Point' 467 A 'geo' URI instance with the altitude element is mapped to a three- 468 dimensional GML "Point" as follows: 470 'geo' URI: 472 geo:%lat%,%lon%,%alt% 474 GML document: 476 477 480 %lat% %lon% %alt% 481 483 7.3. GML 'Point' without Altitude to 'geo' URI 485 A GML 'Point' in the reference system identified as 486 "urn:ogc:def:crs:EPSG:6.6:4326" is mapped to a 'geo' URI as follows: 488 GML document: 490 491 494 %lat% %lon% 495 497 'geo' URI: 499 geo:%lat%,%lon% 501 Note: GML documents in other reference systems MAY be used as well if 502 a transformation into "urn:ogc:def:crs:EPSG:6.6:4326" is defined and 503 applied before the mapping step. 505 7.4. GML 'Point' with Altitude to 'geo' URI 507 A GML 'Point' in the reference system identified as 508 "urn:ogc:def:crs:EPSG:6.6:4979" is mapped to a 'geo' URI as follows: 510 GML document: 512 513 516 %lat% %lon% 517 519 'geo' URI: 521 geo:%lat%,%lon% 523 Note: GML 'Point' instances in other reference systems MAY be used as 524 well if a transformation into "urn:ogc:def:crs:EPSG:6.6:4979" is 525 defined and applied before the mapping step. 527 8. IANA Considerations 529 This document requests assignment of the 'geo' URI scheme in the IETF 530 part of the URI scheme tree, according to the guidelines in BCP 115 531 (RFC 4395) [RFC4395]. The definitions required for the assignment 532 are contained in Section 4. 534 9. Security Considerations 536 Because the 'geo' URI is not tied to any specific protocol, and 537 identifies a physical location rather than a network resource, most 538 of the general security considerations on URIs (Section 7 of RFC 539 3986) do not apply. However, the following (additional) issues 540 apply: 542 9.1. Invalid Locations 544 The URI syntax (Section 4.3) makes it possible to construct valid 545 'geo' URIs which don't identify a valid location on earth. 546 Applications MUST NOT use URIs which such invalid values, and SHOULD 547 warn the user when such URIs are encountered. 549 An example of such an invalid URI would be (latitude 550 "beyond" north pole). 552 9.2. Location Privacy 554 Location information about individuals is an extremely sensitive 555 topic, especially when location is combined with Personally 556 Identifyable Information (PII). Authors of 'geo' URIs MUST consider 557 data protection and privacy before publishing such URIs. 559 10. Acknowledgements 561 The authors wish to acknowledge the helpful contributions from Carl 562 Reed, Bill McQuillan, Martin Kofal, Andrew Turner and Kim Sanders. 564 11. References 566 11.1. Normative References 568 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 569 Resource Identifier (URI): Generic Syntax", STD 66, 570 RFC 3986, January 2005. 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 576 Specifications: ABNF", RFC 4234, October 2005. 578 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 579 A., Peterson, J., Sparks, R., Handley, M., and E. 581 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 582 June 2002. 584 11.2. Informative References 586 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 587 Registration Procedures for New URI Schemes", BCP 115, 588 RFC 4395, February 2006. 590 [WGS84] National Imagery and Mapping Agency, "Department of 591 Defense World Geodetic System 1984, Third Edition", 592 NIMA TR8350.2, January 2000. 594 Authors' Addresses 596 Alexander Mayrhofer 597 nic.at GmbH 598 Karlsplatz 1/9 599 Wien A-1010 600 Austria 602 Phone: +43 1 5056416 34 603 Email: alexander.mayrhofer@nic.at 604 URI: http://www.nic.at/ 606 Christian Spanring 607 OIR-ID GmbH 608 Franz-Josefs-Kai 27 609 Wien A-1010 611 Phone: +43 1 5338747 36 612 Email: cspanring@gmail.com 613 URI: http://www.oir.at/