martinthomson / i-d-template

A template for IETF internet draft git repositories
Other
207 stars 182 forks source link

Use rfc-editor.org/info/rfcXXXX instead of rfc-editor.org/rfc/rfcXXXX for AUTH48 #371

Open DavidSchinazi opened 1 year ago

DavidSchinazi commented 1 year ago

I absolutely agree that rfc-editor.org/info/rfcXXXX is a much better reference to use than rfc-editor.org/rfc/rfcXXXX as it saves everyone clicks. Using these tools for AUTH48 though, it creates a visible diff between the output of this tool and the output from the RFC Editor.

Proposed solution: if the number: field is filled in, then switch back to rfc-editor.org/info/rfcXXXX. Alternatively, we could define a new separate field that toggles this behavior.

How do you feel about this? I was going to write a PR for it but I noticed that XML2RFC_RFC_BASE_URL was set in config.mk and that file can't access any draft-specific information. So I figured I'd ask for your opinion and guidance before I started making changes.

martinthomson commented 1 year ago

Hmm, that seems like a lot of work to save a few lines in a diff.

You can maybe base this off the filename:

rfc%.whatever: rfc%.xml
      xml2rfc --rfc-base-url https://rfc-editor.org/info/rfcXXX
draft-%.whatever: draft-%.xml
      xml2rfc --rfc-base-url <something useful>

I've not tested this, so this might not work.

make also has this thing where you can assign pattern-specific variables, but I've never managed to make it work properly. You could try that, but I you might still end up with the above split (because %.txt: VAR = x is a different pattern than rfc%.txt: VAR = y; though the documentation suggests that maybe this could work).

The latter might be more elegant if you can make it work.

DavidSchinazi commented 1 year ago

The filename-based approach doesn't work amazingly for me since I generally don't rename the file in the AUTH48 PR.

But if it's a lot of work then maybe we give up. I was initially assuming I could tweak this in a few minutes but the code architecture might not lend itself to that.

Feel free to keep this issue in the backlog of future features or to close it if you prefer.

martinthomson commented 1 year ago

We can leave it here. A well-considered issue is an asset and it's not like there is any hope of reaching zero outstanding issues.