[aprssig] spaces in object names

[Mark Cheavens]

Sorry I am a few HOURS late in this discussion and still have about 
10 emails in the chain to digest, but let me throw out my concerns.

My concern is not how the APRS IS handles these, but rather will the 
existing hardware based devices: Namely TNC's with different versions 
of software handle them?

Most of the authors of the clients and all of the IS backbone are on 
this discussion and should be able to resolve the issues within their 
respective software. (Notable exception to the client side is Roger 
Barker SK). Since MANY users use his software that cannot be changed 
and there are hardware based systems including the KPC-3 and D-700 
that will NEVER get changed, we must look at if the packets will flow 
THROUGH them.

(And I won't bother to chime in on whether I think it is printable or not!)

Just my .02 worth.

Mark Cheavens
KC5EVE

At 06:09 PM 8/12/2009, you wrote:
>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
>
>_______________________________________________
>aprssig mailing list
>aprssig at tapr.org
>https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig