[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-costanzo-dns-gl-00.txt



[ On Saturday, July 31, 1999 at 12:24:44 (-0500), Al Costanzo wrote: ]
> Subject: RE: draft-costanzo-dns-gl-00.txt
>
> Greg, does it really do a better job?  Is it more precise?

It is as precise or imprecise as the publisher wishes it to be!  ;-)
 
> Please tell me how to use LOC to define foobar.nasa.gov which is located on
> the new multinational space station in orbit around the earth?
> 
> I have been told it cannot be done with LOC.

According to my reading of RFC 1876 it's possible to describe any
geo-synchronous body at any altitude up to 42849672.95 meters (though I
suspect orbital mechanics rule out quite a bit of that range!  ;-).

LOC RRs obviously cannot precisely locate any mobile object, be it
moving over the surface of the Earth, under the oceans, or above in an
aircraft or spacecraft; at least not in their current form.  Indeed
defining the exact position of a mobile object in a semi-static database
seem to be somewhat of an oxymoron (though I realize that even a
non-geo-synchronous orbit is perhaps somewhat of a special case).

However as Mr. Elz points out there's no problem with using LOC RRs to
define a large enough sphere to encompass the potential movements of
anything directly related in any way to the Earth (though my knowledge
of this stuff is somewhat limited and I'm not entirely sure that the
maximum sphere is large enough to cover the space station's orbit).

Lastly I think it's important to note that LOC RRs include a version
number, and that's all that's necessary to properly extend them to
specify any additional co-ordinates necessary to pinpoint a network
device on any orbiting satellite or spacecraft, or indeed on or near the
surface of any body in the Solar System or beyond.  One could even tag a
mobile device that's able to report its current position through some
secondary protocol.  One could even reserve a version number to specify
a form of the record that includes arbitrary data such as a postal
address.

> GL can do it in a snap. SO how is LOC 'far superior'  or does it just appear
> to be better because you have to do alot more work to use it :-)

I'm not necessarily opposed to the proposed GL RR, but I don't really
see how it'll solve any problem not already solved by LOC RRs, including
their usability.  Ultimately LOC RRs seem far more flexible to me and
thus far more useful.

BTW, I think your definition of "usability" is slightly backwards.  You
seem to be trying to aim more towards a format that's easy to publish,
but not necessarily easy to use.  LOC RRs, while not trivial to use, are
(I think) much easier to use from a computer programming point of view.

Indeed I don't see any hassle with "using" LOC RRs from the point of
view of publishing them these days either, what with nearly every
hardware, electronics, and outdoor-sportsman store in at least all of
North America selling inexpensive hand-held GPS receivers!  ;-)  I'd be
willing to bet a beer that every hostmaster in North America knows at
least one person who either owns a GPS receiver, or knows someone who
does.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>