Subject: Re: I'm back (finally)

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 1 Dec 2005 11:24:11 GMT

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>The feedback I got (not official) was that the 1123 oblique reference was 
>the closest we have come to an official statement; I got one comment saying 
>that at the time Jon Postel was IANA, he said quite clearly that "there 
>will never be a numeric TLD". But I've not managed to find a policy 
>document that says so.

I think all we can do is to proceed on the assumption that John Postel was
correct.

>I've pushed on the dnsext list for the prohibition to be added to 
>draft-eastlake-2606bis, but that hasn't happened so far... meeting some 
>resistance, mostly of the "not the IETF's business" type.

I would have thought it was very much the IETF's business if every IP
address in the traditional form ("123.456.123.456") could also be
potentially a domain-name. I am sure there are lots of existing things
that would break if that were ever to be allowed.

There is currently a guidance statement from ICANN, that I unearthed in
the IANA website, that says ".example" and the like should not be TLDs. I
suppose persuading ICANN to include a remark about numeric TLDs would
resolve the issue (I gather it is already too late to prevent numeric
components at lower levels).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 13 Dec 2005 16:08:01 +0100

Charles Lindsey wrote:

>> at the time Jon Postel was IANA, he said quite clearly that
>> "there will never be a numeric TLD". But I've not managed to
>> find a policy document that says so.

> I think all we can do is to proceed on the assumption that
> John Postel was correct.

That would be "not only digits".  No idea how I managed to
hallucinate "at least one alpha" into RFC 3696, it clearly
says "not all-numeric":

| There is an additional rule that essentially requires that
| top-level domain names not be all-numeric.

We don't need ABNF for that, or do we ?  Apparently 1123 2.1
(a part of STD 3) says toplabel = 1*ALPHA

| However, a valid host name can never have the dotted-decimal
| form #.#.#.#, since at least the highest-level component
| label will be alphabetic.
                             Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 14 Dec 2005 12:50:05 GMT

>(a part of STD 3) says toplabel = 1*ALPHA

Well we have decided that a path-identity should be an <fqdn> or a
<bareword>, but not an <IP-address> (those are only for
source-identities/diagnostics). So if we want to give a clear syntax for
what is allowed, some ABNF for <fqdn> seems in order.

The syntax I have proposed currently includes:

   toplabel = [ label *( "-" ) ] ALPHA [ label *( "-" ) ]
               ; at least one ALPHA

which gives the required safety and agrees with Jon Postel, but is less
restrictive than what you have found in RFC 1123. We could follow either,
but I don't think Film at 11 would be needed either way :-) .

>| label will be alphabetic.

Yes, that seems clear enough. (It is also the place where it says that if
a domain name is acceptable in some context, then an IP address SHOULD be
acceptable also - which we have decided not to follow in Paths :-( .)

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 14 Dec 2005 21:21:28 +0100

>    toplabel = [ label *( "-" ) ] ALPHA [ label *( "-" ) ]

Yes, that's the "at least one ALPHA" syntax.  But I got this
wrong, it isn't the same as "not only digits" as in RFC 3696.

We'd need "at least one non-DIGIT" for what Harald found out,
and as stated in RFC 3696, "allowing" toblabels like 1-2-3.

Based on what we discussed in...
http://article.gmane.org/gmane.ietf.usenet.format/30109
...that could result in:

   toplabel = ( [ label *( "-" ) ] ALPHA [ *( "-" ) label ] )
            / ( label 1*( "-" ) label )

Is this the most simple form to say "not all-numeric" plus
"hyphen only inside" ?  We could also add "minimal length 2":

   toplabel = ( [ label *( "-" ) ] ALPHA   *( "-" ) label   )
            / (   label *( "-" )   ALPHA [ *( "-" ) label ] )
            / (   label          1*( "-" )          label   )

> less restrictive than what you have found in RFC 1123.  We
> could follow either, but I don't think Film at 11 would be
> needed either way :-)

It's interesting not only here, it could also affect 2821bis
(= to avoid useless root server queries for erroneous IPv4
constructs without square brackets) and RfCs using the simple
2396 approach "must start with ALPHA".

And SPF could reach AUTH48 as soon as 2476bis got its number.

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 15 Dec 2005 16:59:12 GMT

>            / ( label 1*( "-" ) label )

OK, I've put that in my syntax now.

However, the main question that still needs answering (as Harald has agreed) is
whether we want to arrange the syntax so that one can immediately tell
whether a given entry is a path-entry or a souce[diagnostic]-entry.

I have said that is a desireable feature, but nobody else has answered
yet.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 16 Dec 2005 15:16:41 +0100

--On torsdag, desember 15, 2005 16:59:12 +0000 Charles Lindsey 
<[email-masked]> wrote:

> However, the main question that still needs answering (as Harald has
> agreed) is whether we want to arrange the syntax so that one can
> immediately tell whether a given entry is a path-entry or a
> souce[diagnostic]-entry.
>

And I have said that I do not judge it possible to design and get consensus 
for such a mechanism without delaying USEFOR considerably, given the 
current lack of energy in the group.

I think it's better at this time to allow stuff in USEFOR (which will also 
allow existing usage, which is varied, and not mechanically 
distinguishable) and make rules for "one way to do it" in USEPRO.

If we can get that far.

                  Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 19 Dec 2005 17:20:29 GMT

>distinguishable) and make rules for "one way to do it" in USEPRO.

No, I don't think that is workable without syntactic changes in USEFOR.

Anyway, we now have a new draft-06 which addresses some of these issues,
so let us start from that. I have assembled the full text as it now stands
following Ken's diffs.

>3.1.6  Path
>
>   The Path header field indicates the route taken by an article since
>   its injection into the Netnews system.  Each agent that processes an
>   article is required to prepend one (or more) identities to this
>   header field body.  This is primarily to enable news servers to avoid
>   sending articles to sites already known to have them, in particular
>   the site they came from, and additionally to permit tracing the route
>   articles take in moving over the network, and for gathering Usenet
>   statistics.
>
>   path            =  "Path:" SP path-list CRLF
>
>   path-list       =  [FWS]
>                      *( ( path-identity / path-keyword /
>                           path-diagnostic ) [FWS]
>                         path-delimiter [FWS] )
>                      tail-entry [FWS]
>
>
>   path-identity   =  ( ALPHA / DIGIT )
>                      *( ALPHA / DIGIT / "-" / "." / "_" )
>
>   path-keyword    =  "POSTED" / "MISMATCH"

Leaving that in the syntax will prevent subsequent introduction of new
keywords (e.g. SEEN) or making the list of keywords extensible, as you
have suggested. Moreover, it would preclude changing to the alternative
"news.example..MISMATCH" notation.

>   path-diagnostic =  1*( ALPHA / DIGIT / "-" / "." / ":" / "_" )

That allows ":" in _any_ diagnostic, not just in IpV6addresses.

>
>   tail-entry      =  path-identity
>
>   path-delimiter  =  "!" / "!!"
>
>   A <path-identity> is a name identifying a site.  It takes the form of
>   a domain name having one or more components separated by dots.

That makes no allowance for barewords (whether we formally define that
term or not). "It _usually_ takes the form of a domain name ..." would be
OK, because any gory details could then be left to USEPRO.

>
>   Each <path-identity> in the <path-list> (excluding the one in the
>   <tail-entry>) indicates, from right to left, the successive agents
>   through which the article has passed.  The <path-keyword> "POSTED"
>   indicates that the agent to its left injected the article.  The use
>   of the <path-delimiter> "!!" indicates that the agent to its left
>   claims that the agent to its right was the verified source of the
>   article (whereas the <path-delimiter> "!" implies no such claim).
>   The <path-keyword> "MISMATCH" indicates that the agent to its right
>   failed to be so verified.

Which actually extends what was said before because it allows the agent to
is left to shout "MISMATCH" without actually prefacing it with a
diagnostic saying what it actually saw. I think "MISMATCH" (or "SEEN" if
we have it) needs to be anchored to the agent to its left, just as with
"!!".

>
>      NOTE: Although case-insensitive, it is intended that the <path-
>      keyword>s "POSTED" and "MISMATCH" should be in upper case, to
>      distinguish them from the <path-identity>s which are traditionally
>      in lower case.
>
>   A <path-diagnostic> is an item inserted into the Path header for
>   purposes other than to indicate the name of a site.  One commonly
>   observed usage is to insert an IP address.

At least you need to say that such an IP address indicates the site which
whatever agent put it there claims to have received the article from.
However, what we do not (and cannot) know is how often sites insert a
domain-name with that same diagnostic intent, although we do know that many
sites DO insert such a domain name in the form
"true.source.example.MISMATCH".

>  ... The colon (":") is
>   permitted in order to allow IPv6 addresses to be inserted; note that
>   this will cause interoperability problems at older sites that regard
>   ":" as a <path-delimiter> and have neighbors whose names have 4 or
>   fewer characters, and where all the characters are valid HEX digits.

No, that bit about HEX digits is no longer true if you allow ":" in _any_
<path-diagnostic> (such as a "bare-diagnostic" IYSWIM). If you want to
make it cleat that ":" is not allowed except in an IPv6address, then you
either have to write in a big "MUST NOT", or else you have to write some
ABNF (which I think would be better).

But sooner or later we have to make up our minds what we are going to
allow here, so we might as well do it sooner. Certainly, if we want to

1. make it so that diagnostics are recognisable as such (whether by keyword
or otherwise), and

2. keep open the possibility of the alternative keyword notation,

then it has to go into USEFOR. I grant you that the rest of the details
could then be dealt with in USEPRO.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 20 Dec 2005 07:46:22 +0100

> OK, because any gory details could then be left to USEPRO.

Try telling the difference between a domain name having one component and a 
bareword.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 20 Dec 2005 07:50:42 +0100

