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 <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.

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

2.1.2.  Sphere

   The <Sphere> element is described in Section 5.2.6 of [RFC5491].

2.1.3.  Ellipsoid

   The <Ellipsoid> element is described in Section 5.2.7 of [RFC5491].
   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.

2.1.4.  Prism

   The <Prism> element is described in Section 5.2.8 of [RFC5491].

2.2.  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 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
   <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.

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 <location> 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 <Ellipsoid> could produce a
   corresponding <Ellipse>.  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 <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, 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 <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



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 <serviceBoundary> 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 <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
   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
      <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.

5.  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.






Banks                     Expires 14 July 2025                  [Page 6]

Internet-Draft            A 3D Profile for LoST             January 2025


   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.

6.  Considerations for Polygons

   The <Polygon> 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 <Prism>.  [RFC5491] and [RFC5222] 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>).

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 <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.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc5222>.

   [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,
              <https://www.rfc-editor.org/info/rfc5491>.

   [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,
              <https://www.rfc-editor.org/info/rfc7459>.

Author's Address

   Dan Banks
   DATAMARK Technologies
   Columbus, OH
   United States of America
   Email: dbanks@ddti.net






Banks                     Expires 14 July 2025                  [Page 8]