[aprssig] APRS and Unicode

[Kenneth Finnegan]

On Fri, Jan 6, 2017 at 9:41 AM, Robert Bruninga <bruninga at usna.edu> wrote:

> No, if you are talking about APRS "messaging", the TOCALL is a 9 byte fixed
> length field that can conatin alphanumeric in all 9 spots and mixed case.


Mixed case may be allowed, but APRS callsigns aren't case-sensitive. To
quote Pete (http://aprs-is.net/Connecting.aspx):

> RF and APRS-IS clients may convert lower or mixed case callsigns and SSIDs
> to upper case.


Lots of APRS code indiscriminately converts string to upper-case or makes
case-insensitive comparisons, so you don't have to restrict user entry to
only upper case, but you shouldn't make any case-sensitive comparisons, and
I'd suggest you convert any user-entered callsigns to upper-case as soon as
possible.

The APRS 1.0.1 spec does specify that objects are case sensitive (which I'm
not a fan of), but never made the same claim for callsigns.

My own notes on APRS callsigns (not restricted to AX.25) are as follows (
https://github.com/PhirePhly/aprs_notes/blob/master/callsigns.txt):

> Callsigns for APRS must:
>  * Consist of only upper case letters and numbers
>  * The base callsign (before the SSID) must be at least three characters
> long
>  * The base callsign must be no more than nine characters long
>  * The callsign in total must be no more than nine characters long
>  * Optionally include one hyphen with a 1-2 character alphanumeric SSID
> suffix
>  * The SSID may not start with '0'


In the context of messaging, this is space (0x20) padded to 9 bytes.

On Fri, Jan 6, 2017 at 9:41 AM, Robert Bruninga <bruninga at usna.edu> wrote:

> - In any other text, UTF-8 encoding should be used, and non-ASCII
> characters
> are permissible.
> - In the case of Unicode text, the length limitations in the APRS docs
> should be interpreted as characters rather than bytes (e.g. the message
> length specifically says ’67 characters’, not ’67 bytes’).
>
> AGREE, it is the displayed characters that were the limit.


This actually gets pretty sticky, as 67 UTF-8 characters don't necessarily
even fit in an AX.25 packet (67 characters may be as long as 268 bytes).
Starting with the 256 byte MTU for the information field, and subtracting
the message addressing and third party encapsulation which would be needed
for RF-gating, and I figure the hard limit for the contents of APRS
messages is 197 bytes. (256 - 42 third party overhead - 11 APRS message
destination - 6 message number) We've been doing some testing for this, and
confirmed that both aprsc and javAPRSSrvr correctly handle APRS messages
this long (with rather odd upper limits in the 400ish range)

My notes on the topic of packet size: https://github.com/PhirePhly/
aprs_notes/blob/master/APRS_MTU.md

So we're talking about trying to both enforce a 67 character and a 197 byte
limit on message length.

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170106/05636d7f/attachment.html>