Subject: [NNTP] NNTP URI draft

From: Russ Allbery <[email-masked]>
Date: Sat, 05 Mar 2005 17:29:35 -0800

This was mentioned previously here, but there has also been a request
(from several months ago -- I'm really behind, and I'm sorry about that)
for us to look at this draft more formally.  The goal is to retire RFC
1738, which requires pulling out all of the bits of it that the IETF wants
to keep so that the document can be obsoleted.

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>

It is an individual submission; we may be asked to adopt it if we want to
make a lot of changes.  (I'm not sure that we have the bandwidth for that,
but I'm also not sure that many changes are needed.)

The document is pretty simple.  The two points that I personally noted
might need review are:

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

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

   lynx at least does support them and has for some time.  Right now, the
   document only includes what's in RFC 1738, namely a reference to a
   specific newsgroup (with or without a server), a specific message ID,
   or <news:*> referring to all newsgroups.

   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.

 * 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.
   (Since this is an NNTP URI, not a Usenet URI, I expect it should
   satisfy the NNTP message ID requirements, not the more stringent
   Usenet Format message ID requirements.)  Perhaps the right thing to
   do here is to ask this document to wait for the new NNTP document to
   be published and then reference our message ID definition?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 7 Mar 2005 11:47:33 GMT

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

No, there has been further discussion on the [email-masked] 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 [email-masked] 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.

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

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

>   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: [email-masked]      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

---

From: Russ Allbery <[email-masked]>
Date: Mon, 07 Mar 2005 10:03:46 -0800

Charles Lindsey <[email-masked]> writes:

> udefor list.

So are you taking over as editor of this draft, or is Pete planning on
publishing a new version if you get consensus on other mailing lists?  (I
have no idea why usefor would be involved; this has nothing to do with
usefor.)

> have no difficulty in implementing it.

Hm, actually, given the wildmat syntax that we have in NNTP, this isn't
too bad since that doesn't require character classes (which lynx doesn't
support).  Okay, I think I'm agreeing with you that this wouldn't be too
bad, although that means the draft will have to wait until we publish the
base NNTP standard so that there's a definition of wildmat to refer to.

It's not at all clear to me that we want to support commas and "!",
though.  Maybe the news URL should just use wildmat-item, appropriately
escaped?

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

Which can't be avoided, and I don't really want to change the NNTP draft
at this point.

>       newsgroup-name  = 1*%d33-126

Use the definition from NNTP.  Wildmat patterns, if we add them, should be
a separate production since they act differently.

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

Referring to UTF-8 here would be a good idea to provide some motivation as
to why this might change.

>    article

Bad use of MUST.  Referring to a non-existent article is not a violation
of the standard.  As you've worded it right now, a client would need to
ensure through some other means that the article it's asking for actually
exists before using a news URI referencing it.

I think rephrasing this sentence without using MUST at all is a better
idea.

>    place and that it has not expired).

There's got to be a better way of phrasing this.

>    period-delimited hierarchical name, such as "comp.lang.perl.modules".

I don't see any need to refer to 1036 here or, really, anywhere else in
this document.  Since this is a URI scheme for NNTP, it should be
sufficient to just refer to the NNTP draft, which already defines such
things as message IDs and newsgroup names.

> agents are known to barf on anything with '*' in it.

Tough for them.  It's very clearly in the standard.  I'm comfortable with
adding the forth forms; I think the second form should only be added if

>       group       = [ news-server "/" ] wildmat

although you need to distinguish between a literal group name and a
wildmat, since the latter retrieves a different resource normally (namely
a list of possible newsgroups, rather than taking you directly to a
newsgroup).

It's not clear to me whether we should allow the trailing slash to be
optional.  What did HTTP do here?  I know that browsers support leaving it
off, but is that fixed internal to the browser, or actually allowed in the
protocol?

> It would be readily implemented, but it is quite certain that nowhere is
> it implemented currently.

Whoops.  :)

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

>    all articles numbered "nnnn" and above.

Hm, I see that our current draft doesn't allow -nnn or -.  INN does and
has for basically forever, but RFC 2980 doesn't mention it either.  I'll
start a separate thread about that.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 8 Mar 2005 09:06:33 +0000

> off, but is that fixed internal to the browser, or actually allowed in the

There's two different situations.

If you ask for "http://a.server/a/path", the browser constructs a GET
request:
    GET /a/path HTTP/1.1
to be sent to a.server.

"http://a.server/a/path" and "http://a.server/a/path/" are actually two
different resources. They will result in, respectively:
    GET /a/path HTTP/1.1
    GET /a/path/ HTTP/1.1

