[NNTP] NNTP URI draft

Charles Lindsey chl at clerew.man.ac.uk
Wed Mar 9 03:39:58 PST 2005


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

>Charles Lindsey <chl at clerew.man.ac.uk> writes:

>>>> 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


>> ... Would
>> you settle for "SHOULD"?

>No, because again, using a nonexistent message ID is not a protocol
>violation any more than sending an NNTP command "ARTICLE <id>" where <id>
>doesn't correspond to an existing article is a protocol violation.  I
>think you're confusing protocol violations with normal errors.

How about

s/It SHOULD be the message identifier
 /It is intended to be the message identifier/?

What I am trying to indicate is that it is limited, in practical terms, to
the format defined in RFC 1036 or whatever. So I now have:

   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 is intended to 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.



>>>>    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).


>How about:

>    The resource retrieved by this URI is the Netnews article with the
>    given <message-id>.  Message identifiers are required to be globally
>    unique, so the same article will be obtained whatever server is
>    accessed for that purpose (provided the server in question has that
>    article available).

Yes, that's better. Would you buy s/will/should/?


>>>> 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".


>Yeah, I thought about this some more and changed my mind, since after all
>1036 does define the format of the resource that one gets back.  Although
>it's not at all clear to me that this is the right reference for newsgroup
>names in particular, since in practice the news URL can be used with any
>NNTP-supported newsgroup name (which is a richer set than RFC 1036).

The syntax I have given for <newsgroup-name> is as in the NNTP draft. But
it is like message-id - it won't work unless it conforms to 1036/whatever.
So it needs a similar wording to the message-id case.


>>    The <newsgroup-name> SHOULD be that of an existing newsgroup,

So it now says "The <newsgroup-name> is intended to be that of an existing
newsgroup, ..."


>> Actually, it isn't just a URI scheme for NNTP. It might be used to
>> access a local server directly, or it might be used to retrieve
>> groups/articles from an IMAP server. Which, come to think of it, is a
>> good reason NOT to use wildmats.

>Yeah, although in practice the chances of someone doing that are pretty
>remote.

Since when has that been a bar to the IMAP people :-) ?


>> I am suggesting that we either drop the "*" bit entirely (my preference)
>> or turn it into something useful (like a wildmat).

>It already is a wildmat, if we adopt wildmats, which is fine with me.  It
>needs to stay regardless of whether we adopt wildmats or not, though; it's
>simply not okay to just willy-nilly deprecate stuff that's being used when
>there isn't any inherent flaw in the specification.

I think is is usual for a feature that is redundant, not particularly
useful, and which is known to have been badly (or not at all) imlemented
in some systems to be deprecated in a later standard. However, if we go
the wildmat route, then it obviously stays (and grows).


>> Yes, that would have to come in the rewording if we adopt that
>> alternative. But, having realized the possible use of IMAP and other
>> servers with this URI, I am getting rather doubtful. Is the facility
>> likely to be useful enough to be worth the trouble? As I said above, did
>> the "*" ever actually happen in the wild?

>Well, like I said, I find it useful and have certainly seen it used (in
>fact, the <news:comp.lang.perl.*> form is used a lot more than the
><news:*> form, although both are used).  I don't have a strong opinion
>about adding the general wildmat form, just a feeling that it would be
>nice.

But does lynx also support <news:*.test>? And do other systems support
similar stuff? I would be much happier going the wildmat route if that
were the case.


>> As Clive has just shown, HTTP did all sorts of amazing things, the net
>> effect of which was that you got the same effect with or without the
>> "/".

>Clive didn't actually answer my question, which is about what the URI
>syntax says, not about what user agents do.  NNTP user agents can also
>autocorrect the URI if need be; what I want to copy is what the HTTP URI
>syntax specifies.  If that says the trailing slash is optional, great,
>that's all I want.

Well here is a quote from RFC 3986 (which is the umbrella for all URI
schemes - I don't seem to have the actual HTTP spec to hand):

   The syntax and semantics of URIs vary from scheme to scheme, as 
   described by the defining specification for each scheme. 
   Implementations may use scheme-specific rules, at further processing 
   cost, to reduce the probability of false negatives.  For example, 
   because the "http" scheme makes use of an authority component, has a 
   default port of "80", and defines an empty path to be equivalent to 
   "/", the following four URIs are equivalent: 
 
      http://example.com 
      http://example.com/ 
      http://example.com:/ 
      http://example.com:80/ 


>>>> 3.  The nntp URI scheme

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

>>> Again, refer to NNTP not RFC 1036.  (Even more so here, since the whole
>>> concept of an article number is purely an NNTP construction.)

>> Yes, but this is the introductory remarks introducing this URI, and
>> getting hold of Netnews articles is its whole purpose.

>No, it's not.  That's the whole point of the news URI.  The whole point of
>the nntp URI is to access an NNTP server, which is not limited to serving
>Netnews articles.  Please refer to the NNTP standard for the nntp URI, not
>the Usenet article standard; the NNTP standard will cover this point in
>some detail and there's no need to include the whole fairly complex issue
>again here.

But serving Netnews articles is its primary purpose (see 1st paragraph of
the Introduction section of nntpext).

How about:

   The nntp URI scheme is used to retrieve individual articles
   via the NNTP protocol [draft-ietf-nntpext-base-*.txt]. It is usually
   (but not necessarily) used in connection with Netnews articles as
   defined in [RFC 1036].

-- 
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