First draft of Tilde Description Protocol Standard Proposal #3
Loading…
Reference in New Issue
No description provided.
Delete Branch "(deleted):master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is this needed?
Is this needed?
No reason not to I suppose
First Last <username@tilde.tld>format (using a pseydonym is OK but discouraged) for the author field.Fix these issues please.
incorrect format
I added the missing section title for the Procedural Section, and the draft is now compliant with RFC-0 with regards to formatting or tagging.
8eef3dfc0a/draft-tilde-description-protocol.md (procedural-information-procedures)Missing security considerations
Security considerations are not missing.
80f67c1e15/draft-tilde-description-protocol.md (security-considerations-security)Missing configuration considerations
Configuration considerations are not missing.
80f67c1e15/draft-tilde-description-protocol.md (configuration-considerations-config)Use First Last username@tilde.tld
If using a pseudonym is OK, then I choose to use the name I go by in this community, which is dozens.
See RFC 0. (like, really read it.) Tildeverse RFCs mandate things. Do you want all tildeverse members to expose TDP? That goes in the config considerations section.
It is condescending and not helpful to say to just read RFC-0 without telling me what you want me to understand about it, and what I'm currently doing that is not conforming to the understanding you wish I had.
If I were to respond in like, I would tell you to just re-read the proposed draft. (Like, really read it.) But that is not good or constructive communication.
Instead, I will offer my understanding of its compliance with RFC-0:
Config Considerations
See:
8eef3dfc0a/draft-tilde-description-protocol.md (configuration-considerations-config)This section says that tildes must expose a valid ~dp JSON object at their root folder.
This appears to be what you are asking for, and so I legitimately don't know what else you want. Please let me know.
Document Types
This is an RFC document and not a Standards document. As such it does not mandate anything
It was modeled almost exactly after RFC-1, which is also an RFC and not a Standard.
If there is something I am not understanding about the document types and I need to do something else, please let me know.
Unless I'm totally missing something here, this is the 3rd time you pointed to missing content that is not actually missing. I get the feeling that you are not taking the time to read the draft.
I'm sorry, but I generally try to avoid having to explain in-depth, especially since my last 2 replies were typed on mobile during school/on buses and I hate my smartphone's digital keyboard.
What I mean by "mandate" was more of a "what are you requesting?". From RFC #1:
The request is made clear: add something to a header in nginx/apache/whatever.
Nowhere in your draft does it specify the request. If you want ~verse boxes to support TDP if at all possible, say so in the closing sentence of your abstract.
With all due respect, the reason why I've been avoiding/putting off reviewing this RFC draft is that it seems a bit superfluous. Your first draft was basically a copy/paste or transcription job of the TDP protocol set forth by datagrok with the required front-matter and closing procedural info added. Not to say this is a lazy job, but if the description of the protocol datagrok sets forth is enough, why do we need it in our database? Not to devalue your contribution in any way, but as I put forth in my first (admittedly, double-posted) comment, "Is this needed?"
(It was the second btw.)
Closing due to inactivity. If you want to get this up to snuff, let me know and this will be re-opened.
(the way khuxkm conducted the conversation seems a bit unconstructive to me)
I mean, not to dredge up something that happened four years ago, but yeah, this was a really disappointing experience for me. I was just trying to participate in something that I thought was cool, and felt really shot down for reasons I still don't understand. It demonstrated that khuxhm was (at the time) not interested in considering any RFC that they didn't write themself. Which is antithetical to the spirit of the tildeverse. That is, to the spirit of community, learning, inclusion, and engagement.
On the other hand, I could be wrong about everything, so 🤷♀️
"not to dredge up something that happened four years ago" proceeds to do just that
yeah, I could've been a bit more constructive in my responses, but I largely stand by my intended point: the idea of the tildeverse RFC system was to have a place where people would be able to write something that requested something, and then have that request debated and considered.
all you had to do was stick a "conforming tildes should support Tilde Description Protocol by including a tilde.json file in their root matching this syntax" and I would've accepted it. the problem is, just saying "this is a thing that exists" can be done just about anywhere; heck, I've done something like that on my blog/gemlog a couple times. I was trying to nudge you in the direction of making a point of it; clearly I wasn't that good at doing it, but I was 15 at the time so please cut me some slack in that regard.
Sorry, I too didn't provide explanations of what I meant. Please, say if you think I should do that. Otherwise, I think I may not touch this issue anymore.
Pull request closed