[dhcwg] Re: Unit of Measurement...?

"James M. Polk" <jmpolk@cisco.com> Wed, 09 July 2003 19:44 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17661; Wed, 9 Jul 2003 15:44:37 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKrA-0007Bz-V4; Wed, 09 Jul 2003 15:44:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKqR-00074o-Su for dhcwg@optimus.ietf.org; Wed, 09 Jul 2003 15:43:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17611 for <dhcwg@ietf.org>; Wed, 9 Jul 2003 15:43:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKqQ-0002PU-00 for dhcwg@ietf.org; Wed, 09 Jul 2003 15:43:14 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aKqP-0002PN-00 for dhcwg@ietf.org; Wed, 09 Jul 2003 15:43:14 -0400
Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2003 12:45:34 -0700
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h69JgfMr018520; Wed, 9 Jul 2003 12:42:41 -0700 (PDT)
Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA28351; Wed, 9 Jul 2003 12:42:39 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030709142418.053cc718@localhost>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 Jul 2003 14:42:42 -0500
To: Henning Schulzrinne <hgs@cs.columbia.edu>
From: "James M. Polk" <jmpolk@cisco.com>
Cc: Marc Linsner <mlinsner@cisco.com>, 'Andrew Daviel' <andrew@daviel.org>, dhcwg@ietf.org, geopriv@mail.apps.ietf.org
In-Reply-To: <3F0C533D.1010605@cs.columbia.edu>
References: <4.3.2.7.2.20030708235923.053d2718@localhost> <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <4.3.2.7.2.20030708235923.053d2718@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] Re: Unit of Measurement...?
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

At 01:39 PM 7/9/2003 -0400, Henning Schulzrinne wrote:
>James M. Polk wrote:
>
>
>I gather the datum for long/lat does not uniquely define the datum for 
>altitude.

Our original datum was WSG84 (geoid or 3D) which has a vertical datum along 
with lat/long - and we added the UoM of floors for wired devices (one of 
the primary reqs of this effort) because for emergency responders in 
buildings - a meters of altitude value was determined to be too vague 
(which floor is 63 meters up?), thus necessitating "floors" be included 
instead of meters.

Floors have an established "0" as written in this ID.

We also included text stating that ~ 'if the datum does not include an 
altitude datum, consider "0" altitude to be "mean low tide" '. Perhaps we 
didn't take the same preciseness of altitude into account that we did for 
lat/long. We favored the view that precision of altitude in meters wouldn't 
be as important as it is in lat/long. We're obviously being corrected for 
that now.

However, I presently don't favor a move to separate the current altitude 
field into two: one of altitude (in meters for example), and one for floors 
(exclusively). I don't yet see the reason why both should reasonably ever 
be included at the same time. Parsing on the Altitude UoM field to see how 
the Altitude value should be interpreted should be sufficient here.

Adding text defining altitude, I have no problem with. I look forward to 
Greg's opinion (and hopefully text to this) to resolve this issue of 
clarity. We should state what's most reasonable towards defining or scoping 
altitude, and yet not try to solve (within an IETF document) that which 
(per Greg) hasn't been resolved by Geoloc focused people for more than a 
century (re: vertical datums).

Does this sound fair?





cheers,
James

                                *******************
                    The answer is "42", what's the question?


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg