[aprssig] spaces in object names

[Pete Loveall AE5PL Lists]

> -----Original Message-----
> From: Bob Bruninga
> Sent: Wednesday, August 12, 2009 6:10 PM
> 
> 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.

Only one question Bob: When the specification doesn't even HINT at embedded spaces as being disallowed, not intended, etc., why do you now want to promote ambiguity?

Let's look at that Object name definition again: "An Object Report has a fixed 9-character Object name, which may consist of any printable ASCII characters."  The first part says (paraphrased) that an Object name is -always- 9 characters.  The second part says that the characters -may- (bad choice of words, in my opinion) be any printable ASCII characters.  Further, in looking at the spec, the way you ensure 9 characters is by "padding" with spaces (an ASCII printable character and therefore proper "padding" according to the APRS spec).

I don't think anyone has a major issue with disregarding trailing spaces as most authors already assume that.  But if you start to post-spec throw ambiguity into the mix by saying "if you do this, the results may be ambiguous because somebody didn't write their software that way", you weaken the specification, not strengthen it.  How about the thousands of clients out there that disregarded the sentence "Object names are case-sensitive." because they assumed all 9 character names and callsigns must be upper case?

I guess what I am saying is that I recommend you be very judicious in what you disparage and what you encourage.  I would think you, of all people, would want to strengthen the APRS specification, not weaken it.

73,

Pete Loveall AE5PL
pete at ae5pl dot net