[aprssig] APRS<=>E-mail

[Lynn W. Deffenbaugh (Mr)]

Actually, I would rely on the TCPIP as the path rather than trying to 
play catchup or guesswork on what client application they are using.  If 
their path is ONLY TCPIP* (excluding the qXX code and gate), then assume 
APRS-IS.  Otherwise, it is RF-limited.

Lynn (D) - KJ4ERJ

Gregory A. Carter wrote:
> Thanks for looking that up Lynn...
>
> So it may be possible to check to see if the user is actually online 
> at the time with messaging by looking at the destination address they 
> have set which would hopefully reveal what client they are using.  Of 
> course this would fail in the case of MIC_E packets but would 
> generally be useful for others.  If we couldn't detect what client 
> they were using then we're default to the RF limit.
>
> Greg
>
> NV6G
> OpenAPRS.Net
>
> On Mon, Jan 5, 2009 at 10:24 AM, Lynn W. Deffenbaugh (Mr) 
> <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>> wrote:
>
>      From the APRS101 spec approved 29 August 2000 under the NTS Radiogram
>     section:
>
>     Each line may be up 67 characters long, including the 3-character NTS
>     format identifier. Lines in excess of 67 characters will be truncated.
>
>     Also from the Messages, Bulletins, and Announcements section:
>
>     The message text may be up to 67 characters long, and may contain any
>     printable ASCII characters except |, ~ or {.
>
>      From the APRS-IS Specification:
>
>     All "packets" sent to APRS-IS must be in the TNC2 format
>     terminated by a
>     carriage return, line feed sequence. No line may exceed 512 bytes
>     including the CR/LF sequence.
>
>     And that 512 bytes INCLUDES the TNC2 monitor format "header"
>     information
>     (prior to the colon) of SENDER>DEST,PATH:rest of packet.  If I
>     remember
>     correctly, the AX.25 path can handle up to 8 hops and then an
>     IGate may
>     add a qXX and it's own callsign, and a callsign-ssid is 9 characters,
>     plus the commas means that the header maxes out at 120 bytes
>     (sender+dest+8*path+qXX+IGate) (actually 114 if we assume a 3, not 9,
>     character qXX code).  That would leave a maximum of 398 payload
>     characters per the APRS-IS spec.  Oh, but we have to allow for the 9
>     character message destination and an additional colon separator
>     plus the
>     ack at the end (assuming the e-mail forwarder is doing the
>     decaying send
>     until ack routine).  That'd leave us with 382 (10 for dest & colon
>     and 6
>     for {msgno per APRS spec).
>
>     Seems like 382 is the upper limit of message body for TCP/APRS-IS
>     packets and 67 is the defined spec limit for APRS over RF messages.
>
>     Lynn (D) - KJ4ERJ - Thankful for Jason's suggestion to check the
>     specs...
>
>     Jason KG4WSV wrote:
>     > On Mon, Jan 5, 2009 at 11:48 AM, Lynn W. Deffenbaugh (Mr)
>     > <ldeffenb at homeside.to <mailto:ldeffenb at homeside.to>> wrote:
>     >
>     >> To throw out numbers, I'd say 1K for non-RF users
>     >>
>     >
>     > gack!  Think maybe you should check the APRS-IS design first?  I
>     don't
>     > know the upper limit on packet size, but it would pay to check
>     it out.
>     >
>     > Think "APRS messages", not "small email".
>     >
>     > -Jason
>     > kg4wsv
>     >
>     > _______________________________________________
>     > aprssig mailing list
>     > aprssig at tapr.org <mailto:aprssig at tapr.org>
>     > https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>     >
>     >
>
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at tapr.org <mailto:aprssig at tapr.org>
>     https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>