server more changes to content and design by n7tae · Pull Request #6 · M17-Project/M17_inet

n7tae · 2026-09-08T19:57:47Z

I have:

Changed the last paragraph of the Introduction to a "Purpose" and "Where to get involved" subsection.
Removed all numerical beginnings and any ending punctuation from all topic heading.
Allowed for the possibility of future improvement in urfd and made other improvements to Chapter 3.
Added some colons and dashes to make all tables look good and consistent.

jancona

Claude-detected typos:
"can be use by other developers" → "used"
"and entire M17 ecosystem" → "and the entire"
"rasing" → "raising"
"group.io" → "groups.io"
"behave as legacy reflector" → "reflectors"
"DISC packet is send" → "sent" (not from by this PR, but maybe fix it while you're in there)

Thanks for doing this, it definitely adds to the spec!

jancona · 2026-09-08T21:50:48Z


-M17 is designed with this use in mind, and has native IP framing to support it.
-In competing radio protocols, a repeater or some other RF to IP bridge is required for linking,
-leading to the use of hot-spots (tiny simplex RF bridges).


I kind of like this paragraph. It says how M17 is different and why this document exists. Can it still be included in purpose?

jancona · 2026-09-08T21:54:03Z

+This part of the specification is where M17 over-the-air engineering is translated to Internet Protocol (IP) capabilities that M17 users want. In the spirit of true Open-Source innovation, M17 developers are encouraged to document their M17 contributions here so that their M17 programs and tools can be use by other developers and entire M17 ecosystem can be used and enjoyed by all M17 users.
+
+
+### Where to get involved


This doesn't feel very "spec-like," plus we don't want to change the spec if a Discord channel name changes. Maybe the text should be in the README or a CONTRIBUTING file, with a pointer to that here.

agreed. the other info was moved to README.md.

jancona · 2026-09-08T21:55:20Z

+
+### Where to get involved
+
+1. Casual discussion or simple questions on any M17 Specification related topic from anyone can be started on the #m17-specification channel of the  [M17 Discord](https://discord.com/).


Probably want the Discord invitation URL: https://discord.gg/TYby5jq8u
Also two spaces before [Discord].

This takes me to "Jim has invited you to join the M17 discord". I'm going to leave the simpler url.

jancona · 2026-09-08T21:59:09Z


-1. Legacy reflector are all *urfd* reflectors as well as any *mrefd* reflector with a version number less than 1.0.0. Legacy reflectors **do not** forward any packet mode data.
-2. Any *mrefd* reflector with a version number greater or equal to 1.0.0, will forward both stream data and packet data from any client on any particular node to all nodes connected to that same module, except if the data is packet mode data and if that node is an interlinked, legacy reflector.
+1. Legacy reflector any *mrefd* reflector with a version number less than 1.0.0. Legacy reflectors **do not** forward any packet mode data. All known *urfd* reflectors behave as legacy reflector, but evolution of *urfd* is possible.


s/Legacy reflector any/Legacy reflectors are any/
s/behave as legacy reflector,/behave as legacy reflectors,/

jancona · 2026-09-08T22:00:49Z

 #### Enforcing the "one hop" policy by appending a byte

-Also be aware that both *urfd* and *mrefd* enforce a "one hop policy" for any incoming packet from a regular client. Fundamentally that means that any packet received from an interlinked reflector will not be forwarded to any other reflector. Therefore any number of reflectors that share a channel must be interlinked to all reflectors in that same group. That's the only way any client can hear every other client on that interlinked module.
+It is important to note that interlinking methods both *urfd* and *mrefd* are based on [*xlxd*](https://github.com/LX3JL/xlxd) and enforce a "one hop policy" for any incoming packet from a regular client. Fundamentally that means that any packet received from an interlinked reflector will not be forwarded to any other reflector. Therefore any number of reflectors that share a channel must be interlinked to all reflectors in that same group. That's the only way any client can hear every other client on that interlinked module.


s/interlinking methods both/interlinking methods in both/

jancona · 2026-09-08T22:03:58Z

+1. Casual discussion or simple questions on any M17 Specification related topic from anyone can be started on the #m17-specification channel of the  [M17 Discord](https://discord.com/).
+1. More serious discussion that warrants a permanent record should take place by either rasing an issue on [this repo](https://github.com/M17-Project/M17_inet), or posting a message to the [M17-Users group.io](https://groups.io/g/M17-Users/topics) website.
+1. Developers can submit a pull request (PR) to [this repo](https://github.com/M17-Project/M17_inet) to add information about their M17 application(s). They only need to supply the information in a new `##` Chapter in the `M17 Internet Interface.md` file. If they want to make sure the PDF is rendered properly, instructions for making the PDF are in the `README.md` file.
+1. Even skilled M17 users can submit a PR if they already have an account on github.com and see a problem with either specification document and know how to fix it. Many have done so already.


"Even skilled M17 users can submit a PR" might sound condescending. Maybe something like "M17 users who aren't developers can submit a PR".

jancona · 2026-09-08T22:15:33Z

+1. Any *mrefd* reflector with a version number greater or equal to 1.0.0, will forward both stream data and packet data from any client on any particular node to all nodes connected to that same module, except if the data is packet mode data and if that node is an interlinked, legacy reflector.

-Importantly, legacy reflectors will only forward stream data if the destination in the packet is addressed to the module to which it is linked. For example, the destination address must decode to `M17-XYZ m` or `URFXYZ  m`, where `m` is an appropriate module letter, A-Z. In both cases, please note that these destinations fill the maximum width of an M17 callsign, there are two spaces before the module in the *urfd* address! Further, legacy reflectors will readdress the destination address to be the encoded callsign of the client receiving the data. Whenever a reflector modifies a packet, any CRCs affected by that modification will be recalculated.
+Importantly, legacy reflectors will only forward stream data if the destination in the packet is addressed to the module to which it is linked. For example, the destination address must decode to `"M17-XYZ m"` or `"URFXYZ  m"`, where `m` is an appropriate module letter, A-Z. In both cases, please note that these destinations fill the maximum width of an M17 callsign, there are two spaces before the module in the *urfd* address! Further, legacy reflectors will readdress the destination address to be the encoded callsign of the client receiving the data. Whenever a reflector modifies a packet, any CRCs affected by that modification will be recalculated.


The PDF rendering of the spaces in the destination address examples looks a little weird. I'm not sure what to do about it.

agreed. I rewrote this, as I couldn't find a way to do this either. This seems to be a limitation with the transcriber.

jancona · 2026-09-08T22:16:43Z

-| Field          | Size     | Description              |
-|:---------------|:---------|:-------------------------|
+| Field | Size | Description              |
+|:-----:|:----:|:-------------------------|


Do we want the Field column centered? It looks a little funny to me.

I like centered better than left justified. You can change it with your next PR!

jancona

LGTM

server more changes to content and design

0e59483

jancona reviewed Sep 8, 2026

View reviewed changes

n7tae added 2 commits September 8, 2026 15:34

fix some typos Jim found

ef511e7

some more changes from jim

6bbf95c

jancona approved these changes Sep 9, 2026

View reviewed changes

sp5wwp merged commit 6a8d8f2 into M17-Project:main Sep 9, 2026
1 check passed

		This part of the specification is where M17 over-the-air engineering is translated to Internet Protocol (IP) capabilities that M17 users want. In the spirit of true Open-Source innovation, M17 developers are encouraged to document their M17 contributions here so that their M17 programs and tools can be use by other developers and entire M17 ecosystem can be used and enjoyed by all M17 users.


		### Where to get involved


		### Where to get involved

		1. Casual discussion or simple questions on any M17 Specification related topic from anyone can be started on the #m17-specification channel of the [M17 Discord](https://discord.com/).

Conversation

n7tae commented Sep 8, 2026

Uh oh!

jancona left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jancona left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants