RFC: Redefine 'reserved' addresses

[kc1awv]

Regarding a previous discussion in GH #139 about the spec and address encoding / reserved space, how about slicing off a part of the space for application functions, and define them? The spec should also define that 'future use' is open to anyone, this is just the first subset of the reserved addresses being used.

0xFFFFFFFF0000 - 0xFFFFFFFFFFFE gives 65534 addresses that could be used for application functions, like #ECHO, #INFO, and #UNLINK.

Use of the # character shall also indicate use of reserved address space / application functions.

Application space of the 65534 addresses can be further subdivided with a large enough divisor to hold the functions for differing applications. For instance, allocating 14 commands for an application gives space for 4681 different applications. Multiple subdivisions could be requested if the number of commands for a single application exceeds 14. Though, I'd expect that would be a very rare case.

Think of it like IANA, but for M17 addresses instead of port numbers.

[n7tae]

This sounds good and about the right size to me, but I have lot's of questions. My initial question are about what the reserved address are for and what's the benefit of using them.

I can see the need for i8n so I can use ALL, E-land can use TODO, F-land can use TOUT and S-land can use WSZYSCY and we all actually mean #ALL, but how many languages will we support? (initially and what we might think will be a max) and how many #COMMAND values will be specified in the spec? (initial and what might be a max)

Are their #s that don't need i8n? What kind of commands might they be? Can we anticipate what they might be and how many their might be? Does each # have it's own scope? (radio/hot-spot/repeater/reflector/?)

Should we have an area in the reserved space where an application (by that, I mean anything from the lowly mvoice to the massive MMDVM) can use addresses for their own special needs? I would say that these reserved addresses have specific "application scope".

[mdiepart]

Here are a few comments about this issue:

1. i8n is, in my opinion, not an issue if we decide that 0x0000000ED87D means "repeat after me" then we can let the implementations handle the actual translations. This however raises another issue which we will have anyway :
2. How to enter the functions in the UI? Should the implementation display a list of actual commands? And if we use i8n with the current codes, what do you have to enter? The translated command name?

And here are a few suggestions about how imo we could/should handle this

1. Use some of the "Don't care" bits in the "LSF TYPE" field to have a protocol version field
2. Mark the current "ECHO", "INFO" and "UNLINK" identifiers as deprecated (from protocol version 0b001 onward) but keep them in the specs
3. Add more identifiers in the same style as "ALL". That is, the address value of the identifier do not match the encoded value of those letters (and mark that a specific part of the address space is reserved?)
4. Because reflectors can have any name and are not regulated by IARU, specify what is an acceptable reflector name to make sure that it cannot clash with the reserved address space (example, if I want to call my reflector "........." then the encoded name would be "0xFFFFFFFFFFFF")

[n7tae]

Nine dots is at the top of the valid (not reserved) address space, 0xEE6B27FFFFFF.

[mdiepart]

Ah yes, my bad

[SmittyHalibut]

Specifically, the reserved addresses in question are necessarily outside the encodable space. They CAN NOT be encoded with a valid 9 character base40() input string. Thats why I proposed using them for special purposes. Otherwise, they’ll go unused. Which is a fine option, but if we can think of a use for them, they’re there. -MarkOn Sep 10, 2024, at 1:14 PM, Morgan Diepart ***@***.***> wrote: Ah yes, my bad —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sp5wwp]

Addressed in a28a833.