ietf-tools / idnits Goto Github PK

Describe the issue

A document I'm shepherding used to include in the abstract a phrase like "This document updates [RFCXXXX]" and Idnits requested to get rid of references there. The editors did the change, but now Idnits complaints (as a comment) that, considering the update field in the header, "the abstract doesn't seem to mention this, which it should".
To me, that I-D is fine to progress like this, but I'm not comfortable with that behavior of Idnits.

Code of Conduct

• I agree to follow the IETF's Code of Conduct

The latest version of this tool complains about missing references when it is regular text in the draft. For example if the text in the draft says the following:

   [64496 64500]
      Matches the AS_PATH where at least one of the ASes is either 64496
      or 64500.

   [^64496 64500]
      Matches the AS_PATH where neither 64496 nor 64500 are present in
      the AS_PATH.

   [64496-64511]
      Matches the AS_PATH where at least one AS number is in the range
      64496..64511, inclusive.  This matches the documentation AS
      numbers in [RFC5398].

The tools reports the following error:

  == Missing Reference: '64496 64500' is mentioned on line 7881, but
     not defined

  == Missing Reference: '64496-64511' is mentioned on line 7889, but
     not defined

  == Missing Reference: '64505-64511' is mentioned on line 7901, but
     not defined

Using the current version on a light-mode terminal is unreadable, even with --solarized, due to the yellow text. (The baby blue is difficult but possible to read.) Please add something like --no-color. This is probably better than --readable-in-light-mode because light modes differ.

Right now idnits stores cache state in ~/.idnits. Modern practice seems to be to use ~/.cache/idnits.

This needs to be upgraded to 2.17.01.

After installing locally to my home directory (since I can't install with -g on this box):

# ~/node_modules/@ietf-tools/idnits/cli.js draft-ietf-ace-cmpv2-coap-transport-09.txt 
node:internal/process/esm_loader:97
    internalBinding('errors').triggerUncaughtException(
                              ^

[Error: ENOENT: no such file or directory, open './package.json'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: './package.json'
}

Node.js v18.13.0

The output of idnits points at obsoletes language that isn't there.

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-rfc8736bis-00.txt

The output includes this comment:

-- The abstract seems to indicate that this document obsoletes RFC7761, but
the header doesn't have an 'Obsoletes:' line to match this.

But the abstract doesn't use "obsoletes" anywhere near the mention of rfc7761.

This has become the real repository for this script - the repo should be adjusted to reflect that.

idnits reports:
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)

The URL does not exist anymore

The current version of kramdown-rfc adds procoessing instructions similar to the following to the XML output:

<?line 57?>

idnits currently flags these with INVALID_ABSTRACT_SECTION_CHILD and INVALID_INTRODUCTION_SECTION_CHILD.

owner:[email protected] type_enhancement | by [email protected]

From
https://mailarchive.ietf.org/arch/msg/tools-discuss/ebs8FYDGWgzTdzsj1FzMBgLBBNQ

idnits correctly produces warnings such as:

 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200)

However, afaik, it does not produce warnings like:

 ** Updated normative reference: RFC 791 (Updated by Updated by RFC 1349, RFC 2474, RFC 6864)

I believe this would be of benefit, since it ought to prompt the authors or reviewers to check whether those updates affect the draft. In fact I've often seen references to RFC791 that show ignorance of RFC2474, so this is not an artificial problem.

