[aprssig] IGate wildcards/Telpac data

[Bill Diaz]

Bob,
  See below:

>-----Original Message-----
>From: aprssig-bounces at lists.tapr.org 
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Robert Bruninga
>Sent: Tuesday, February 15, 2005 10:29
>To: jj at aprsworld.net; steve at dimse.com
>Cc: aprssig at lists.tapr.org
>Subject: Re: [aprssig] IGate wildcards/Telpac data

>
>No, NO, NO.

>The callsign field in APRS is and always has been 9
>bytes.  Also there always was a minimum requirement 
>of at least 3 bytes.  (im not sure if the 3 byte minimum
>got into the spec or not).

>Thus WL-CCCCCC is a violation since it makes for a
>two byte call and a 6 byte SSID.  But CCCCCC-WL
>is just fine.  Such a callsign cannot be "originated"
>by a raw TNC, but that is a limitation of the TNC,
>not a limitation of the APRS SPEC.  THus a received
>callsign field of 9 bytes is OK as an object, or as a
>3rd party format, or an item, or any of the many other
>APRS formats with that 9 byte field.

I agree WL-CCCCCCC is a bad idea.  

IMO, any construct which causes any APRS application to fail is unacceptable
and should be rejected.  I am not a fan of non-numeric SSID's or other
constructs which violate the AX.25 spec.  Many of these were adopted on
whims of individual developers or are permitted by applications which do not
check to ensure user entered information conforms to AX.25 and APRS specs.

Callsigns exceeding 9 characters or inserting a hypen before the end of the
call will surely result in problems with some applications. A viable and
workable solution would be one which does not require changes to any server
or client software.  

Our existing APRS spec is terribly convoluted. It is now extremely difficult
for new developers to write workable APRS spec compliant code. Lets not
aggravate the situation by adopting yet another construct not presently
supported.


Bill KC9XG

>But I do agree with Steve on FINDU or other applications
>of gaiting to RF where the ability to wildcard a callsign
>exists, that maybe that something is only considered an
>SSID if it is 2 bytes long and at the end.  That is why
>I like the CCCCCC-WL option...


>de WB4APR, Bob

>
>>>> steve at dimse.com 2/15/05 9:29:17 AM >>>
>On 2/15/05 at 8:06 AM James Jefferson Jarvis <jj at aprsworld.net> sent:

>>Are you talking about allowing callsign-ssid to be an arbitrary
>length? 

>>If so, then I object based on the fact that aprsworld and anything
>that uses 
>>it is expecting callsign-ssid to be at most 9 characters. IIRC the
>APRS 
>>internet stream was supposed to look like AEA or TNC2 packets. Both of
>those 
>>would only present at most 9 characters for callsign-SSID, so that's
>what I 
>>went with 5 years ago.

>This specific issue could be addressed by not using any other SSID, so
>even 6
>letter calls fit in 9 chars (findU uses 10 chars). E.G. WL-WZ9ZZZ, and
>using the
>true SSID only in the object.

>Still, the precedent will be set, and there is no reason to limit
>callsigns to 9
>characters, so I'm sure someone will want to use more in the future...

>Steve K4HG