[aprssig] spaces in object names

[Bob Bruninga]

Well, hummh...

When I wrote "printible ascii" I was using no other definition other than that it was something that put INK on paper or it changed PIXels on a display".  Just to avoid this kind of ambiguities and errors and problems from the beginning.

But now we see that "printible ASCII" actualy does include the SPACE by rigid definition.

But the INTENT of the original design of APRS was that embedded spaces would not be used.  ANd the intent of the 9 byte FIXED length object field was not to preserve trailing spaces, but to allow for fixed field parsing. THe trailing spaces were assumed to be ignored in all comparisions which would be left justified.

So, dispite the formal definition of "printible ASCII" to include the SPACE character in the formal definition of ASCII, it was the intent of APRS not to inculde embedded spaces in callsigns or object names.

I do not say that includign them is *wrong* or that you cannot display them if you find them, but that including them will yield ambiguous and inconsistent results and should be avoided simply for this reason.

I am going to add the statement in the APRS1.2 addendum to clarify this situation that embedded spaces were not intended nor should be included in callsigns or object names if consistent performance is expected.

or something like that.
Bob, WB4APR

Bob, WB4APR


---- Original message ----
>Date: Wed, 12 Aug 2009 17:11:04 -0500
>From: aprssig-bounces at tapr.org (on behalf of Pete Loveall AE5PL Lists <hamlists at ametx.com>)
>Subject: Re: [aprssig] spaces in object names  
>To: TAPR APRS Mailing List <aprssig at tapr.org>
>
>Steve, time to put your dependence on Wikipedia to bed.  Go to http://nemesis.lonestar.org/reference/telecom/codes/ascii.html and -read- the ANSI definition of the ASCII character set which has been in place since 1968.  There is no ambiguity.  The space character is part of the "Basic Printable" character set; specifically it is considered to be a part of the "Symbols and Punctuation" subset.  Since the APRS spec says "An Object Report has a fixed 9-character Object name, which may consist of any printable ASCII characters.", the space character is included in that statement.  Period.  The objects that are generated for the D-STAR repeaters are not invalid in any sense of the word.
>
>BTW, the APRS spec also says "Object names are case-sensitive." but a number of authors ignored that too.  It doesn't make it wrong, just that some people read the spec a little closer than others.
>
>As to trimming trailing spaces for readability, I fully understand and tend to agree with you and Bob that, for display purposes, trimming trailing spaces is worthwhile.  However, if we are to hold to the spec, we really shouldn't do that either.  I think most authors do trim trailing spaces from Object names and Item names.  Because of this last statement, I tend to say that it is the -de facto standard- to disregard -trailing- spaces in an Item or Object name.
>
>73,
>
>Pete Loveall AE5PL
>pete at ae5pl dot net
>
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig