Re: snews 4395-review

Roy T. Fielding wrote:

> Traditionally, all of the "s" schemes mean that a secure connection
> must be used to access the resource.  The notion of secure-before-access
> is a common pattern that applies regardless of STARTTLS support -- it
> says that some form of secure connection is required with the access.

For snews my conclusion was "dedicated port" (same idea as https) and
no STARTTLS.  In I-D.gilman-news-url-02 (1998) I found about "snews":

| This current usage may be deprecated in the future for security
| reasons should suitable provisions for security protocol negotiation
| over the standard NNTP port of 119 be standardized in the future.

That happened in RFCs 4642 and 4643 some weeks ago, and RFC 4642 offers:

| In some existing implementations, TCP port 563 has been dedicated to
| NNTP over TLS.  These implementations begin the TLS negotiation
| immediately upon connection and then continue with the initial steps
| of an NNTP session.  This use of TLS on a separate port is
| discouraged for the reasons documented in Section 7 of "Using TLS
| with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
|
| This specification formalizes the STARTTLS command already in
| occasional use by the installed base.  The STARTTLS command rectifies
| a number of the problems with using a separate port for a "secure"
| protocol variant; it is the preferred way of using TLS with NNTP.

For the registration of "snews" as historical I've to combine these
two statements somehow.   If you think that "(no STARTTLS)" doesn't
belong in the "semantics" part of the template I can delete it - does
that help wrt your concern ?

> One way to deploy such a change is to say that if the port is empty
> or 563, then initiate TLS first; otherwise, do RFC4642.

The registration template claims that this scheme is deprecated, it's
not the best place for instructions how to implement it anyway for use
with new RFC 4642 servers.

If <snews://some.example:119/unique@domain> would get a semantics
different from no port or 563 it would be confusing.  And maybe wrong,
RFC 4642 is relatively new.  Some "nntps" server might require snews-
URIs with a different port, but not (yet) support RFC 4642.  I'm not
aware of such "nntps" servers, but I also couldn't prove a negative.

> In any case, snews is not a historical scheme.

 From my POV it is.  Especially the part where it's syntactically the
same as the news-scheme.  The news-scheme is based on the concept of
worldwide unique Message-IDs, and worldwide Usenet newsgroup names,
no matter what NNTP server, let alone secure access on it.

Therefore the <server> part in news is optional, for rare cases where
a group or article is only available on a dedicated NNTP server, and
not more or less "anywhere".

The snews scheme has a bad name for this analogy, it should have been
nntps, because for the nntp scheme the <server> part is required.

The original idea of the Gilman draft was obviously to unify the news
and nntp schemes as news, and later it added snews in its version -02.

Some years later common practice is to use nntp URIs as in RFC 1738 if
at all, news URIs as in the Gilman draft, and the snews URIs are even
rarer than nntp URIs.

A unified syntax would be tricky if you look into the Gilman draft, it
would rely on newsgroup names always different from article numbers.
The new NNTP RFC and the new Netnews article format I-D don't offer
this as MUST, the latter has a SHOULD.

For your proposal of a permanent registration we'd get something in
the direction of "despite of its name snews has otherwise the same
semantics as the nntp scheme".  And probably that would not be true
for the historical uses.  Let's please just get rid of snews as cruft.

Frank

Received on Friday, 10 November 2006 20:35:25 UTC