[aprssig] aprsd drops mic-e characters

[Bill Diaz]

Tapio,
  See below:

>-----Original Message-----
>From: aprssig-bounces at lists.tapr.org 
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Tapio Sokura
>Sent: Saturday, May 07, 2005 12:43
>To: TAPR APRS Mailing List
>Subject: Re: [aprssig] aprsd drops mic-e characters
>

>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.

Just because something is posted at sourceforge does not guarantee it is
correct.  Obviously, the version you are modifying contains code that may
have been obsoleted a long time ago.  

>>>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.

You are only quoting a reference to object names and yes they are expected
to constructed of ASCII characters.  There is no such reference to data in
all payloads.

>> 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.

Your intereptation is flawed.  You are unilaterally deciding what characters
are valid and what is not.  I suggest you spend some time reviewing the
APRSSig and APRSSpec archives.  Then you may be in a better position to
judge what is generally considered to be proper behavior both on RF and on
the APRS-IS. 

>> 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.

Obviously you are not interested in determining how a packet is delimited or
constructed, you would rather tell everyone how it SHOULD, in your opinion
be constructed.  FYI, the FromCall can be up to 9 printable ASCII
characters.  This does not include spaces, or control characters, therefore
a char following a delimiter must be > chr(32) to be considered part of the
next packet.  If it is not, it should be rejected.  For example, you may
encounter a LF, which is not part of the next packet but is part of the
previous packet.  Since most packets are terminated with CR rather than CR
and LF, you would simply throw away any char following a CR which is < 32.
if an application sends extra delimiters, they should be removed. Pretty
basic logic.

>> 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. 

All working APRS software can detect a packet delimiter by constructing a
string consisting of all characters up to the delimiter.  Anything that
follows is NOT part of the packet of interest.

Once you encounter a CR or CR/LF, it is the end of the packet.  What follows
may, indeed by another packet.  To repeat once again, APRS-IS packets
terminate with a CR or CR/LF.  Anything that follows is likely not related
to the previous packet. 

>I bet many applications accessing APRS-IS won't 
>correctly handle bytes in the stream that are zero, for 
>example. 

How many APRS applications can you name that cannot correctly handle a nul
char?  

>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.

FWIW, you need to understand how APRS packets are constructed before you
attempt to criticize what has evolved over the years.  We have a workable
system that was developed by many talented, dedicated individuals who worked
for years to bring us to where we are today.  There were many disagreements
and arguments that were resolved after much debate.  

If you are not happy with what is presently available, you are free to
design your own "improved" system, but please do not pollute the existing
APRS-IS or locally recognized APRS channels with mangled or eliminating
packet constructs that you do not approve of.  Be interesting to see how
many APRS users who would use such a system.

>>>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.

It is not clean because of defective software (such as your "improvements"
to aprsd) or improperly setup TNC's.  Please don't make it worse with ill
considered "improvements".

If you no not pass an RF packet you consider to be broken, no one will
criticize you.  If you intentionally modify the contents of any payload that
is another matter entirely.  

Bill KC9XG

>   Tapio
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>