ecrit D. Banks Internet-Draft DATAMARK Technologies Updates: 5222 (if approved) 10 January 2025 Intended status: Standards Track Expires: 14 July 2025 A 3D Location Profile for the Location-to-Service Translation (LoST) Protocol draft-banks-ecrit-lost-3d-profile-00 Abstract This document defines a new location profile containing three- dimensional (3D) shapes to be used with the Location-to-Service Translation Protocol (LoST) defined in RFC 5222. Registration of the 3D location profile in the "Location-to-Service Translation (LoST) Location Profiles" IANA registry is requested accordingly. Inconsistencies in RFC 5222 relating to additional location profiles are revised and additional clarification is given to assist implementors when using this profile. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 July 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Banks Expires 14 July 2025 [Page 1] Internet-Draft A 3D Profile for LoST January 2025 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Three-Dimensional Geodetic Profile . . . . . . . . . . . . . 3 2.1. Shapes . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Point . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.3. Ellipsoid . . . . . . . . . . . . . . . . . . . . . . 4 2.1.4. Prism . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Meaning of Shapes . . . . . . . . . . . . . . . . . . . . 4 3. Usage in a LoST Query . . . . . . . . . . . . . . . . . . . . 4 4. Usage in a LoST Response . . . . . . . . . . . . . . . . . . 5 5. Considerations for Points . . . . . . . . . . . . . . . . . . 6 6. Considerations for Polygons . . . . . . . . . . . . . . . . . 7 7. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Location-to-Service Translation (LoST) Protocol [RFC5222] uses a location profile when conveying location in a request or response. The LoST specification includes two baseline location profiles and mandates that exactly one of baseline profiles be used in addition to zero or more additional profiles. The baseline profile for expressing a location in geodetic form is "geodetic-2d", and the profile allows a subset of the shapes described in [RFC5491] (which are in turn taken from GeoShape). With the exception of a point having three coordinates, no 3D shapes are included in the "geodetic- 2d" profile. Location supplied with emergency calls is now commonly provided with three-dimensional attributes representing a volume where the caller is likely to be found. The Sphere, Ellipsoid, and Prism shapes from RFC 5491 and GeoShape are used to represent this volume and can be included in PIDF-LO, but cannot be used to query a LoST server because they are not included in any existing location profile. It is desirable for a LoST server be able to take elevation into account Banks Expires 14 July 2025 [Page 2] Internet-Draft A 3D Profile for LoST January 2025 in order to provide different mappings in the for locations that would otherwise share a common horizontal position. Further, it is not desirable to discard the representation of uncertainty (e.g., query using a 3D point) in order to include elevation. To overcome these limitations and to fully accommodate the 3D shapes that are expected in PIDF-LO, we introduce the "geodetic-3D" profile. Some text in RFC 5222 discussing multiple location profiles, particularly with respect to service boundaries, is confusing or inconsistent. With the addition of a new location profile, it is necessary to provide the revisions and clarifications which can be found below. Additionally, a number of implementations of LoST have been observed to behave contrary to certain requirements in RFC 5222, leading to interoperability issues. Further guidance is therefore provided to assist implementors in achieving conformance and interoperability. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Three-Dimensional Geodetic Profile The "geodetic-3d" location profile is identified by the token "geodetic-3d" and derives from the baseline "geodetic-2d" profile. As with the "geodetic-2d" profile, clients and servers use this profile by placing shapes into a or element. 2.1. Shapes This section identifies the shapes allowable within the "geodetic-3d" profile. All of the following are fully defined, including XML schema, in [GeoShape]. Note that the 'srsName' for three-dimensional shapes is "urn:ogc:def:crs:EPSG::4979", not "urn:ogc:def:crs:EPSG::4326" as used with two-dimensional shapes. Banks Expires 14 July 2025 [Page 3] Internet-Draft A 3D Profile for LoST January 2025 2.1.1. Point The element is described in Section 5.2.1 of [RFC5491] and can be represented using either two-dimensional or three-dimensional coordinates. Both forms are permitted within the "geodetic-2d" profile, but only the three-dimensional is permitted within the "geodetic-3d" profile. The purpose for allowing the to be used within both profiles is discussed in section 5, below. 2.1.2. Sphere The element is described in Section 5.2.6 of [RFC5491]. 2.1.3. Ellipsoid The element is described in Section 5.2.7 of [RFC5491]. Note that while the contains elements representing the semi-major and semi-minor axes, the vertical dimension is contained within the element which represents the full length of the vertical axis rather than a semi-axis. 2.1.4. Prism The element is described in Section 5.2.8 of [RFC5491]. 2.2. Meaning of Shapes When a client uses one of the , , or elements, the shape represents a volume of uncertainty. The discussion in Section 12.2 of [RFC5222] regarding the area of two- dimensional shapes applies similarly to the volume of three- dimensional shapes. That is, the client is expected to be satisfied by a result pertaining to any portion of the volume, multiple elements MAY be returned when applicable, and a server that understands the "geodetic-3d" profile and is authoritative for any part of the queried volume MUST return either a or a to another server whose coverage area is a subset of the earlier server's coverage area. 3. Usage in a LoST Query When a client wishes to query a LoST server using the "geodetic-3d" profile, it MUST conform to the behavior described in Section 12 of [RFC5222]. Specifically, the request MUST contain location information in the baseline "geodetic-2d" profile in addition to the "geodetic-3d" profile, and it MUST NOT contain location information in the baseline "civic" profile or any other profile that derives from the "civic" profile. The request MAY include location in other Banks Expires 14 July 2025 [Page 4] Internet-Draft A 3D Profile for LoST January 2025 profiles that derive from the "geodetic-2d" profile. Locations in separate profiles MUST appear as separate elements. Because "a server uses the first-listed location profile that it understands and ignores the others" (Section 12.1 of [RFC5222], rule 7), the "geodetic-3d" location should be placed before the "geodetic- 2d" location in the query or it will not be considered. It is possible that the location information a LoST client is in possession of solely fits the "geodetic-3d" profile. In order to meet the above requirements, the client will need to produce a corresponding location within the "geodetic-2d" profile. For example, a client in possession of an could produce a corresponding . In general, the client SHOULD produce a 2D shape that reasonably represents the footprint of the original shape. Section 5.3 of [RFC7459] discusses a simple conversion technique for each of the shapes (except Point) in the "geodetic-3d" profile. RFC 7459 also discusses the effect that the suggested conversion has upon the confidence of the resultant shape. Note that the representation of confidence defined by RFC 7459 for use in PIDF-LO is not included within either the "geodetic-2d" or "geodetic-3d" profile. Although it may be possible to manipulate the uncertainty and confidence of a shape to scale one at the expense of the other, the client is not expected to perform such manipulation for the purpose of formulating a LoST query. 4. Usage in a LoST Response Per Section 5.5 of [RFC5222], the LoST response may represent a service region using "one or more elements" and that the elements be in varying location profiles. The text in section 12.1 allows that "A response MAY contain multiple mappings or boundaries for the different elements, subject to the restrictions below." However, Section 12.1 of [RFC5222], rule 7 states "A server uses the first-listed location profile that it understands and ignores the others." Rule 9 further adds "The element MUST use the same location profile that was used to retrieve the answer and indicates which profile has been used with the 'profile' attribute." And finally, the schema only allows a single element which applies to the entire , not individual elements. Until now, there have been no profiles beyond the baseline profiles, so this contradiction was of no practical consequence. Additionally, it is recognized that a server could understand a profile (such as the "geodetic-3d" profile) but not have the data necessary to Banks Expires 14 July 2025 [Page 5] Internet-Draft A 3D Profile for LoST January 2025 determine a response for that profile. For example, service regions may not be described in three dimensions for all areas and the server would be unable to produce a in the "geodetic-3d" profile. For those reasons, Rule 7 is amended as follows: 7. A server uses the first-listed location that it both understands and is able to formulate a response for. Other locations are ignored. Further, we reaffirm rule 9. A therefore MUST NOT contain multiple elements, section 5.5 notwithstanding. Any sent to a client will conform to one of the profiles used in the request, so no additional representations are needed in order to assure that the client understands the boundary. Lastly, section 5.5 states that multiple locations within a are additive and expresses intent for this to apply to both shapes and civic locations. The last paragraph of Section 12.2 of [RFC5222] seemingly contradicts this and states that such elements are alternative descriptions, not additive geometries. However, the practical consequence of allowing "alternate" descriptions is that they would effectively be additive. Replacing the entire final paragraph of section 12.2, we revise the usage of multiple shapes as follows: When multiple geodetic shapes are placed within a single element, all the shapes MUST belong to the location profile identified for the and the resultant boundary encompasses the area or volume represented by the combination of all the shapes. However, complex boundary representations might be problematic for performance and servers MAY choose not to return any for a request. 5. Considerations for Points The element used in the "geodetic-2d" profile is permitted to have either two or three coordinates, so it is not necessary to use the "geodetic-3d" profile in order to query with a having three-dimensional coordinates and obtain an answer. However, such a query using the "geodetic-2d" profile precludes the return of a that includes elevation information. Additionally, in the event that altitude of the point is used to choose a service region that otherwise would not have been chosen using horizontal coordinates alone, it would be incorrect to return a in the "geodetic-2d" profile. Banks Expires 14 July 2025 [Page 6] Internet-Draft A 3D Profile for LoST January 2025 In order to allow for a in the "geodetic-3d" profile to be returned when the LoST server is queried with a three- coordinate , such a is permitted within the "geodetic- 3d" profile. A client still MUST include a location in the "geodetic-2d" baseline profile as well, which MAY be the same . A server MAY then return a according to whichever profile was actually used to determine the response. 6. Considerations for Polygons The defined in [GeoShape] can be specified using points with either two coordinates or three, with the third (altitude) being constant. The latter construct is useful when serving as the base of a . [RFC5491] and [RFC5222] give special consideration to the in permitting the altitude to be included when used in the "geodetic-2d" profile, but no such consideration is given to . Thus, a used in the "geodetic-2d" profile MUST NOT include three-dimensional coordinates. Because is identified in RFC 5491 only as "(2d)", is intentionally omitted from the "geodetic-3d" profile (except as used within ). 7. Limitations Within the "geodetic-2d" profile, any two-dimensional shape can be approximated (ignoring whether the shape is truly planar or is relative to the ellipsoid) to an arbitrary degree with a . While the shapes included in the "geodetic-3d" profile are expected to be adequate for representing location in a query, they do not allow such approximation of all three-dimensional shapes. Consequently, a server may not be able to produce a comprehensive representation of a three-dimensional service region. However, a server MAY choose to return a containing a simplified shape that fits entirely within the true shape of complex region. 8. IANA Considerations IANA is requested to add the "geodetic-3d" profile name to the "Location-to-Service Translation (LoST) Location Profiles" registry established by [RFC5222]. 9. Security Considerations The introduction of the 3D location profile to LoST should not create any new security considerations beyond those described in Section 18 of [RFC5222] or otherwise modify the security of the LoST protocol. Banks Expires 14 July 2025 [Page 7] Internet-Draft A 3D Profile for LoST January 2025 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, . [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, DOI 10.17487/RFC5491, March 2009, . [GeoShape] Reed, C., Ed. and M. Thomson, Ed., "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification 06-142r1, Version: 1.0, 10 April 2007. 10.2. Informative References [RFC7459] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO)", RFC 7459, DOI 10.17487/RFC7459, February 2015, . Author's Address Dan Banks DATAMARK Technologies Columbus, OH United States of America Email: dbanks@ddti.net Banks Expires 14 July 2025 [Page 8]