Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)
RFC 5962

I'm not entering a Discuss, but I have a number of fairly strong Comments that I hope you will feel able to debate in email and make updates to the draft accordingly.

---

Your Abstract says...

   This document defines PIDF-LO extensions that are intended to convey
   information about moving objects.

Perhaps you could be a little more afirmative? Such as:

   This document defines PIDF-LO extensions to convey information about
   moving objects.

---

Why is the directional component of acceleration not supplied?

---

In Section 3.1

   The <orientation> and <heading> establish a direction.

Aren't they both directions in their own right? And can't they be 
different?

<orientation> establishes a "direction of facing" while <heading>
establishes a "direction of travel".

---

In Section 3.1

   Angular
   measures are expressed in degrees and values MAY be negative.

Are you sure that this is an RFC 2119 "MAY"? Wouldn't "may" be perfectly
adequate?

---

In Section 3.1

   The first measure specifies the horizontal direction from the current
   position of the presentity to a point that it either pointing towards
   or travelling towards.

You (I hope) don't mean "either". Hopefully there is a little more
predictability! I think you mean:

   The first measure specifies the horizontal direction from the current
   position of the presentity to a point that it is pointing towards 
   (for <orientation>) or travelling towards (for <heading>).

---

In Section 3.1

   The second measure, if present, specifies the vertical component of
   this angle.  This angle is the elevation from the local horizontal
   plane.  If the second angle value is omitted, the vertical component
   is unknown and the speed measure MAY be assumed to only contain the
   horizontal component of speed.

Well, surely it is only if the second angle value of <heading> is 
omitted that you can make that assumption. If the second angle of 
<orientation> is absent, it says nothing about speed.

Additionally, when you say "MAY" in this case, it implies that the
normal case is something else that you have not stated.

---

Section 5

At the very least, you are introducing additional information that may
be distributed. Knowledge of that information makes a presentity more
vulnerable, therefore the definition of additional Presence Information
puts further weight behind the need to use security mechanisms.

3.1.  Angular Measures and Coordinate Reference Systems

   [RFC5491] constrains the coordinate reference system (CRS) used in
   PIDF-LO to World Geodetic System 1984 (WGS 84) using either the two-
   dimensional (latitude, longitude) CRS identified by
   "urn:ogc:def:crs:EPSG::4326" or the two-dimensional (latitude,

s/two-dimensional/three-dimensional

   longitude, altitude) CRS identified by "urn:ogc:def:crs:EPSG::4979".

It wouldn't hurt to add a definition or pointer to a definition of "presentity" to the Terminology section.

One question and two nits.

I almost made this a DISCUSS but I decided against it.  Question:
 
Was there any thought given to allowing a system of measurement parameter (i.e., imperial vs metric) to allow different speed measurements (e.g., feet/second vs meters/second)?

Nits:

Section 2: r/through/throughout
Section 2: r/[RFC4079])/[RFC4079]

I would also like to see some discussion of Adrian's comments.  I am particularly interested
in the decision to adopt the commonly used scalar definition of acceleration instead of the
vector definition of acceleration.  Was this considered?