What usually happens is that the first generates a "redirected" response
pointing at the second, and the browser makes a second request.

"http://a.server" is a special case. RFC 2616 says that:

    Note that the absolute path
    cannot be empty; if none is present in the original URI, it MUST be
    given as "/" (the server root).

So "http://a.server" and "http://a.server/" both generate the request:
    GET / HTTP/1.1

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Russ Allbery <[email-masked]>
Date: Tue, 08 Mar 2005 08:12:25 -0800

> So "http://a.server" and "http://a.server/" both generate the request:

What I'm wondering is more whether http://a.server is officially blessed
as a valid URL in the syntax, or if the trailing / is syntactically
required.  We should copy whatever HTTP does in its URI syntax.

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 8 Mar 2005 17:29:33 GMT

>have no idea why usefor would be involved; this has nothing to do with

Pete has agreed to incorporate my texts if I can persuade him that the
Netnews community have been consulted and are happy. I put it before
Usefor because they are a likely bunch of people who might want to
comment. Officially, it should be duscussed on the [email-masked] list, but I
am happy for it to be tossed around here for a bit if you are willing.

>..., although that means the draft will have to wait until we publish the

I think we can rely on the [email-masked] process to drag on until the
nntp-draft is well into its IESG review :-) .

>though.  Maybe the news URL should just use wildmat-item, appropriately

I don't see what harm the full wildmat would do. I would imagine that all
any system implementing this form of the URI would do would be to issue a
LIST ACTIVE command with that wildmat, and then say to the user "here are
all the groups you asked about - which one would you like to
read/subscribe/whatever?".

>a separate production since they act differently.

OK, I now have:
      newsgroup-name  = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E 
                          ; excludes "*" "," "?" "[" "\" "]" 
I have omitted the UTF8-non-ascii, because that is covered by the next
bit.

>to why this might change.

Hmmmm! I think a low-profile on UTF-8 would be advisable given previous
furores on that issue. How about:

   .... It is not
   precluded that future extensions for internationalized <newsgroup-name>s
   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]).

>exists before using a news URI referencing it.

Hmmmm! It is really a requirement to be observed by users (for sure, if
they violate it they ain't going to get any article returned). I was
trying to avoid arguments about the syntactic form of a message
identifier, and this seemed a simple way of saying "it MUST be a valid
message-id" without needing to say what "valid" actually meant. Would you
settle for "SHOULD"?

>There's got to be a better way of phrasing this.

It was really aimed at URI-savvy people who might not understand fully the
nature of Usenet. I am open to suggestions for rewording.

>this document.

I think mention of RFC 1036 (or, one day, of USEFOR) is essential
somewhere (after all, the nntpext draft references 1036). What is daid
here is similar to what was said above regarding message-ids. You can
write any <newsgroup-name> you like, but it ain't going to work unless it is
a real one. The wording there actually comes from RFC 1738, which was
exceedingly vague on the whole issue. How about:

   The <newsgroup-name> SHOULD be that of an existing newsgroup, such as
   "comp.lang.perl.modules", and hence will in practice conform to the
   syntax defined in [RFC 1036] or in any subsequent standard for
   Netnews articles.

(cf the wording for message-ids).

> ....  Since this is a URI scheme for NNTP, it should be

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.

>>    it refers to "all available news groups"....

>we're adding wildmat support in general, as in:

It was in RFC 1738, but has anybody actually encountered it in the wild?

It is quite unlike anything in any other URI scheme, whereas the 3rd and
4th forms are typical of many schemes with the meaning of "show me
everything you have", or "show me the default". I am suggesting that we
either drop the "*" bit entirely (my preference) or turn it into something
useful (like a wildmat).

[In any case, the danger with all of those forms is that they may
institute a download of the complete active file. Try that on supernews,
and you will sit there for 5 minuts waiting for it all to appear :-( .]

>a list of possible newsgroups, rather than taking you directly to a

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?

>off, but is that fixed internal to the browser, or actually allowed in the

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 "/".
Consequently, the average user now believes that a "/" in that position is
optional. I think it better to go along with that belief, because that is
what people are going to do anyway, and existing servers seem to agree.

>Whoops.  :)

Indeed. Which is why I ask whether it is really useful enough to bring it
in.

>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. So I don't think
mention of 1036 can be omitted. OTOH, I agree there ought to be a mention
of nntpext.

   The nntp URI scheme is used to refer to individual Netnews articles,
   as defined in [RFC 1036], enabling them to be retrieved via the NNTP
   protocol [draft-ietf-nntpext-base-*.txt].

>start a separate thread about that.

OK. I gather that the conclusion was to make no change there.

---

From: Russ Allbery <[email-masked]>
Date: Tue, 08 Mar 2005 14:24:53 -0800

Charles Lindsey <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> publishing a new version if you get consensus on other mailing lists?
>> (I have no idea why usefor would be involved; this has nothing to do
>> with usefor.)

> comment. Officially, it should be duscussed on the [email-masked] list, but
> I am happy for it to be tossed around here for a bit if you are willing.

Officially, we were asked by the IESG to review the document here, and I
was just way behind on my e-mail.  If something has changed since then, I
haven't heard about it (although I might not have).

Okay, that sounds good.

> I don't see what harm the full wildmat would do.

It just seems weird to me, but in the absence of anything firmer than "it
seems weird," I guess that's okay.  I find the <news:comp.lang.*> very
useful and I've seen it used in practice on real web pages (although it's
been a few years), so it would be nice to support it.

