[aprssig] [RFC] Power Source Data Extension

[Jason KG4WSV]

On Sun, Feb 12, 2017 at 2:59 PM, Kenneth Finnegan <
kennethfinnegan2007 at gmail.com> wrote:

> What extensibility is it lacking? New power sources?
>

Probably not an issue, but you have limited any extensions to the remaining
uppercase letters without a complete rewrite and introduction of backwards
incompatibility.


> Reduction in readability compared to what?
>

As opposed to _not_ having a space (or comma in the case of station
capabilities) and having it jammed against the next chunk of data, be it
comment or some other comment/status-legal data.  I'm a big fan of having
packets human readable where practical, and our brains are trained to use
space as a "word" delimiter.


> All fields should be start with either the appropriate APRS data type
>> identifier or field separator and end with either a field separator or the
>> end of packet.
>>
>
> So if a station capability parser encounters ",PWR=SB&," what should the
> parser do with the ampersand?
>

Unless there's more uses of & than I see after a quick perusal of the spec,
I'd probably ignore it, possibly along with the entire field. The
capability spec seems to clearly intend for a comma to be the field
separator, so i'd all it an illegal field since it includes & before the ,
and & is not in the field spec you're proposing.  Or did I miss something?


> It seems like you're talking about the tokenizer, which I wasn't talking
> about. I'm only talking about how to parse this field.
>

I really don't see how you can differentiate the two problems too much,
since you need to know when the field stops so you can stop parsing it.
The spec doesn't provide much help with this sort of question, so default
to space.


> Tokenizing APRS packets is a kettle of fish I want nothing to do with,
> because I don't think you can depend on everyone using field separators in
> comment fields.
>

you can at least not make it worse and build tokenizability (is that a
word?) in to _this_ field...


>  For status packets and comment fields the field separator is (or should
> be) a space.
>
> It should be, but I think I've seen Bob recommend / as well.
>

Ugh.  well, it isn't in the spec, except i the specific instance of
altitude in comment.


> Where's the most relevant documentation on data extension field separators
> these days?
>

A quick perusal of the 101 spec doesn't show "data extension field" as a
thing.  There are "APRS Data Extensions" (ch 5) which are fixed length 7
byte fields in a fixed location.  /A=xxxxxx altitude us referred to as
"Altitude in Comment Text" which is a fixed 9 byte wide field and "may
occur anywhere in the comment".

So maybe we need to define a "data extension field"?


Sheesh, I sound like i'm arguing, even to myself, but i'm not really.  I
just think whitespace around it would be a good idea.

-Jason
kg4wsv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170212/1c25cfbb/attachment.html>