<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 12, 2017 at 2:59 PM, Kenneth Finnegan <span dir="ltr"><<a href="mailto:kennethfinnegan2007@gmail.com" target="_blank">kennethfinnegan2007@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>What extensibility is it lacking? New power sources?</div></blockquote><div><br></div><div>Probably not an issue, but you have limited any extensions to the remaining uppercase letters without a complete rewrite and introduction of backwards incompatibility.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Reduction in readability compared to what?</div><span class=""><div></div></span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="m_4265331239923365516gmail-"><div class="gmail_quote">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.  </div></span></div></div></blockquote><div><br></div></span><div>So if a station capability parser encounters ",PWR=SB&," what should the parser do with the ampersand? </div></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div></blockquote><div><br></div><div>you can at least not make it worse and build tokenizability (is that a word?) in to _this_ field...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div> For status packets and comment fields the field separator is (or should be) a space. </div><div><br></div></span><div>It should be, but I think I've seen Bob recommend / as well.</div></blockquote><div><br></div><div>Ugh.  well, it isn't in the spec, except i the specific instance of altitude in comment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> Where's the most relevant documentation on data extension field separators these days?</div></blockquote></div><div class="gmail_extra"><br></div>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".</div><div class="gmail_extra"><br></div><div class="gmail_extra">So maybe we need to define a "data extension field"?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Jason<br><div class="gmail_signature" data-smartmail="gmail_signature">kg4wsv</div>
</div></div>