https://gitlab.synchro.net/main/sbbs/-/commit/3bed2149e5ccec34c5e690d9
Added Files:
src/tith/standards/TSP-0001.txt
Log Message:
Add TSP-0001 for putting nodelist fields in DNS
--- SBBSecho 3.32-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: Deucе to Git commit to main/sbbs/master on Tue Nov 18 2025 04:20 pm

Howdy,

Add TSP-0001 for putting nodelist fields in DNS

Does the query need to also include the "field=" in the response?

IE: If you are querying for _tith_sysopname, why put sysop= in the response? Couldnt the response just be the answer "Deuce"?

(Curious why you are going this route?)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: deon to Deuce on Wed Nov 19 2025 11:44 pm

Howdy,

Add TSP-0001 for putting nodelist fields in DNS

Another question - would it make sense that the query is reversed?

ie: _sysopname_tith... _iflags_tith....

instead of the other way around? Like srv records are _binkp_tcp, not _tcp_binkp...


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: deon to Deuce on Thu Nov 20 2025 00:04:29

---
þ Synchronet þ Enigma BBS -=- enigma-bbs.com
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: deon to Deuce on Wed Nov 19 2025 11:44 pm

Add TSP-0001 for putting nodelist fields in DNS

Does the query need to also include the "field=" in the response?

IE: If you are querying for _tith_sysopname, why put sysop= in the response? Couldnt the response just be the answer "Deuce"?

Because that's what the RFC said to do... it's supposed to be thing=other thing.
---
þ Synchronet þ The future of BBSing
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: deon to Deuce on Thu Nov 20 2025 12:04 am

Add TSP-0001 for putting nodelist fields in DNS

Another question - would it make sense that the query is reversed?

ie: _sysopname_tith... _iflags_tith....

instead of the other way around? Like srv records are _binkp_tcp, not _tcp_binkp...

I like putting the common prefix first so they can be sorted reasonably.
---
þ Synchronet þ The future of BBSing
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/8e3b82edc54a42cfd20c433f
Modified Files:
src/tith/standards/TSP-0001.txt
Log Message:
Add feedback, reference RFC 1464
--- SBBSecho 3.32-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: Deuce to deon on Thu Nov 27 2025 07:18 am

Howdy,

IE: If you are querying for _tith_sysopname, why put sysop= in the response? Couldnt the response just be the answer "Deuce"?

Because that's what the RFC said to do... it's supposed to be thing=other thing.

Is this RFC 1464 that you speak of?

It makes sense when the attribute=value is a "subset" of the think you are querying, but you are using it twice which seems duplicative(?) to me.

IE: if the query was alterant.bbs.dege.au, it would seem logical to have sysop=deon, and os=linux and bbs=synchronet, etc, but if I was to query _sysop_alterant.bbs.dege.au, I would have thought it to be a better answer to just say "deon", since sysop is the attribute I want to get the answer to.

RFC8552 I think is written with this approach in mind. Anyway, no biggie, just providing feedback in case it might be useful.


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: Deuce to deon on Thu Nov 27 2025 07:19 am

Howdy,

I like putting the common prefix first so they can be sorted reasonably.

OK, make senses.

If it was the other way, then it could be delegated to the system in question. IE: The nodelist for the domain (and addresses) are with the ZC, but the details come from the end system.

EG: if _tith.f2.n2.z885.bbsdev.net was delegated to my BBS, then the answer to _sysop._tith... _systemname._tith... could come from the BBS software/system in question and be consistent with what the BBS software uses (binkp) when interacting with other systems (instead of potentially being different to whats in the "nodelist").

Probably a stretch to implement - but just an idea :)


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: deon to Deuce on Fri Nov 28 2025 01:47 pm

Is this RFC 1464 that you speak of?

It makes sense when the attribute=value is a "subset" of the think you are querying, but you are using it twice which seems duplicative(?) to me.

Yeah, the RFC seems to be written assuming you would pile all the TXT records into a single key and get a big reply and pick them all apart. This isn't great for UDP DNS resolution since it would quickly grow larger than the MTU and be much more susceptible to packet loss.

Existing uses generally use a single-letter bit before the = so they're minimally compliant, which I guess makes sense... so n= for sysop name and f= for iflags. It's mostly there so it doesn't get eaten by strictly comforming DNS servers that would drop a TXT record without an = in it.

sysop=deon, and os=linux and bbs=synchronet, etc, but if I was to query _sysop_alterant.bbs.dege.au, I would have thought it to be a better answer to just say "deon", since sysop is the attribute I want to get the answer to.

Yeah, "n=deon" is about the shortest it can be... updating the doc now.

RFC8552 I think is written with this approach in mind. Anyway, no biggie, just providing feedback in case it might be useful.

Adding 8552 to references and switching the second _ to a -.

Definately useful feedback.
---
þ Synchronet þ The future of BBSing
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: src/tith/standards/TSP-0001.txt
By: deon to Deuce on Fri Nov 28 2025 01:54 pm

If it was the other way, then it could be delegated to the system in question. IE: The nodelist for the domain (and addresses) are with the ZC, but the details come from the end system.

Yeah, that seems like a really weird way to delegate. :D

EG: if _tith.f2.n2.z885.bbsdev.net was delegated to my BBS, then the answer to _sysop._tith... _systemname._tith... could come from the BBS software/system in question and be consistent with what the BBS software uses (binkp) when interacting with other systems (instead of potentially being different to whats in the "nodelist").

Probably a stretch to implement - but just an idea :)

Yeah, I've switched from _tith_sysopname to _tith-sysopname to make it more clear that they're not separate components. The sysopname specifically I expect to use as the "To" user for status messages, so I do need that, and the iflags is pretty obvious why it's needed.

I expect to come up with reasons to need a couple other fields (system flags for example for non-ICM nodes) but have no immediate plans to implement them.
---
þ Synchronet þ The future of BBSing
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/commit/44617671e9e87af2eb6eed0f
Modified Files:
src/tith/standards/TSP-0001.txt
Log Message:
Shorten tag name and use - instead of _ for second part
--- SBBSecho 3.32-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)