> I would imagine that all any system implementing this form of the URI
> would do would be to issue a LIST ACTIVE command with that wildmat, and
> then say to the user "here are all the groups you asked about - which
> one would you like to read/subscribe/whatever?".

Maybe.  It could just check a local newsgroup list, or do any number of
other things.  But yes, that's what lynx does.

>    be %-encoded (except perhaps when used in an IRI [RFC 3987]).

Works for me.

>> Bad use of MUST.  Referring to a non-existent article is not a
>> violation of the standard.  As you've worded it right now, a client
>> would need to ensure through some other means that the article it's
>> asking for actually exists before using a news URI referencing it.

> Hmmmm! It is really a requirement to be observed by users

Then it's even more absurd.  :)

> I was trying to avoid arguments about the syntactic form of a message
> message-id" without needing to say what "valid" actually meant. 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.

Think of it this way: it's the difference, in C, between calling open() on
a file that you don't have access to (error) and calling open() without a
file argument (protocol violation).

I think it's reasonable to just drop that sentence.  If we want to include
the information there, something like:

    It is used to retrieve the article with that message identifier.

that doesn't use protocol language for something that isn't a protocol
constraint.  Although really this is already covered in the paragraph
discussed below, so I think you can just drop that bit.

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

> It was really aimed at URI-savvy people who might not understand fully
> the nature of Usenet. I am open to suggestions for rewording.

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

I think explicitly stating the globally unique part makes it a bit clearer
what's going on.

> somewhere (after all, the nntpext draft references 1036).

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

This one isn't as much of an issue as the later NNTP URI reference,
though.

> What is daid here is similar to what was said above regarding
> message-ids. You can write any <newsgroup-name> you like, but it ain't
> going to work unless it is a real one. The wording there actually comes
> from RFC 1738, which was exceedingly vague on the whole issue. How
> about:

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

No, bad use of protocol language.  The original is much better.

>> ....  Since this is a URI scheme for NNTP, it should be sufficient to
>> just refer to the NNTP draft, which already defines such things as
>> message IDs and newsgroup names.

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

> It was in RFC 1738, but has anybody actually encountered it in the wild?

Yes.

> everything you have", or "show me the default".

That's great.  I still don't see any point of changing this; it's been
around for years and was in the original standard.

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

> and you will sit there for 5 minuts waiting for it all to appear :-( .]

Quality of implementation issue for your client; i.e., not our problem.

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

>> optional.  What did HTTP do here?  I know that browsers support leaving
>> it off, but is that fixed internal to the browser, or actually allowed
>> in the protocol?

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

>>> It would be readily implemented, but it is quite certain that nowhere
>>> is it implemented currently.

> Indeed. Which is why I ask whether it is really useful enough to bring
> it in.

"Whoops" here means "whoops, you wrote an authoritative-sounding statement
about what NNTP software implements that turns out to have been wrong."  I
thought I already pointed that out.

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

> So I don't think mention of 1036 can be omitted.

I do, here.  I think you're right about the news URI.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 9 Mar 2005 11:39:58 GMT

>> ... Would

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

