[aprssig] aprsd drops mic-e characters

[Tapio Sokura]

Bill Diaz wrote:
>>I guess it wasn't fixed then, at least 2.2.5-13 contains it 

> It was fixed at one point, in some distributions.  Some of the older

I meant the aprsd at sourceforge, just to be clear.

>>vague on what are and what are not valid characters. It says in many 
>>places that "printable ASCII" is good, but what is printable ASCII? 
>>Usually it means characters of decimal value between 32-126, possibly 
>>including 127. But characters above 127 are not normally considered to 
>>be ASCII.

> Many european languages use 8 bit characters and consider them to be
> printable.  Users may incorporate 8 bit characters for other perfectly valid

Yes, but they are not ASCII. For example, a direct quote from APRS 1.0.1 
specification says "An Object Report has a fixed 9-character Object 
name, which may consist of any printable ASCII characters." And the 
glossary at the end describes ASCII as being a 7-bit code. And so do the 
documents that actually specify ASCII, I believe.

> reasons.  We discussed this long ago on this SIG and reached a consenus that
> applications should not modifiy the payload.  There is simply no rational
> reason for an application to intentionally mangle packets.

There are good reasons for using many characters in many protocols, but 
allowing data that contains invalid characters (according to the 
specification of the protocol) to pass onto the network is not good 
behavior. Granted, filtering some characters out of the packet can and 
will cause duplicates, so I guess the best option is to not pass invalid 
packets at all so there is no duplication.

> There is no ambiguity on where an APRS IS packet begins and ends.  Packets
> are terminated with CR or CR/LF.  If the character following a CR or LF is >
> chr(32), it is likely the start of a new packet.  The header generally

Likely? As you well know, computers don't have a likely-bit or maybe-bit 
or whatever you want to call it. Neither should specifications that deal 
with computers have incertainities like this one.

> should not contain 8 bit char, or control char, whereas the payload can
> contain both.

So if I receive an AX.25 packet that first has some data in the 
information field, then a CR/LF, then contains data that just happens to 
look like an APRS-IS header and then more data.. how does this fit into 
the APRS-IS ?  I bet that just about all software handling the APRS-IS 
stream will think this is two packets in a row and thus in essence 
modify the payload. I bet many applications accessing APRS-IS won't 
correctly handle bytes in the stream that are zero, for example. But as 
the APRS spec says, 7-bit binary data is fine in user-defined packets 
for example, so I guess they should be passed on then.

> You should not, modify any char in the payload.  Please think about the
> effect on the APRS-IS and client applications worldwide before you
> unilaterily decide to "improve" APRS.  

I think APRS(-IS) has been "improved" to the point it currently stands 
very well even without my input. And this is not a compliment.

>>I need is a clear and unambiguous specification on what 
>>characters/packets to pass and what not to pass. The "pass everything" 
>>just doesn't work in APRS-IS without a clearly defined protocol that 
>>somehow embeds or escapes the "bad" characters. 

> Escaping what you consider to be "bad" characters is a bad practice since
> the originator may have had a valid reason for using them.  Simply put, do
> not edit the payload of ANY packet you may relay.  

Naturally I can't escape those bad characters now, because there is no 
mechanism in the APRS-IS to escape characters (or vice versa, delimit 
packets without the delimiters being escaped in the data). Of course you 
can just ignore the fact that packets can be constructed that fit the 
APRS spec and after being used on the air, the packet will be broken 
when it makes it to the APRS-IS. It doesn't matter what software is 
doing the igating, it will break those packets because APRS-IS is not an 
8-bit (or should I say, 7-bit) clean packet transfer medium.

   Tapio