Harald Tveit Alvestrand wrote:
 
> Try telling the difference between a domain
> name having one component and a bareword.

              %x5F   SCNR

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 20 Dec 2005 09:27:02 +0100

>> name having one component and a bareword.

Underscore. Sigh. yes.
Note that those are legal in domain names, but illegal in host names; third 
religious war to the right for details...

---

From: Richard Clayton <[email-masked]>
Date: Tue, 20 Dec 2005 10:00:11 +0000

In message <[email-masked]>, Charles Lindsey
<[email-masked]> writes

>>   articles take in moving over the network, and for gathering Usenet

/Usenet //

>>   failed to be so verified.

this sounds as if !! can only appear early on :(  for the third sentence
try:

    The use of the <path-delimiter> "!!" indicates that the agent to its
    left verified the identity of the agent to its right before
    accepting the article (whereas the <path-delimiter> "!" implies no
    such claim.

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 21 Dec 2005 16:55:38 GMT

>Try telling the difference between a domain name having one component and a 

Then you need to say "It usually takes the form of a fully qualified
domain name ...", and/or make some mention of barewords.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 21 Dec 2005 17:00:04 GMT

>    accepting the article (whereas the <path-delimiter> "!" implies no

Yes, that sounds better.

But we still need to reach some conclusion on what to say about
<path-keyword>s, and decide whether to tighten things up sufficiently that
we can truly say that <path-identity>s consisting only of <=4 Hex Digits
are the only ones that need be warned against.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 21 Dec 2005 14:10:27 -0500

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Both changes applied.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Dec 2005 04:26:37 +0100

--On 21. desember 2005 16:55 +0000 Charles Lindsey <[email-masked]> 
wrote:

>>> term or not). "It _usually_ takes the form of a domain name ..." would
>>> be OK, because any gory details could then be left to USEPRO.
>
>> Try telling the difference between a domain name having one component
>> and a  bareword.
>

Did you miss my point?

"The form of a domain name having one or more components" subsumes the form 
of a domain name having one component - "foobar" is just as much in "the 
form of a domain name" as "clerew.man.ac.uk" is - it is just not a FULLY 
QUALIFIED domain name, in the way the term is usually used.

Putting in "usually" would mean that you couldn't tell for sure whether 
non-domain-name constructs like "1...." or "really....silly" were allowed 
as "path-identity". (The grammar does not disallow them.)

That said, there may be good reason for mentioning the case of "bareword" - 
it's an important case for being consistent with existing practice.
If so, propose text.

                         Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 28 Dec 2005 18:14:14 GMT

In <7684C8CF917DC078E129BA27@B50854F0A9192E8EC6CDA126> Harald Tveit Alvestrand <[email-masked]> writes:

>--On 21. desember 2005 16:55 +0000 Charles Lindsey <[email-masked]>=20
>wrote:

>"The form of a domain name having one or more components" subsumes the form =

>of a domain name having one component - "foobar" is just as much in "the=20
>form of a domain name" as "clerew.man.ac.uk" is - it is just not a FULLY=20

>Putting in "usually" would mean that you couldn't tell for sure whether=20
>non-domain-name constructs like "1...." or "really....silly" were allowed=20

>That said, there may be good reason for mentioning the case of "bareword" - =

>it's an important case for being consistent with existing practice.

Well it all depends on how much you want to say here, and how much in
USEPRO. And also on precisely what you want to disallow/discourage.

So I would start from

   A <path-identity> is a name identifying a site.  It usually takes the
   form of a fully qualified domain name or a "bareword".

That is brief, but requires some definition of "bareword". If it is
understood (whether by writing ABNF or otherwise) that it has no "."s in
it, then it is clear that funnies like "really....silly" would be at best
'unusual' (even if syntactically permitted) and you could leave it to
USEPRO to draw the rules tighter (with MUST/SHOULD/MAY/whatever as we may
decide). Alternatively, you could wrap up the whole thing in ABNF (which,
at one extreme, would lead to a syntax such as I have proposed).

However, I would suggest that there are two more pressing things to decide
first:

1. The remarks in the present draft regarding the "dead:beef" matter are
just wrong. I think we are agreed that we don't want to see ':'s anywhere
except in IPv6addresses, and then only in diagnostics/whatever. But do we
want to make that prohibition clear here in USEFOR (which would certainly
need some ABNF), or do we want to do it as part of some "rule tightening"
in USEPRO?

2. How many and which keywords do we want to introduce here? Which is
related to the question of whether we want some way to distinguish
diagnostics from sites (for which a keyword such as "SEEN" would apprear
to be needed). So either we need to define the keywords here in USEFOR, or
else we regard them as "funny kinds of barwords" and give
instructions/conventions for inserting them in USEPRO. To my mind, it
would be much better to try and decide which instructions/conventions we
are aiming towards now, rather than fix the format of USEFOR before we are
quite sure where we are aiming.