(I came to this by noticing that the proposed updates to the RFC style guide have removed the statement that the RFC Editor catches references to obsoleted RFCs, as described at https://tools.ietf.org/html/rfc7322#section-4.8.6).

Issue migrated from trac:573 at 2022-02-08 07:11:18 +0000

This proposal is for a rewrite of idnits in javascript, so that it can run both natively in the browser and on the server / console.

General Implementation

• Implemented as a ESM library, exposing a single async function checkNits(opts), that resolves to a result object.
• A separate cli.js parses command line arguments, calls the library and output the results in a console friendly format.
• Section texts should be stored in a separate .json file.

Distribution

As a NPM package that can be both embedded into a web application or used as a standard CLI, on any platform supported by Node.js.

Arguments

See README.md instead.

Returns

{
  result: string, // either "success" or "failed"
  file: {
    path: string, // Path of the document
    lines: Number, // Number of total lines processed
    size: Number // filesize in bytes
  },
  issues: [
    {
      lines: Array<Number>, // start and end line number (starts at 1), e.g. [1,5]
      message: string, // error message
      ref: string, // optional link reference
      level: string // either "warn" or "error"
    },
    ...
  ]
}

Web UI Mockup

The library could be integrated into a web app, allowing the user to browse for a document to validate. The document would be presented in a code editor like view, with warnings / errors shown on relevant lines (either inline or on the side).

Breakdown of the Current Implementation

1. starts at L3053
2. calls check_line()
   1. check line length
   2. check line spacing
   3. check line ending with hyphenated word
   4. check ascii chars only and not ctrl chars
   5. check that abstract and "status of memo" are not numbered
   6. check RFC 2119 language
   7. check example domain names
   8. check ipv4 addresses
3. calculate page count
4. warn if draft starts with PK or BM
5. normalize text and try a list of matches
   1. calls match_para()
6. calls report()
   1. todo

Original idnits SOW

idnits-SOW-00.pdf

Hi,

I'm trying out idnits v3 (3.0.0-alpha.33) and it works great but there's one lint I'm wondering about:

2  Error
 └- Code - MISSING_REFERENCES_TITLE
 └- Desc - The references section is missing a title attribute.
 └- Ref  - https://authors.ietf.org/required-content#references
 └- Path - rfc.back.references[0].title

I've been looking through the already published RFCs but the <reference> tags seem to be missing titles there too:

$ curl -sSL https://www.rfc-editor.org/rfc/rfc8949.xml | grep '<references'
    <references pn="section-11">
      <references pn="section-11.1">
      <references pn="section-11.2">

Where can I learn more about the title attribute and the reasoning for this lint?

(Context: I'm producing the XML from Markdown via mmark but before I submit an issue there I'd like to understand the reasoning).

Thank you for your time! 👋

draft-rswg-rfc7997bis is draft in the RSWG, and the filename is completely legal. The description of "Filename must consists of at least 4 components" does not match some of the names described on https://authors.ietf.org/naming-your-internet-draft.

This file also gets FILENAME_INVALID_VERSION_SUFFIX and FILENAME_DOCNAME_MISMATCH errors, which is probably queued off of the above. The docname in the file is draft-rswg-rfc7997bis-02, which has a valid version suffix.

Hello,

I am receiving following warning for my Internet Draft. draft-viathinksoft-oidip-03 :

Unused Reference: 'RFC8792' is defined on line 1056, but no explicit reference was found in the text

Example:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-viathinksoft-oidip-03.txt

But RFC8792 is used in the Appendix.

I have put the Appendix after the References section as recommended by many sources.

Did I do something wrong?

Kind regards,
Daniel Marschall

owner:[email protected] type_enhancement | by [email protected]

From https://mailarchive.ietf.org/arch/msg/tools-discuss/MQLDxikNfhZggHZBLp-v13xEmOA

Hi,

Been discussing this with the other stream heads and wondered whether there
is space for a feature in your To Do list for idnits.

I see at https://tools.ietf.org/tools/idnits/todo that you have an item for
cross-checking obsoletion of higher level docs.

Could you also check for obsoletes/updates across streams (e.g., an
Independent Submission attempts to Obsolete an IETF Stream RFC) and generate
a warning such as:

"This document attempts to obsolete/update an RFC from another stream.
Specific rules may apply to this process, and you will need sign-off from
both stream heads before this document can proceed."

Very much appreciate the work that the tools team does.

Best,
Adrian
--
Adrian Farrel
Independent Submissions Editor (ISE)
[email protected]

Issue migrated from trac:452 at 2022-02-08 07:03:24 +0000

As with #10 , there are several obsolete URLs in the report generated by the Validate (idnits) function at https://author-tools.ietf.org.

Screenshot attached.

It looks like:

https://trustee.ietf.org/license-info -> https://trustee.ietf.org/documents/trust-legal-provisions/

https://www.ietf.org/id-info/checklist & https://www.ietf.org/id-info/1id-guidelines.txt -> https://authors.ietf.org/required-content

At 06d166e we shifted to accepting both an older and corrected string for describing the BSD license in the boilerplate. This was to allow idnits to succeed as people updated their versions of xml2rfc et.al.

Enough time has passed that we should now strictly accept only the corrected version.

A run of idnits with the latest version results in the following error for all RFC cited in the draft. In this case it was being run against draft-ietf-idr-bgp-model-15.txt

Attempted to download rfc8277 state...
The downloaded file seems to be corrupt, proceeding with outdated information.

Removing the .idnits directory in home does not help.

idnits uses wget internally.
Its invocation should include arguments that limit timeouts and retry behavior

Pypi lists idnits at version 3, but this repos seems to have 2.17.1.

Hi, I'm a maintainer for the Homebrew package manager. We maintain an idnits package but we don't have a way of checking for new versions at the moment. We used to check the tarball link on the previous website but the idnits page started redirecting to https://www6.ietf.org/tools/idnits/ around 2021-11 and the current website is only an online checker (no tarball link or version information).

I happened upon this repository and it seems like something we could migrate to in the future (now that it's no longer just a mirror) but we can't use it until there are version tags. Could you please create a tag for 2.17.00 (preferably pointing to the original commit, bfda9518d5b4e8a682f2e6f34a449c2d3ea745390)? Similarly, would you be willing to commit to tagging new versions as they're released? This would make it easy for us to download a snapshot of a given version and allow us to programmatically check the tags for new versions.

Somewhat related, are there any plans for releasing a new version? I see there are some new commits after 2.17.00 but the version in the idnits file remains the same.

Thanks!