Subject: requesting change of status for RFC 1876

From: Paul A Vixie <[email-masked]>
Date: Sun, 29 Nov 1998 15:36:05 -0800

from experimental to proposed standard

---

From: Christian Kuhtz <[email-masked]>
Date: Sun, 29 Nov 1998 21:38:03 -0500

I support Paul's motion.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 29 Nov 1998 23:40:05 -0500

Sounds reasonable to me.

Donald

From:  Paul A Vixie <[email-masked]>
X-Authentication-Warning:  opsmail.internic.net: majordom set sender to owner-namedro
[email-masked] using -f
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7bit
Message-Id:  <[email-masked]>
To:  [email-masked]
Date:  Sun, 29 Nov 1998 15:36:05 -0800
Sender:  [email-masked]
Precedence:  bulk

---

From: [email-masked]
Date: Mon, 30 Nov 1998 08:40:08 -0800 (PST)

> from experimental to proposed standard

I'll add another affirmative hum to this request w/ a minor
editiorial nit.  Please change the numbers/names from 
ones that might be used at ISI.  There are numbers and domain lables
that are explicitly for documentation use.

-- 
--bill

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 30 Nov 1998 10:24:57 -0600

I can't comment on the appropriateness of the requested change in
status, but if it does take place, I suggest a few editorial changes:

"sane" -> "same"	in VERT PRE description

insert "unsigned"	in description of LATTITUDE and LONGITUDE
			fields

fix unbalanced nested parentheses
			in ALTITUDE description

Clean up descriptions of HORIZ PRE and VERT PRE.  In particular,
"total potential vertical error" is meaningless to me.  Noting that
the error in a location measurement is more generally expressed as an
ellipse than a circle, I suggest:

HORIZ PRE    The circular horizontal precision of the data, in
             centimeters, expressed using the same representation as
             SIZE.  This is the diameter of the horizontal "circle of
             probable error", rather than the radius.  (This was chosen
             to match the interpretation of SIZE; to get a "plus or
             minus" value, divide by 2.)

VERT PRE     The vertical precision of the data, in centimeters,
             expressed using the same representation as for SIZE.  This
             is the total length of the error bar, rather than a "plus
             or minus" value.  (This was chosen to match the
             interpretation of SIZE; to get a "plus or minus" value,
             divide by 2.)  Note that if altitude above or below sea
             level is used, the precision value should include the
             uncertainty in sea level relative to the [WGS 84]
             ellipsoid.

Specify how siz, hp, vp are to be converted to the wire format when the
value in the zone file cannot be represented exactly, or declare that
such a case is an error.  Possibly make the "sample" routine in the
appendix the reference, although I think it would then need to be
tightened up to check for numeric overflow due to too-long decimal
strings.
				Matt