>    accessed for that purpose (provided the server in question has that

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

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

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

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

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

>about adding the general wildmat form, just a feeling that it would be

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.

>syntax specifies.  If that says the trailing slash is optional, great,

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/ 

>some detail and there's no need to include the whole fairly complex issue

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 9 Mar 2005 12:17:51 +0000

> required.  We should copy whatever HTTP does in its URI syntax.

Sorry, I hadn't had time to look this up, but it seems Charles has answered
it.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 09 Mar 2005 11:04:12 -0800

>  /It is intended to be the message identifier/?

I'm fine with that.

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

>    defined in [RFC 1036] or in any subsequent standard for Netnews

This looks great to me.

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

Sure, sounds good.

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

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

Sounds good here as well.

> But does lynx also support <news:*.test>?

Yup.

> And do other systems support similar stuff?

I don't know, I don't have any other software installed right now that
supports URL syntax and supports Usenet.

 
>       http://example.com:80/ 

Thanks!  That's authoritative as far as I'm concerned.

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

>    (but not necessarily) used in connection with Netnews articles as

That sounds great!  Thank you.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 10 Mar 2005 10:56:09 GMT

>supports URL syntax and supports Usenet.

OK, on that basis it seems like we go ahread with the wildmats. That will
involve a fair rewrite, which may take a while. In the meantime, I shall
report progress to the [email-masked] list (there is nobody there except Frank
Ellerman and occasionally Al Gilman who is taking much interest in this,
so the discussions here have been useful).

>That sounds great!  Thank you.

That all sounds like a consensus :-) .

---

From: [email-masked] (Kai Henningsen)
Date: 11 Mar 2005 11:10:00 +0200

> think you're confusing protocol violations with normal errors.

I think this points out a generic problem with the draft. It's not precise  
enough about what it all means.

What the text SHOULD do, in my opinion. is, for every possible URI,  
specify what sequence of NNTP commands it is supposed to cause, and what  
the result is supposed to be, as much as possible. (Don't the http and ftp  
schemes do that?)

So, for example, news:bla@foo can be explained as causing ARTICLE blaa@foo  
and returning the text returned by that command, if any, or an error  
indication if that command returns one.

Done like that, a lot of the semantic can be punted to the NNTP standard -  
you do not need to care with what is a valid message id, or what happens  
when there is no article for that message id, because the NNTP standard  
already does - you just create inputs to NNTP and report outputs.

That is, IMHO, what an URI spec should be like.

MfG Kai

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 14 Mar 2005 11:13:13 GMT

>the result is supposed to be, as much as possible. (Don't the http and ftp  

No, you can't do that, because it is not obligatory (for the news scheme
at least) to use NNTP (though that will be the case 99% of the time). For
example, when used with the local server, it might access the active file
(whatever) directly. Moreover, even with an NNTP connection, it might
choose to access the newsgroups file or the overview rather than the
active file.

>indication if that command returns one.

That is fine for those forms of the URI that return a single article. But
it is not so clear what is to happen to those forms that simply connect
you to the server and leave it to you what to do next. If it connects you
to a list of groups, is it then suppose to select one to read, or is it
supposed to invite you to select one to subscribe to, or will it depend
whether you are already subscribed? These are all things to be determined
by the local implementation, depending on what sort of news reader it
chooses to connect you to. The standard really shouldn't be caring about
that.

>already does - you just create inputs to NNTP and report outputs.

I don't think there is much semantic to be specified, and I think my
present text already goes as far as is justified.

---

From: [email-masked] (Kai Henningsen)
Date: 14 Mar 2005 14:25:00 +0200

> choose to access the newsgroups file or the overview rather than the

So? Say that if this is done via NNTP, this is how it's done; if it is  
done some other way, the result is supposed to be the same.

> whether you are already subscribed?

Well, that certainly *should* be specified. Otherwise, it's useless.

>These are all things to be determined

No, the standard *SHOULD* specify that. A URI without specified semantics  
is a very bad idea.

> present text already goes as far as is justified.

I seriously disagree.

MfG Kai

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 15 Mar 2005 11:31:14 GMT

>done some other way, the result is supposed to be the same.

Then you just specify what the overall result is supposed to be (which is
what my text does). It is not the job of a standard to tell implementors
how to do their job. Even less so when describing the behaviour of user
agents. And even less so again when making rules for URIs, which are
supposed to be meaningful in all kinds of agents with all kinds of user
interfaces (not just in browsers rendering HTML).

>Well, that certainly *should* be specified. Otherwise, it's useless.

Why? That surely is a user interface issue which is intimately tied up
with whether the program displaying the URI is a web browser, a MUA or a
newsreader, together with whether or how it is connected to a newsreader.
You cannot assume that the program which shows the URI to you is itself
going to perform the NNTP lookup, or whether it is going to punt it to a
separate newsreader (which may or may not then start to worry whether or
not you are subscribed to the groups in question).

>No, the standard *SHOULD* specify that. A URI without specified semantics  

I think it you really want to pursue that line, which seems contrary to
the way URIs are supposed to work, then you had better take it to the
[email-masked] list and put it to the URI experts.