Re: snews 4395-review

Charles Lindsey wrote:

> this all started with two rival drafts

Actually it started with what looked like a mere clerical task, update
some schemes more or less defined in 1738 to state of the art 3986.

So far Paul finished off wais, prospero, gopher, and telnet.  For the
rest of the zoo it either wasn't 100% clear what to do (especially the
file-scheme), or the timing was bad (news and nntp) because the base
drafts weren't ready.  For ftp I forgot what the problem was.  I liked
the plan to document what's actually used, and update only the syntax
as required for 3986.  Now after 3997 etc. are published and Usefor had
its "last call" the situation is clearer.  Nobody's going to screw up
the <msg-id-core> and <newsgroup-name> syntax anymore (maybe the IESG
could still try that, if they put on their best asbestos).

> the 'snews' scheme is currently not registered at all AFAICS.

Yes, and that's suboptimal, after all it was implemented in some UAs.

> is it actually necessary to register it, even as historical, at this
> stage?

s/even/only/.  The original Gilman-concept were unified news- and nntp-
schemes.  Based on that it made sense to say that one size fits all,
and to pick news as preferred name for the unified scheme.

And then it's also clear that some "S" variant would be snews or newss.

BUT - there must be a but - it didn't work exactly following this plan,
a grammar where the server name is optional is fine for Message-IDs
and newsgroup names, and fails for article numbers.

For anything with an article number the server name is required.  And
while the difference between "it has an @ or it doesn't have an @" is
obvious it starts to get messy if all access metods (by server, by
group name, by article number, by message-id, and maybe even by range
or by wildmat) are lumped together in one unified scheme.

That's why the Gilman draft made it only partially (my crystal ball
says), the "by article number or range" stuff was too confusing.  And
that left snews in limbo, because snews is defined to be like news,
only using nntps instead of nntp.  That's also what everybody would
intuitively expect: "like news".

But for the news-scheme the server is optional, and snews without a
server name makes no sense, what should it be, some kind of default
nntps server, maybe different from the default NNTP server ?

Without a unified scheme "snews" is just a bad name.  It should be
nntps, because it inherits the "server required" from the nntp-scheme.

On the other hand it can handle Message-IDs like the news-scheme, the
nntp-scheme can't (unless it's a unified all access methods version).

Therefore the best description of this mess is "historical", and say
what snews did.  It could deal with a specified server name plus an
optional newsgroup name or Message-ID.  Using nntps without STARTTLS.

So far that's simple, and it's also simple to note it as "historical".

As soon as somebody tries to improve it, using RFC 4642 depending on
the port number (IMO a bad plan), or otherwise "direct nntps", it's
again too messy for a mere registraton template, and I'd kick it from
the news and nntp draft, because it's incompatible with it.  It would
only make sense based on a unified scheme (if at all), and I'm not
trying to unify news and nntp.  RFC 1738 also didn't.  And your draft
also didn't.   And in common practice it's AFAIK also not unified.

That results in "it should be historical, because it doesn't work as
expected without unification", and "if it's historical the best place
to say so is the news and nntp draft".

> that is how RFC 4642 leaves it, and I-D.gilman-news-url-02 foresaw
> that happening.

