[aprssig] State Abbreviations for SSn-N rouiting...

[Scott Miller]

Yet.  Don't forget who we've got in the White House.  ;]

Seriously... ISO 3166-1 and 3166-2 give you country codes and subdivisions
for every country out there.  I think the combination of those is at most
five bytes, without the '-' separator  (e.g., AUNS = Australia - New South
Wales, DESH = Germany - Schleswig-Holstein, USCA = United States,
California).  Wikipedia has a lot of them listed.

Now, I'm not saying that using these is a good idea, or the way that APRS
should be set up everywhere.  It's just an established, consistent way of
identifying countries and their top-level administrative subdivisions
(states, provinces, cantons, etc.)

Scott
N1VG

----- Original Message ----- 
From: "Andrew Rich" <vk4tec at tech-software.net>
To: "TAPR APRS Mailing List" <aprssig at lists.tapr.org>;
<tim_cunningham at mindspring.com>
Sent: Thursday, February 17, 2005 11:56 AM
Subject: RE: [aprssig] State Abbreviations for SSn-N rouiting...


> The USA is not the only country !
>
>
>
> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu]
> Sent: Friday, 18 February 2005 04:17
> To: tim_cunningham at mindspring.com
> Cc: aprssig at lists.tapr.org
> Subject: [aprssig] State Abbreviations for SSn-N rouiting...
>
>
> Tim,
>
> There is no need to limit it to two bytes.
> ALA is just fine.  It can be WVA or
> FLA.  Doesnt matter,  Just whatever
> the state wants to use...  I only used SSn-N
> in my docs as a convenience...
>
> It does not make the packet any bigger, since
> its a fixed 7 byte field anyway...
>
> So, no, if you already  have ALA in place,
> please leave it.  But if new states do stick with the
> 2 byte version of SSn-N then it will be easiler
> for visitors to "guess" correctly without having
> to look first...
>
> thanks
>
> Bob
>
>
> >>> "Tim Cunningham" <tim_cunningham at mindspring.com> 2/17/05 10:07:03
> AM >>>
> Bob,
>
> I do not see that behavior with UIDIGI on this end. We have
> 7 of them in earshot of each other here with no other types
> to mess up the process. I do not see that behavior here in a
> pure UIDIGI environment.
>
> Our challenge has been dealing with the new paradigm SSn-n
> changes. A few years ago when we did this we used ALA
> for the UIFLOOD call and moved WIDE to the UITRACE call.
> I had initially started to use AL and you suggested ALA. So, we
> went with ALA. As you can tell where I am going with this
> dialog it has added some complication to make the change since
> everybody who used ALAn-n burned their EPROM's, PIC's,
> and weather stations with ALAn-n. Now the SSn-n suggesting
> we use AL is a problem. We will deal with that one when we
> see the cost impact for the users that adopted ALAn-n.
>
>
> 73's
>
> Tim - N8DEU
>
>
>
>
> ----- Original Message ----- 
> From: "Robert Bruninga" <bruninga at usna.edu>
> To: <aprssig at lists.tapr.org>
> Sent: Thursday, February 17, 2005 11:43 AM
> Subject: [aprssig] UIDIGI ROM TESTING NEEDED:
>
>
> > Whats with the UIDIG ROM?
> >
> > I sent out a TRACE2-2 packet  and the W3GXT-2
> > digi using UUIDIGI ROM digipeated it 3 times from
> > each of the other 3 digis that heard the original..
> > It did NOT do dupe elimination as it should...
> >
> > Is this a fault of the UIDIGI firmware, or is this a local
> > setting that is incorrect?
> >
> > de Wb4APR, Bob
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>