Subject: [Geopriv] [geopriv] rfc3825bis #42 (new): Altitude format (from Richard Barnes)

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 06:09:59 -0000

#42: Altitude format (from Richard Barnes)

 Actually, while we're on this, there's another contradiction lurking here:

 On the one hand, the option definitions say:
 "Altitude:  A 30 bit value defined by the AType field."
 One might read this to mean that the AType value can specify the meaning
 of all the bits in the field.  So if I define AType=7, I could say that
 the the 30 bits contain a 3-character ASCII code describing the color of
 the carpet on the floor in question (with each character padded to 10
 bits, natch).  More to the point, for AType=2 (==floors), you might split
 the field into two integers, one signed and one unsigned, that represent
 "major" and "minor" floor numbers.  That way, you could actually directly
 represent 1.1, 4.1, 4.2.

 On the other hand, Section 2.4 defines the Altitude field as 22/8 fixed
 point regardless of the AType value -- it's only the semantic of this
 number that changes.  This rules out all of the creative encodings
 described above, at the cost of forcing everything into a 22/8 fixed-point
 mold.

 I'll leave it to the author to decide which of these to go with (I don't
 think it really matters much).  If it's the former, then the 22/8 fixed
 point thing should be moved down into the subsections of 2.4.  If the
 latter, then it should be moved up to the option definitions, as with the
 Latitude and Longitude fields.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  bernard_aboba@…           
     Type:  defect                     |      Status:  new                       
 Priority:  major                      |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:  1.0                       
 Severity:  Submitted WG Document      |    Keywords:                            
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/42>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 06:15:32 -0000

Comment(by bernard_aboba@…):

 Proposed Resolution:  Move the 22/8 fixed point thing down into the
 subsections of 2.4.

Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/42#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 06:21:37 -0000

Here is the proposed text for Sections 2.4, 2.4.1 and 2.4.2 (text for
 Section 2.4.3 is covered in Issue 41).

 2.4.  Altitude

    How the Altitude value is interpreted depends on the Altitude Type
    (AType) value and the selected datum.  Three Altitude Type values are
    defined in this document: unknown (0), meters (1) and floors (2).

 2.4.1.  No Known Altitude (AType = 0)

    In some cases, the altitude of the location might not be provided.
    An Altitude Type value of zero indicates that the altitude is not
    given to the client.  In this case, the Altitude and Altitude
    Uncertainty fields can contain any value and MUST be ignored.

 2.4.2.  Altitude in Meters (AType = 1)

    If the Altitude Type has a value of one, Altitude is measured in
    meters, in relation to the zero set by the vertical datum.  For AType
    = 1, the Altitude value is expressed as a 30 bit, fixed point, twos
    complement integer with 22 integer bits and 8 fractional bits.

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/42#comment:2>
geopriv <http://tools.ietf.org/geopriv/>