[aprssig] OT - trying to locate N3DXC

[Dixon, Tim]

Hello,
I'm sorry to have to post this here, but have reason to believe that you
all could help.  I'm trying to locate a valid way of contacting Brad
Baker, N3DXC.  I've tried both published email addresses from qrz.com
and eham.  I need an email address, telephone number, whatever, but
email me privately, please.  There's no need to tie up the list with
this any further.

Many thanks!

/tim
KG4MIQ

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

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

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