-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cleanup specs and structure #329
Comments
Note to self when SASL gets merged, fit this example into the merged spec: Example showing new SASL mechanisms becoming available. This example requires the client to support
The given |
We could also note that 908 can be used to advertise a change of mechlist |
For changing mechanisms, should we push CAP DEL+NEW or 908? Maybe if they've already negotiated the |
We could push 908 for changed mechlists but still have an example of sasl going away and then coming back on e.g. a services outage. Clients should handle both. |
Yep, that sounds like a good way to split them up. I'll do it that way in the SASL merge then \o/ |
As mentioned on IRC. This should probably be a MUST:
|
As long as the MUST phrasing doesn't accidentally forbid the server from rejecting unauthenticated clients |
After the SASL specs get merged, we can throw another PR in that actually makes that change. Putting material changes in with the merge slows stuff down. |
Fine by me! |
Message-tags has also now been merged into a single spec. Whoo! |
Reorganised the list of things-to-be-done. Much more action-oriented now.
Regarding sub-issues and etc, I don't think this needs to be split up. It was only blocked for so long because I didn't want to tangle with pending SASL changes that looked fairly widespread, but I've bumped that below general cleanups so that's not a blocker now. |
This is something I've been meaning to do for a while, just making an issue so I remember to submit the changes. Once #327 is done and SASL is merged I'll do this.
Merge CAP 3.1, CAP 3.2 and(done)cap-notify
(Merge CAP 3.1, CAP 3.2, and cap-notify specs #327).Remove version numbers from spec filenames and YAML title names.Where they exist, remove markdown headers that duplicate the YAML title headers on specs (some specs for instance have an## IRCv3 <blah> Extension
up the top in addition to the YAML header – rip that out.Reorganise the specs under a few separate folders.This involves a lot of coordination between this repo and the website repo (renaming / combining specs data files, updating spec pages and etc), so need to be careful when merging PRs and subsequently pulling the updates into the website.
Since this repo's a submodule named
/specs
on the website, makes sense to have a few subfolders:specs/client-tags
: Client tag specifications.specs/batches
: Batch type specifications.specs/sasl-mechs
: SASL-mechanism-specific specs.specs/metadata-keys
: Metadata key specs.specs/deprecated
: Deprecated specs we want to keep around (such as the current SASL mech specs underspecs/documentation
).specs/extensions
: Everything not covered by the above.Yep, under this arrangement everything currently in
specs/core
gets put intospecs/extensions
instead. It makes sure people know that things are optional (things like metadata aren't mandatory to implement to be IRCv3-compliant), and the main Specs page on the website is better positioned to make the necessary separation between, for example, cap, message-tags, and specs like extended-join anyway.This replaces #265 and #299
The text was updated successfully, but these errors were encountered: