[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #1047 Path field delimiters and syntax - status
In <572CD0E1D0957B0EFAD23738@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> Harald Tveit Alvestrand <harald@xxxxxxxxxxxxx> writes:
>--On mandag, august 22, 2005 11:58:32 +0000 Charles Lindsey
><chl@xxxxxxxxxxxxxxxx> wrote:
>>> Saying that giving a name to your system is REQUIRED by the standards is
>>> a Good Thing, and allows us to positively refuse to allow such idiocies
>>> as using an IP address to identify your server in injection-info.
>>
>> Why is it an "idiocy"? We are talking about globally routable IP addresses
>> which are allocated according to a very well defined procedure. So, in
>> fact, they would actually be safer than "barewords".
>RFC 1958 section 4.1:
> 4.1 Avoid any design that requires addresses to be hard coded or
> stored on non-volatile storage (except of course where this is an
> essential requirement as in a name server or configuration server).
> In general, user applications should use names rather than addresses.
But who said anything about "requiring addresses to be hard coded"?
Every internet protocol that I can think of (certainly email and URLs)
permits IP addresses in the syntax everywhere that domain-names are
allowed. It then goes on to tell you (with varying degrees of firmness)
that IP addresses SHOULD NOT be used without good cause (but the protocols
MUST still accept them and process them correctly). So indeed, there is no
place where they are REQUIRED to be used, but lots of places where they
MAY be used (subject to varying degrees of discouragement, as indicated).
That is all I am asking for in <path-identity>s. The syntax should
_permit_ them (as it will also for "diagnostic" use). But the semantics
(in USEPRO) will provide strong discouragement (as it will also do for
<bareword>s). My currently proposed USEPRO text is:
<Path-identity>s can take the following forms (in decreasing order of
preference):
1. A fully qualified domain name (FQDN) associated with an "A" or
"AAAA" record identifying that news-server, or with an "MX" record
through which its administrators can be contacted; alternatively
an equivalent "CNAME".
2. An encoding of the public [RFC 1918], permanently routable IP
address - <IPv4address> or <IPv6address> [RFC 3986] - of that
news-server. This option SHOULD NOT be used if an FQDN for that
server is available (however, such IP addresses are perfectly
suitable for purely diagnostic identities [reference needed to
later section]).
3. Some other (arbitrary) name believed to be unique and registered
at least with all other news-servers sending articles directly to
the given one. This option SHOULD NOT be used unless the earlier
options are unavailable (e.g. because the server in question is
not connected to the Internet), or unless it is of longstanding
usage and cessation would be unduly disruptive, or unless one
of the earlier options is provided as well.
NOTE: A news-server administrator who chooses a name which turns
out not to be unique will have to bear the consequences.
NOTE: The syntax permits the colon character (which, prior to
this standard, was a <path-delimiter>) within any <path-
identity> which is in the form of an <IPv6address>. It would
therefore be unwise to choose, as such a name, anything composed
solely from four (or less) hexadecimal digits.
[The precise text is up for discussion, of course, and I just noticed that
the mention of MX records may need to be toned down.]
>That's been an Internet architectural principle for 10 years, and we have
>LOTS of experience in what happens when you violate that principle.
Whay I am proposing seems exactly in conformance with that architectural
principle.
>I stand by "idiocy".
--
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: chl@xxxxxxxxxxxxxxxx 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