Subject: Re: [Tools-discuss] Idnits-1.85 - requesting a further feature

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 16 Jan 2006 02:04:13 +0100

Hi Allison,

on 2006-01-15 20:55 Allison Mankin said the following:
> Hi, Henrik,
> 
> Would it be hard to add checking of Section 6A and 6B of
> http://www.ietf.org/ID-Checklist.html to Idnits when you next
> update?  

I assume you mean Section 3, items 6A and 6B.

> The shepherds and ADs vet a lot of example addresses.  It's
> pretty easy to catch problem FQDNs by eye, but problem literals
> can slip through more readily, especially if most of the literals
> in a document have been switched to comply with RFC 3330/RFC 3849,
> but a few have been missed.
> 
> The IESG ends up catching 6A/6B nits often.

The checks I can imagine for this would be

  1. Anything which matches a typical FQDN:

	([a-z0-9-_]+\.)+[a-z0-9-_]+\.[a-z0-9-_]+

	should also match

	([a-z0-9-_]+\.)+example.(com|org|net)

  2. Anything which matches an explicit IPv4 address:

	[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\
	
	should also match

	192\.0\.2\.[0-9]+

  3. Anything which matches an explicit IPv6 address:

	[0-9a-fA-F]+:(([0-9a-fA-F]*):)*

	should also match

	2001:DB8:(([0-9a-fA-F]*):)*

Of course, if a document proposes an explicit IANA allocation of
a specific non-example prefix, that will violate this.

I could still issue a warning for this, which people who really
were proposing a specific prefix allocation would have to ignore.

If the above looks sensible to you, I'll put it in the next version
of idnits.

Regards,

	Henrik

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 16 Jan 2006 13:21:28 +0100

>         ([a-z0-9-_]+\.)+[a-z0-9-_]+\.[a-z0-9-_]+

My abilities to read REs without starting gawk are limited,
but that appears to be three or more labels without the
1123 or 3696 restriction on toplabel.  If that's correct
your second case IPv4address is a special case of this RE.

Some hours ago I've proposed a "toplabel task force" in
USEFOR, maybe it's actually a good idea, not only a joke.

>         ([a-z0-9-_]+\.)+example.(com|org|net)

The com/net/org label is only optional, ".example" at the
end is also okay.  Apparently you don't want two labels -
avoiding tons of "false positives".

>         2001:DB8:(([0-9a-fA-F]*):)*

I think it's a bit more tricky, are you talking about complete
FWS delimited words, or only about the start of FWS delimited
words ?  On STD 66 http://tools.ietf.org/html/3986#page-20 the
<IPv6address> might be what you want:

The tail of <IPv6address> can be an <IPv4address>.  <IP-Literal>
incl. <IPv4address> often comes in square brackets.  Warnings
for all kinds of feed: abcdef: etc. might be confusing.

                               Bye, Frank

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 16 Jan 2006 16:02:46 +0100

Hi Frank,

> your second case IPv4address is a special case of this RE.

Yes, and yes.

I could be more precise, and add (some of) the limitations
that 3696 describes, and say e.g., 

	([a-z0-9][a-z0-9-]*[a-z][a-z0-9-]*[a-z0-9]\.)+[a-z0-9][a-z0-9-]*[a-z][a-z0-9-]*[a-z0-9][.]?

- but I'm not sure that would contribute to the initial
exploration of the basic idea ,;-)

But I agree, bot the added precision in the regex, and possibly
some additional qualification based on
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
might be of interest - the latter would let you say either
  "Warning: Existing top level domain used instead of .example
   or .example.(com|net|org) ."
or
  "Error: Non-existing top level domain used instead of .example
   or .example.(com|net|org) ."

> USEFOR, maybe it's actually a good idea, not only a joke.

Dunno ;-)

> avoiding tons of "false positives".

Right, and right.

> <IPv6address> might be what you want:

Humm, yes.  This one needs some refinement.

> for all kinds of feed: abcdef: etc. might be confusing.

I'll probably need to set up rather strict checks, and then run
the last 1000 RFCs or so through it and devise heuristics to avoid
too many false positives.  Using a check for square brackets in the
heuristics makes sense to me.

Thanks,

	Henrik