From: <zealots-admin@shmoo.com>
Date: Sat, 17 Mar 2001 12:00:02 -0900 (AKST)
Message-Id: <200103172100.MAA50698@archimedes.shmoo.com>
Subject: Zealots digest, Vol 1 #5 - 2 msgs
Reply-to: zealots@shmoo.com
Mime-version: 1.0
Content-type: text/plain
To: zealots@shmoo.com
Sender: zealots-admin@shmoo.com
Errors-To: zealots-admin@shmoo.com
Precedence: bulk


Send Zealots mailing list submissions to
	zealots@shmoo.com

To subscribe or unsubscribe via the web, visit
	http://www.shmoo.com/mailman/listinfo/zealots
or, via email, send a message with subject or body 'help' to
	zealots-request@shmoo.com
You can reach the person managing the list at
	zealots-admin@shmoo.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Zealots digest..."


Today's Topics:

  1. Re: Making lists of points (W Lewis)
  2. Re: Making lists of points (W Lewis)

--__--__--

Message: 1
Date: Fri, 16 Mar 2001 15:29:13 -0800 (PST)
From: W Lewis <wiml@hhhh.org>
To: <jpugh@jpugh.org>
cc: <zealots@shmoo.com>
Subject: Re: [Zealots] Making lists of points

On Thu, 15 Mar 2001 jpugh@jpugh.org wrote:
> Why not use a directory. This type of data is exactly what a directory was
> built to hold.
>
> Novell's NDS eDirectory is already setup for such a task. Many ways to write
> to the directory with the proper permissions and even more ways to read and
> search it. eDirectory has the flexibility to allow you to create nearly any
> type of field and poplulate it with any type of data.

Well, I'm not looking for a way to store the data; I already have a
Postgres backend that meets my needs. I'm looking for a way to exchange
the data with other people, who presumably have their own internal
representations different from mine.

(NDS itself looks a tad Windows-specific, but LDAP might be a good way to
provide access to point databases, if/when something that complex is
needed --- interesting idea.)

Wim.


--__--__--

Message: 2
Date: Fri, 16 Mar 2001 16:44:27 -0800 (PST)
From: W Lewis <wiml@hhhh.org>
To: B Potter <gdead@shmoo.com>
cc: <zealots@shmoo.com>
Subject: Re: [Zealots] Making lists of points

On Fri, 16 Mar 2001, B Potter wrote:
> When you say "machine parsable" address, what do you mean?  like a street
> address?  ie: 1234 anywhere St.?

Yup. Something not completely free-form. The exact restrictions are not
important, as long as it's rigid enough that a program can pick it apart
reliably. Perhaps the field could contain either "1234 Somewhere St."
or (intersection of) "Somewhere St. and Anywhere Pl.". Either of these can
be looked up in a database and converted to lat/long.

I think a more free-form field should also be available, so that people
can enter "Bucknell University Library" or (an example local to me)
"Sea-Tac airport". But it should be distinguished from the parsable field
somehow.

If we wanted to be fancy, we could include an indication of data quality.
There are three fields here (general location, specific address, and
lat/long) which specify the point's location. Presumably one of them is
original, and the others, if they exist, are derived from it. Perhaps a
point is originally entered as "near the foot of Foo Hill". Someone enters
an address near the foot of Foo Hill in order to get the point to show up
on a diagram, but that address (and lat/long) are overly precise, and
therefore misleading. Marking them as having been derived from the
less-precise field would be good. But for another point, I may have a
precise lat/long from GPS, and I may enter "near the foot of Foo Hill" to
give people an idea of where that lat/long is; in this case, it's the
lat/long that's authoritative and the fuzzy location that's just
informative.

Another tack might be RFC1876-style "precision" fields for the lat/long,
but it seems to me this doesn't solve the whole problem.

Anyway, all the above is probably more complex than is wise for a
first-cut format, but I think it is good to keep this stuff in mind.

> It would be great if we could setup a format that fits your needs, GAWD's
> needs, and anyone elses.  I don't think the comments need to be included
> in the format,

I think a general comments/description field would be useful, but
including GAWD's arbitrary-number-of-comments-added-by-random-people in
the interchange format is unncessary, I agree.

> and I"m not sure if the the "public" feild is all that useful.

Would it be implied by the "provider" field then, or do you think it just
isn't a useful piece of information?

> city *
> state or prov (if applicable)
> country (ISO code) *
> postal code

This is most of a parsed street address, fwiw --- it's just missing the
street-name and house number.

> location (a fuzzy address) *

> lat and long (in decimal)

I think it would be good to accept the D-M-S format also, since my thought
is that some people will be producing point lists in a text editor.

> date added to system

How about a "date last verified"? APs, especially unofficial ones,
presumably move around a bit.

> encryption (type)
> auth keys
> protocol (802.11, etc) *
> provider
> picture URL
> contact name
> contact URL
> MAC address

I don't have any way of displaying these on a map (yet), so I don't care
about them (yet) :-) Although the "protocol" is explicitly unecessary in
my application, since some people will be keeping track of proposed or
potential sites, not just operational APs.

To add my own interests, there are the fields:
   non-fuzzy address field (optional)
   short name or label (required currently, could be optional)
   brief commentary/description (this could be combined with the
                        fuzzy location field, but I think it'd be better
                        to keep them separate)

Counting these up, I see 17 to 19 fields, plus any "derived" flags etc.
which might be needed. That's a lot ... perhaps some fields could be
combined, for example, the encryption type and encryption keys could be
specified in the same field.

As an aside, have you thought about having GAWD keep track of the IP side
of access points, if any --- their IP address, what they route to (nearest
ISP or corporate intranet), firewall or NAT policies, etc.?

> we were thinking of "non-verified" XML.  ie: there would be no DTD, just a
> specification of sorts.  There are several perl (and other) libraries to
> handle this sort of set-up.  They work pretty well, and are pretty easy to
> rip together.

Hmm, if the libraries are fairly lightweight, I may reconsider my anti-XML
stance. :-) But in general, XML comes with a lot of extra baggage
(entities, namespaces, finicky syntactical edge cases, etc.) which, in my
experience, leads to a bloated parser if you really want to support XML.

Alternatively, I could define a simple format which has a subset of these
fields and simpler syntax; for the full format, XML would be used. If the
fields have the same meanings then automatic translation for import/export
is easy. By a simple syntax I mean something like this:

Lat/Long: 122 13 48.87 W 44 18 00 N
Contact: Bob Jones <bjones@blahblahblah.blah>
Comment: 65th floor of office tower
Name: bob

Location: near the abandoned mine
Address: 1447 E Haunted St.
Contact: Old Man Withers <withers@aol.com>
Comment: would be encrypted if not for those damn kids
Name: mine1

Very easy for a human or a computer to parse or generate, good for simple
data, but awkward for complex structures.

Wim.


--__--__--

_______________________________________________
Zealots mailing list
Zealots@shmoo.com
http://www.shmoo.com/mailman/listinfo/zealots


End of Zealots Digest