[aprssig] spaces in object names

[Steve Dimse]

The issue is not which side is right. Wikipedia says it is not. The  
fact is, it is debatable. If you want to debate it with someone else,  
feel free.

The issue is this ambiguity creates a problem with the use of APRS,  
and it needs to be resolved. If we had been aware of this ambiguity it  
would have been clarified in spec 1.0. Instead, it is clarified in  
1.2. But it is clarified.

If someone were in court being charged with "Delivery of illegal  
packets" I absolutely agree that they should be acquitted. We are not  
running a trial, I am not blaming anyone for doing this, it is just a  
different interpretation of an unexpectedly ambiguous phrase. Time to  
clarify and move on.

The original intent was that spaces should not be embedded in objects,  
and that has now been mabe explicit.

Steve K4HG


On Aug 12, 2009, at 5:16 PM, Lynn W. Deffenbaugh (Mr) wrote:

> According to the Watcom C runtime library function isprint(), "Space  
> is printable".
>
> Lynn (D) - KJ4ERJ
>
> PS.  Simple program to ask...
>
> #include <ctype.h>
> #include <stdio.h>
>
> int main(void)
> {
>   printf("Space is %s\n", isprint(' ')?"printable":"NOT printable");
>   return isprint(' ');
> }
>
>
> Steve Dimse wrote:
>> It has recently come to my attention that DStar objects are being  
>> sent to APRS with an embedded space in the object name (like "K4HG  
>> A"). The APRS spec states that objects names can be any printable  
>> character. As it turned out this is a poor choice of words.  
>> Surprisingly to me, whether space is printable is debatable. When I  
>> searched Google, the first entry (wikipedia) and some others very  
>> clearly state it is not a printable character. Other pages state it  
>> is a printable character. This sort of ambiguity is obviously not  
>> desirable in the spec document.
>>
>> It never occurred to me to consider it printable, so my parser  
>> removed all spaces as a lazy way to get rid of trailing spaces.  
>> This obvious broke with these objects, the object "K4HG A   "  
>> became "K4HGA". This was obviously a bug, and I've corrected it to  
>> match my interpretation of the spec, namely object "K4HG A   " is  
>> invalid. I continue to remove trailing spaces.
>>
>> The problem is readability. If you do not remove trailing spaces,  
>> there can be six different entities on map that print as "K4HG",  
>> distinguished on whether they have zero to five spaces after my  
>> callsign. This is a problem for the tactical use of APRS. The same  
>> argument applies to embedded spaces, where the number of spaces can  
>> be difficult to judge with a proportional font.
>>
>> I've discussed this with Bob and he agrees, and will be making this  
>> clarification on the spec addendum page. In looking over the log  
>> for the last couple hours, I only see DStar objects with embedded  
>> spaces, so there should not be any problems to other users from  
>> this clarification.
>>
>> Those sending DStar objects, the easiest change to make would be to  
>> simply replace the embedded space with a dash, so K4HG A becomes  
>> K4HG-A.
>>
>> Steve K4HG
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>