[NNTP] NNTP URI draft

Charles Lindsey chl at clerew.man.ac.uk
Mon Mar 7 03:47:33 PST 2005


In <87r7itblz4.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu> writes:

>Anyway, this draft documents the news URI and deprecates the nntp URI.
>You can see it at:

>  <http://www.ietf.org/internet-drafts/draft-hoffman-news-nntp-uri-04.txt>

No, there has been further discussion on the uri at w3.org list since then,
and the current version of what I have is shown below. Pete Hoffman was
reluctant to include that text in in his draft-hoffman-news-nntp-uri-*
series until I had obtained some feedback from this (nntp) list and the
udefor list. I called for such feedback a month or so ago, but the only
response was from Frank Ellerman who responded on the uri at w3.org list.

It includes both the news and nntp schemes in full, but there is one
outstanding issue regarding the '*' notation, which is currently
indifferently implemented.


> * Do we want to document URIs for referring to particular news
>   hierarchies, like:

>       <news:comp.*>
>       <news:rec.arts.comics.*>

Yes that is the issue. I don't think it is implemented anywhere at
present, but my view is that if such a notation is adopted, then it would
be better to allow the full wildmat syntax in there.

>   lynx at least does support them and has for some time.

OK, I did not know that.

>   I presume that if we do want to support the above, we don't want to
>   try to allow full wildmat syntax in a URI and instead would limit it
>   to just representing hierarchies.

If it is regarded as a new feature, then allowing the full wildmat would
seem like the obvious move, since any interface to an NNTP server should
have no difficulty in implementing it.

> * The draft tries to deal with some of the message ID complications, but
>   I wonder if we don't have better information in our new base draft.

No, the latest text has removed those complications, and is much the same
as the current NNTP draft, except for an mandatory '@' in the middle.

Anyway, here is my current working text.

2.  The News URI Scheme

   The news URI scheme is used to refer to either news groups
   or individual Netnews articles, as defined in [RFC 1036].

   The news URI takes the form:

      newsURI     = "news:" ( article / group / all-groups )
      article     = [ news-server "/" ] message-id
      group       = [ news-server "/" ] newsgroup-name
      all-groups  = news-server [ "/" [ "*" ] ] / "*"
      news-server = "//" authority
      message-id  = printable-ascii "@" printable-ascii
      newsgroup-name  = 1*%d33-126
      printable-ascii = 1*( %d33-61 / %d63-126 ) ; excludes ">"

   <authority> is defined in [RFC 3986], and provides for a <host>, a
   <port> (defaulting to 119 in this scheme) and possibly a <userinfo>.

   Within a <printable-ascii> and a <newsgroup-name>, the characters
   '%', '@', '/', '?' and '#' are reserved and MUST be %-encoded if they
   occur. All other characters MAY be used freely to represent
   themselves. It is not precluded that future extensions to the Netnews
   standard may permit octets outside of the given ranges, in which case
   they too MUST be %-encoded (except perhaps when used in an IRI [RFC
   3987]).

   If no <news-server> is specified, the resources are to be retrieved
   from whatever server has been configured for local use.

2.1  The newsURI contains an <article>

   A <message-id> corresponds to the <msg-id> of [RFC 2822] and to the
   Message-ID of section 2.1.5 of [RFC 1036], but without the enclosing
   "<" and ">". It MUST be the message identifier of an actual Netnews
   article and hence will in practice conform to the syntax defined in
   [RFC 1036] or in any subsequent standard for Netnews articles. Thus not
   every <message-id> as defined above is valid.

   Observe the delimiter "@" which enables an <article> to be
   distinguished from a <newsgroup-name>.

   The resource retrieved by this URI is the Netnews article with the
   given <message-id>.  In a properly working Netnews system, the same
   article will be obtained whatever server is accessed for the purpose
   (assuming the server in question carried that article in the first
   place and that it has not expired).

2.2  The newsURI contains a <group>

   According to [RFC 1036], the <newsgroup-name> will in practice be a
   period-delimited hierarchical name, such as "comp.lang.perl.modules".

   The resource retrieved by this URI is some means to gain access to
   the articles in the given <newsgroup-name> that are available from the
   given <authority> (usually by invoking a suitable news reading agent
   initialized to access that group).

2.3  The newsURI contains an <all-groups>

   If the newsURI is of one of the following forms:
      <URI:news:*>
      <URI:news://news.example.com/*>
      <URI:news://news.example.com/>
      <URI:news://news.example.com>
   it refers to "all available news groups".  The resource retrieved by
   this URI is some means to gain access to all the newsgroups that are
   available from the given <authority> (usually by invoking a suitable news
   reading agent).

[Issue: Do we really want all those forms? Only the first was in [RFC
1738], but many agents currently accept the others. Moreover, some
agents are known to barf on anything with '*' in it. Maybe the '*' part
of the notation should be dispensed with. I therefore offer two
alternative formulations.]

[1st alternative]

      all-groups  = news-server [ "/" ] / <empty>

   The possibility for <all-groups> to consist of a "*", which was
   present in [RFC 1738] is now obsoleted, and its continued use is
   deprecated. It was, in any case, only patchily implemented.

[That allows the following forms:
      <URI:news:>
      <URI:news://news.example.com/>
      <URI:news://news.example.com>
of which the first may or may not already work on current
implementations (but that is true of the others also).]

[2nd alternative]

      newsURI     = "news:" ( article / group )
      article     = [ news-server "/" ] message-id
      group       = [ news-server "/" ] wildmat

[where <wildmat> is defined in draft-ietf-nntpext-base-*.txt and would
allow the following forms:
      <URI:news:*>
      <URI:news:comp.*>
      <URI:news:*.test>
      <URI:news://news.example.com/*>
      <URI:news://news.example.com/comp.*>
      <URI:news://news.example.com/*.test>

this is an enhancement of draft-gilman-news-url-02.txt and preserves the
"*". It would be readily implemented, but it is quite certain that
nowhere is it implemented currently. It would also be possible to
preserve the <empty> from alternative 1 as well.]

3.  The nntp URI scheme

   The nntp URI scheme is used to refer to individual Netnews articles,
   as defined in [RFC 1036].

   The nntp URI takes the form:

      nntpURI     = "nntp"  ":" news-server "/" newsgroup-name "/" range
      news-server =  "//" authority
      range       = article-number ["-" [article-number]]
      article-number = 1*DIGIT

   Observe, in contradistinction to the news scheme, that the
   <news-server> is not optional here, because the mapping from
   <article-numbers> to actual articles is established independently by
   each server.

3.1  The range is a single <article-number>

   The resource retrieved by this URI is the Netnews article numbered
   by the given <article-number> in the given <newsgroup-name> from the
   given <authority>.

3.2  The range encompasses more than a single <article-number>

   The resource retrieved by this URI is some means to gain access to
   the articles numbered within the given <range> of <article-
   number>s in the given <newsgroup-name> from the given <authority>
   (usually by invoking a suitable news reading agent initialized to
   access that range). A <range> of the form "nnnn-" provides access to
   all articles numbered "nnnn" and above.



-- 
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 at clerew.man.ac.uk      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



More information about the ietf-nntp mailing list