Regarding comment 1:
The situation could certainly use some cleaning up. The v4 description should simply reference Section 2.3.
What is described in 2.3 is consistent with the "bad is better than none" philosophy. I'm certainly OK with a sender being given a MUST directive, but a receiver needs to know what to do with bad inputs. At least with longitude, there are cases where wrapping successfully corrects errors.
Text suggestion for comment 2:
OLD:
... If the RFC 3825 DHCPv4 client
does not reject the option and utilizes the location data it will
most likely assume a datum and interpret the LongUnc/LatUnc/AltUnc
values as significant digits and apply them to the Latitude,
Longitude, and Altitude values. The resultant location value will be
in error up to a full degree of latitude and longitude, and a full
increment of altitude. ...
NEW:
... If the RFC 3825 DHCPv4 client
does not reject the option and utilizes the location data it will
most likely assume a datum.
Assuming one of the RFC 3825 datums causes correct interpretation of
Latitude/Longitude/Altitude values. The values for LongUnc/LatUnc
/AltUnc are mistakenly interpreted as representing significant digits.
The resultant location value will be in error up to a full degree of
latitude and longitude, and a full increment of altitude. ...
--Martin
p.s.
Clamp latitude:
latitude = max(-90, min(latitude, 90))
Wrap longitude:
longitude = (longitude + 180) % 360 - 180
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of geopriv issue tracker
> Sent: Tuesday, 22 June 2010 12:28 AM
> To: bernard_aboba@hotmail.com
> Cc: geopriv@ietf.org
> Subject: [Geopriv] [geopriv] #33: Lat/Long and Datum
>
> #33: Lat/Long and Datum
> ---------------------------------------+-------------------------------
> -----
> Reporter: bernard_aboba@… | Owner: bernard_aboba@…
> Type: defect | Status: new
> Priority: major | Milestone: draft-ietf-
> geopriv-3825bis
> Component: rfc3825bis | Version: 1.0
> Severity: In WG Last Call | Keywords:
> ---------------------------------------+-------------------------------
> -----
> Comment 1:
> The document is unclear about whether or not the lat/lon values SHOULD
> or
> MUST be constrained to +-90 / +- 180.
> -- v4 option format says SHOULD for both
> -- Section 2.3 says MUST for lat, SHOULD for lon
> -- v6 option format doesn't specify
> I would suggest changing all of these to MUST, unless you're keeping
> the
> option formats open to allow for them to be redefined by different
> datums.
>
> Comment 2:
> In Section 2.2.1.2, it might be helpful to note that if a v0-only
> client
> does ignore the datum element and accept the option, then it is
> probably
> going to interpret it as WGS84, and thus at least get correct
> coordinate
> values, as long as the server sends WGS84.
>
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/33>
> geopriv <http://tools.ietf.org/geopriv/>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
