Subject: RE: LOC record rounding policy

From: "Christian Huitema" <[email-masked]>
Date: Wed, 30 Jan 2002 18:41:46 -0800

> But I can't begin to think why we're discussing this here, as long as
the
> correct thing is on the wire (ie: 1000'ths) then how that is input is
a
> quality of implementation issue - for me, I don't think I'd want to be
> dealing
> in radians (or their fractions) at all, I still prefer degrees,
minutes,
> ...
> (including decimals of a second if appropriate).

A 1/1000th of a second of arc is about 3.1 centimeters at the equator or
along a meridian -- not much more than an inch. What exactly is the
application that: (a) needs a better precision; (b) needs that better
precision stored in the DNS; and (c) needs the better precision so much
that it would break on a rounding error ?..

-- Christian Huitema

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jan 2002 19:11:08 -0800

i run a cron against the readings of the gps.  it looks to see how stable
a reading it gets over time, now approaching three years.  it prints the
string that is stable.  the device may or may not have some precision.  i
don't really care.  i just run a script which produces a loc rr.  if the
wire format wants less digits of precision, it should round.  if it wants
more precision, it should add zeros.

randy

---

From: [email-masked]
Date: Thu, 31 Jan 2002 14:29:43 +1100

> don't really care.  i just run a script which produces a loc rr.

	No.  You produce something looks vaguely like a LOC record.
	If there is more than three decimal places in the seconds
	fields then it is not a LOC record.

	I suggest that you fix the script.

> if the
> wire format wants less digits of precision, it should round.

	Well if you want it to round please write the new draft
	and then everyone that has implemented LOC can rev their
	implementation.

>  if it wants more precision, it should add zeros.

	That was already allowed.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Jan 2002 11:00:51 +0700

Date:        Wed, 30 Jan 2002 18:41:46 -0800
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | A 1/1000th of a second of arc is about 3.1 centimeters at the equator or
  | along a meridian -- not much more than an inch. What exactly is the
  | application that: (a) needs a better precision; (b) needs that better
  | precision stored in the DNS; and (c) needs the better precision so much
  | that it would break on a rounding error ?..

There are none ... but it is important that the RRs can be specified
precisely.

But that's fine now, specifying 3 decimal places exactly does that, and
no-one is planning on altering that.

The only question is what should be done when someone for whatever reason
(perhaps reacting to 33 1/3 seconds somewhere and producing 33.33333333)
gives more than is specified, what should be done.

I still don't care, and nothing I have seen yet has convinced me that there's
any reason at all for anyone else to care either.

If the user does care, he can just specify the exact 3 decimal digits,
then everyone knows exactly what will happen.   More than 3, and the 
implementation does whatever it likes.   Let's just move on to issues that
are worthy of debate (and by all means, Randy, or anyone, can express
opinions to the various implementors about how the implementations they use
should behave, and the implementors will, usually anyway, take those kinds
of opinions into account).

kre

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jan 2002 20:07:38 -0800

> I suggest that you fix the script.

as your assertion is not well supported by the rfc, i suggest you need to
first fix the rfc.

randy

---

From: [email-masked]
Date: Thu, 31 Jan 2002 15:35:22 +1100

> as your assertion is not well supported by the rfc, i suggest you need to

	If the RFC had wanted to allow for extra precision it would
	have stated that the field should be rounded or truncated,
	in words in the main part of the RFC.  We would not be
	having this discussion now if the intent was to allow for
	more than thousandths of a second.

	The sample code has considerable flaws in it, it does not
	reflect the intent of the main body of the RFC.  It will
	handle valid input correctly.  Invalid input however is not
	rejected and in many cases not detected.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Jan 2002 12:05:37 +0700

Date:        Thu, 31 Jan 2002 15:35:22 +1100
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	If the RFC had wanted to allow for extra precision it would
  | 	have stated that the field should be rounded or truncated,
  | 	in words in the main part of the RFC.

Perhaps it should have done, but it doesn't.   I suspect that it is
impossible to determine what was "wanted" out of a doc that has been
through the WG process, when dealing with an issue that was simply forgotten
(sometimes it is clear from the WG discussions, and all that was missed
was transcription into the doc - that isn't what I believe happened here,
the whole issue was simply ignored by the WG until now).

  | 	The sample code has considerable flaws in it, it does not
  | 	reflect the intent of the main body of the RFC.  It will
  | 	handle valid input correctly.  Invalid input however is not
  | 	rejected and in many cases not detected.

What is the intent is incredibly unclear.   All it says about the master
file format is ...

       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)

for the relevant data.   The [ n .. m ] notation and its meaning is
defined nowhere.  From that, all that is reasonable is to conclude that
normal mathematical notation is used, which would imply any data in the
closed interval between (and including) 0 and (and including) 59.999 is
OK.   33.333333333 is certainly inside that interval.   One might perhaps
conclude that 59.9991 is illegal though.

The doc certainly doesn't say anywhere that excess digits are incorrect.

This is the kind of thing that implementation experience is supposed to
find - places where it is possible to read the docs in different ways.
Clearly this one is going to need to be updated before it can advance to DS.

Exactly how it should be updated should probably be debated when that
is about to happen.

kre

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Jan 2002 23:27:03 -0800

i want to clear up one thing.

> the whole issue was simply ignored by the WG until now).

LOC was never a WG product.  it can be made into one, and probably this
should be done so that it can advance, with appropriate editorial mods,
to DS.

but had LOC been a WG product, it would not have existed at all, because
frankly gentlemen, we would still be arguing about it.  (same for SRV.)

the platonic ideal of a WG product is something more like, say, DNSSEC.
or A6 and DNAME.  we'll use RSA!  no, we'll add ALG_ID.  no, we'll use
DSA!  we'll use nybbles-in-ascii!  no, we'll use binary labels!  no, we
really will use nybbles-in-ascii!

it's like the weather in portland, of whom the natives say, "if you don't
like it, just wait 20 minutes."

there's certainly no way IP, or TCP, or DNS, or SMTP, could ever have been
standardized had "WG's" existed way back when.  and neither could LOC, or
SRV.

so when discussing the history of LOC, please don't mis-dignify it with the
presumption that it went though a "WG process."  thankfully, and mercifully,
it did not, because the authors knew nothing of WG's at that time.

i've come to see the label, "experimental", as a badge of, well, progress.