A 3D Location Profile for the Location-to-Service Translation (LoST) Protocol

Introduction The Location-to-Service Translation (LoST) Protocol 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 (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 in order to provide different mappings in the <findServiceResponse> 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.

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 when, and only when, they appear in all capitals, as shown here.

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 <location> or <serviceBoundary> element.

Shapes This section identifies the shapes allowable within the "geodetic-3d" profile. All of the following are fully defined, including XML schema, in . 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.

Point The <Point> element is described in 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 <Point> is permitted within the "geodetic-3d" profile. The purpose for allowing the <Point> to be used within both profiles is discussed in section 5, below.

Sphere The <Sphere> element is described in .

Ellipsoid The <Ellipsoid> element is described in . Note that while the <Ellipsoid> contains elements representing the semi-major and semi-minor axes, the vertical dimension is contained within the <verticalAxis> element which represents the full length of the vertical axis rather than a semi-axis.

Prism The <Prism> element is described in .

Meaning of Shapes When a client uses one of the <Sphere>, <Ellipsoid>, or <Prism> elements, the shape represents a volume of uncertainty. The discussion in 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 <mapping> 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 <mapping> or a <redirect> to another server whose coverage area is a subset of the earlier server's coverage area.

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 . 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 profiles that derive from the "geodetic-2d" profile. Locations in separate profiles MUST appear as separate <location> elements. Because "a server uses the first-listed location profile that it understands and ignores the others" (, 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 <Ellipsoid> could produce a corresponding <Ellipse>. In general, the client SHOULD produce a 2D shape that reasonably represents the footprint of the original shape. 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.

Usage in a LoST Response Per , the LoST response may represent a service region using "one or more <serviceBoundary> 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 <location> elements, subject to the restrictions below." However, , rule 7 states "A server uses the first-listed location profile that it understands and ignores the others." Rule 9 further adds "The <serviceBoundary> 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 <locationUsed> element which applies to the entire <findServiceResponse>, not individual <mapping> 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 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 <serviceBoundary> in the "geodetic-3d" profile. For those reasons, Rule 7 is amended as follows:

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 <mapping> therefore MUST NOT contain multiple <serviceBoundary> elements, section 5.5 notwithstanding. Any <serviceBoundary> 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 <serviceBoundary> are additive and expresses intent for this to apply to both shapes and civic locations. The last paragraph of 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 <serviceBoundary> element, all the shapes MUST belong to the location profile identified for the <serviceBoundary> 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 <serviceBoundary> for a request.

Considerations for Points The <Point> 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 <Point> having three-dimensional coordinates and obtain an answer. However, such a query using the "geodetic-2d" profile precludes the return of a <serviceBoundary> 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 <serviceBoundary> in the "geodetic-2d" profile. In order to allow for a <serviceBoundary> in the "geodetic-3d" profile to be returned when the LoST server is queried with a three-coordinate <Point>, such a <Point> 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 <Point>. A server MAY then return a <serviceBoundary> according to whichever profile was actually used to determine the response.

Considerations for Polygons The <Polygon> defined in 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 <Prism>. and give special consideration to the <Point> in permitting the altitude to be included when used in the "geodetic-2d" profile, but no such consideration is given to <Polygon>. Thus, a <Polygon> used in the "geodetic-2d" profile MUST NOT include three-dimensional coordinates. Because <Polygon> is identified in RFC 5491 only as "(2d)", <Polygon> is intentionally omitted from the "geodetic-3d" profile (except as used within <Prism>).

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 <Polygon>. 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 <serviceBoundary> containing a simplified shape that fits entirely within the true shape of complex region.

IANA Considerations IANA is requested to add the "geodetic-3d" profile name to the "Location-to-Service Translation (LoST) Location Profiles" registry established by .

Security Considerations The introduction of the 3D location profile to LoST should not create any new security considerations beyond those described in or otherwise modify the security of the LoST protocol.