-
Notifications
You must be signed in to change notification settings - Fork 30
feat: Properly link to cross-referenced RFCs #51
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
base: main
Are you sure you want to change the base?
Conversation
787072f to
cc2cf8e
Compare
cc2cf8e to
751bd2d
Compare
jennifer-richards
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay but just gave this a look. I have a couple questions/suggestions but don't have a firm request for change and I'm not quite ready to sign off on an approval.
We should run this over a bunch of documents that don't have these sorts of references and confirm that they don't change. The new tests are great, but I worry that we don't have coverage for the negative cases where the new sort of link isn't wanted. Looking for those should happen before this merges IMO.
Thank you for your effort and for the contribution!
|
@jennifer-richards, thanks for the feedback!
Dumb question, but any advice on how I should go about doing this? Do you also think it would be useful to import a few of these into the repo as bigger tests so future updates can also make use of them? |
Very fair questions. I didn't actually mean to ask you to do it - I was thinking it'd be something we would do. The actual test would just be gathering up "some" RFCs, running the original and patched versions, and comparing the output. These shouldn't change except in the cases you're following. @kesara may have a better idea whether this is necessary or how to pick a representative set of inputs. Importing some files into the repo is a possibility, but as a corpus to manually test against and extract specific tests of functionality. The ietf-tools/xml2rfc has tests that amount to "the output for this input shouldn't change," and that turns out to be a tricky test to maintain. |
|
@logan-stytch, @jennifer-richards Apart from that randomly selected new RFCs and couple of Internet-Drafts should be good. Sorry I don't have any specific suggestions. |
As long as this particular change isn't adding new deviations, I'd call it good enough. I.e., I'd compare rfc2html's action on the .txt file before and after this PR rather than comparing to the rfc-editor.org HTML |
dfb1a40 to
49ea57e
Compare
|
I downloaded RFC 7817 and RFC 8649. Here are the diffs of each. For each one, I compared RFC 7817: RFC 8649: |
|
Just wanted to bump here again. Anything else needed to get this committed? |
Thank you for the bump, and sorry for the delay- looking again. |
kesara
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for the PR.
|
Ran this over all the rfcs (minus a few that had encoding issues my quick-and-dirty script didn't deal with). The Ran across a case where a reference that spanned a newline that was split into two separate Didn't find any alarming side effects so I'm happy with it. |
|
Oops- spoke too soon. A line break in RFC 7925 is impacted badly. Startingn at line 1256 in the rendered HTML, becomes Since this is in a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the churn, but see comment re: significant linebreak changes in rfc7925 and possibly others
Edit to add: impacts quite a few. Scanned for changes in line counts and 364 show up. Spot checking, it looks like the same issue in all of them.
|
I think I've got the requested changes fixed, but let me know what you think. I also made a (local) utility to compare |
|
Getting closer! There are still ~100 (108 by my not perfect method) that have line count changes, though. Example in rfc1122: old vs new |
7811353 to
731dec8
Compare
731dec8 to
f7178f5
Compare
|
Thank you for the update! Is this ready for a re-check or do you have more changes coming? |
|
@jennifer-richards - I should probably do my own testing first, I've been pretty busy the last month and haven't had a chance to test thoroughly yet. |
|
Okay, I ran my tests comparing old vs new output and I think this is ready for another review! |
Great, I'll give it a look tomorrow. Thank you! |
|
This is moving forward - down from 108 to 87 line count changes I think. I'm attaching my list here in case you want to look at it. After the holidays, I'll look into this some more and talk with @kesara and others about how much we need to chase perfection here. I've noticed one other change that I don't think is new with this version, but hadn't caught my eye before. In RFC 1002, in a ToC entry for |
Fixes #38
Handles cross-RFC section references by identifying these before RFC linking, adding special markers, proceeding with normal RFC linking, and then removing the cross-RFC markers once finished.
To be honest, there are a bunch of very nasty regexes in here, so it was hard to be 100% certain that this was correct. I added a number of new test cases to
tests.pyto hopefully validate that this is working as expected.