[aprssig] Mic-E format issues

[Robert Bruninga]

>> For network integrity, each [Mic-E] design needs 
>> to have its own identifier.  
> 
> I disagree - I couldn't care less whether I'm 
> transmitting to a D-7, a D-700, a D-710, an 
> OpenTrak, etc, and I certainly couldn't 
> tell you what the "quirks" of each are. 

But those who are responsible for proper operation of the
network probably should...

> Can we focus on capabilities?  If someone makes 
> a radio that has *exactly* the same capabilities 
> as a D-700, why should it need a new  ID? 

Because it seems in the computer world that different source
"software" is never, ever *exactly* the same.

> ...we need a way of expressing *capability* in a 
> way that people can understand, not just expressing 
> what model radio...

There are too many capabilities to keep track of that way. The
current APRS capabilities chart contains over 200 "capabilities"
and even if there was only a Y/N binary response for each, that
would take probably an 18 byte field to express.  It is much
easier just to identify the product in the one byte set aside
for that purpose.  See the current chart:
http://www.eskimo.com/~archer/aprs_capabilities.html#table1

> (Quick: Does SmartPalm - APZPAD - display objects?

It is easier to go to the SmartPalm web page and look it up
there, without having to encumber every packet with 18 bytes of
capabilities...

> We need to identify which capabilities are useful 
> to know, and figure out a way of making that easy 
> to remember, without having to remember  
> what every type of APRS device can and can't do.

But noone can remember it all, even if we make it "easy to
remember".  That is why we have the above capabilities web
page...  Then all we have to do is have the one-byte identifier
as to the product.

I have added a Mic-E TYPE file to the APRS1.2 addendum web page:

http://www.ew.usna.edu/~bruninga/aprs/mic-e-types.txt

Hope that helps.

Bob, WB4APR