Yes.  And if Roy wants to resurrect it somehow it would deserve its
own I-D, there should be no problem to change "historical" later to
"permanent" for an in essence new scheme if that happens (unlikely in
practice, but in theory RFC 4395 doesn't say "once historical forever
historical").

> I question whether the template needs to be so long and detailed.

For the semantics part I got an update, not shorter, but better than
my text.  For the interoperability "was not widely implemented" is an
important detail for implementors, otherwise they might be tempted to
support it anyway (but as explained above it won't work as expected).

Security is as short as possible, "see 4642 and 2595".  Anything else
is already minimal, the long template field names are taken from 4395.

> for a historical scheme, I would expect a reference to gilman's
> original draft somewhere

|   References:        RFCXXXX, [RFC4642], [I-D.gilman-news-url]

If IANA stores the registration template outside of its context
they'd derefrence [I-D.gilman-news-url],  I doubt that they do this,
but it's clear how to do it if they want it.

> But there is no need for the template to explain how to use it, or
> to suggest that it would necessarily include any fresh news features
> from the present draft.

That's not the case, there are no fresh features in relation to the
Gilman draft, he already had "*" everywhere (for <wildmat-pattern>),
and he had an overall "like news" (for his unified scheme).

The only new feature today would be the (encoded) question mark in a
<wildmat-pattern>, but that's only a theoretical side-effect of 3997.

Wasting prose for this ?-detail in a historical scheme is pointless,
the draft clearly says that it's "not yet" supported by many UAs and
servers.  Folks will avoid the %3F feature if they can read between
the lines for news URLs, that's no special incompatibility wrt snews.

> I think you need to provide full templates for the news and nntp
> schemes, since the present registrations refer to RFC 1738, and that
> document contains no templates.

| The IANA registry of URI schemes could be updated to point to this
| memo instead of [RFC1738] for the "news" and "nntp" URI schemes.

They are already registered, only the defining document changes.  It
is a grandfathered case, no new registration.  For an RFC on standards
track "change controller = IETF" etc. is implicitly clear

Paul's 4266 (gopher), 4248 (telnet), etc. have no IANA section at all
in the published form, apparently that's good enough for grandfathered
cases.

> I was quite mystified by:
> 8.2.  nntp.uri.arpa NAPTR
>     This section contains the [RFC3405] template for the registration of
>     the "nntp" URI scheme with the Dynamic Delegation Discovery System.
[...]

I was also mystified when I stumbled over this one (there's even a IANA
mailing list for such registrations).  The author of 3405 registered http,
ftp, and mailto.  I'm not sure if the regexps are as they should be, and
I'm a bit pissed that nntp was as always ignored.  In theory folks could
identify the host (without userinfo) in an nntp URL, using the NAPTR or
common sense, and figure out alternative servers for the found domain if
somebody bothered to create the necessary NAPTR / SRV / A records.

At the moment I don't know why anybody would wish to do this, but there
are real cases where it might be a good idea (in theory).  One of these
cases is news.clara.net:

195.245.201.101  proxy01.news.clara.net
195.245.201.102  proxy02.news.clara.net
195.8.68.207     iris.uk.clara.net
195.8.68.209     despina.uk.clara.net
195.8.68.218     demeter.uk.clara.net
195.8.68.222     damia.uk.clara.net
195.245.201.100  proxy00.news.clara.net

Admittedly I didn't use NAPTR to get this list, it's a homebrewn script
trying to emulate `host`.  But sometimes I needed a server name behind
news.clara.net, if something in their load balancing was broken, and an
alternative name still worked (I've configured damia as backup for such
cases for some years now, but needed to change this once).

> I had never heard of the Dynamic Delegation Discovery System, and it
> took me a couple of hours to figure out what it was all about.

Same here.  I only knew S-NAPTR (straight forward NAPTR) because the
IRIS / CRISP folks use it.  And my heuristics to guess whois server
names for TLDs _is_ black magic and unreliable.  The S-NAPTR stuff is
also some kind of black magic, but at least a clean theoretical concept.

The DDDS uri.arpa concept is apparently a predecessor of S-NAPTR (nick
name "napstr").  That's all I know about it, or rather guess, the ENUM
folks also use it.  Probably the SPF folks didn't know that it exists,
(I certainly didn't know it until I read some CRISP drafts this year).

We don't need to discuss what a BSD nslookup vintage 1991 compiled for
OS/2 1999 by IBM thinks about DNS record types SRV or NAPTR today. :-(

> it is impossible to discover which *.uri.arpa domains actually exist

Urn (in the RFC), http, ftp, and mailto (on the IANA mailing list).

> What format has been used in other RFCs that create *.uri.arpa domains?

I've posted URLs to get the dig output for ftp.uri.arpa (etc.) here,
see <http://permalink.gmane.org/gmane.org.w3c.uri/894>

And in the document history of the news+nntp-URI draft I repeated that:

| o  The IANA registration template for an "nntp.uri.arpa" NAPTR record
|    was added.  If that record is correct the existing "ftp.uri.arpa"
|    and "http.uri.arpa" records could be updated, apparently they
|    don't remove the optional <userinfo> at the moment.

> And why did you not create one for news.uri.arpa as well? Because its
> server might be empty?

Yes.  And because scheme-name != protocol-name would be confusing, one
NAPTR regexp for nntp is good enough (or already too much).

> how are nntp server admins supposed to take advantage of this facility

No idea, they do odd stuff, use NNTP for file sharing with yenc and what
else, and if registering nntp only takes ten lines in a draft, why not.

If nobody ever uses it, no harm done, otherwise it's ready to be used.
For an example where it could make sense (in theory) see above.  We both
never used ftp.uri.arpa so far, IMO nntp.uri isn't worse or better.

The RFCs 3401..3405 are relatively new (2002), maybe they wait for some
interesting applications (ENUM + CRISP is a start).  RFC 3405 says that
registering is simple if it's in the same document as the scheme.  And
it is a BCP.

Frank

Received on Wednesday, 15 November 2006 19:00:43 UTC