> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Friday, 11 September 2009 6:09 AM
> To: trac@localhost.amsl.com; Thomson, Martin; bernard_aboba@hotmail.com
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] [geopriv] #8: Altitude type of 0 == no altitude
>
> At 01:29 AM 9/10/2009, geopriv issue tracker wrote:
> >#8: Altitude type of 0 == no altitude
> >---------------------------------------+------------------------------
> ------
> > Reporter: martin.thomson@andrew.com | Owner:
> > martin.thomson@andrew.com
> > Type: defect | Status: new
> >
> > Priority: major | Milestone:
> >
> >Component: rfc3825bis | Version:
> >
> > Severity: - | Resolution:
> >
> > Keywords: altitude |
> >---------------------------------------+------------------------------
> ------
> >
> >Comment(by bernard_aboba@hotmail.com):
> >
> > Here is the text from draft-thomson-geopriv-3825bis-03:
> >
> > 2.4.1. No Known Altitude (AT = 0)
> >
> > In some cases, the altitude of the location might not be known.
> An
> > altitude type of 0 indicates that the altitude is not known. In
> this
> > case, the altitude and altitude uncertainty fields can contain
> any
> > value and are ignored.
> >
> > Is this text a satisfactory resolution to the issue?
>
> This doesn't satisfy the basic need to be able to provide location in
> 2D, where altitude simply isn't given (either because it is not known
> or it doesn't matter to the location provider (i.e., the sighter
> (dare I use that word :-) or measuring equipment result such as a
> wiremap database).
>
> A lot of times (like probably 90% of the time), location in 2D is
> satisfactory. From the client's point of view, it will not learn the
> location, but that doesn't necessarily mean the location isn't known
> to the server (and it didn't provide it for whatever reason).
>
> I suggest this subtle rephrasing of section 2.4.1:
>
> 2.4.1. Altitude Not Provided (AT = 0)
>
> In some cases, the altitude of the location might not be provided.
> An
> altitude type of 0 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.
>
> this last 'MUST' is so that implementations do not use the fields
> unless they want to be considered 'out of compliance', which may be
> fine with proprietary (augmented) implementations - but it does
> remove any doubt about how the client is to interpret the 2 fields
> according to this spec.
>
> James
>
>
> >--
> >Ticket URL:
> <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/8#comment:2>
> >geopriv <http://tools.ietf.org/geopriv/>
> >
> >_______________________________________________
> >Geopriv mailing list
> >Geopriv@ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
>
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
