[NNTP] Re: Updated news-nntp-uri I-D

Charles Lindsey chl at clerew.man.ac.uk
Fri Nov 16 09:59:48 PST 2007


In <Jr3GvF.L1x at clerew.man.ac.uk> "Charles Lindsey" <chl at clerew.man.ac.uk> writes:

>>Russ agreed somewhile back that this document could be discussed on the
>>nntp mailing list (ietf-nntp at lists.eyrie.org) which, now that RFC3977 is
>>agreed, is still maintained to watch over future nntp developments such as
>>this. This message is therefore copied to that list, and I shall comment on
>>the draft there.

>OK, so my comments follow. They are mostly wording niggles, but there are
>some serious issues also.

>>                    The 'news' and 'nntp' URI Schemes
>>                     draft-ellermann-news-nntp-uri-06

Frank has now published draft-ellermann-news-nntp-uri-08 in response to my
comments (pity he did not come on here first to discuss them). Largely, he
has accepted all my cosmetic suggestions, but totally ignored my technical
ones. Here follows his latest "Document History" section, and I shall
comment on that.



Appendix C.  Document History

   Changes in version 08:

   o  Many editorial and stylistic improvements proposed by Charles
      Lindsey adopted wholesale.

Fine!

   o  Adopted Charles' proposal to simplify the acknowledgements.  It is
      possibly not generally interesting who helped to figure out
      <pchar>, but suggestions to overrule STD 66 [RFC3986] in this memo
      are futile.  One or two contributors are unfortunately buried in
      an mbox on a SCSI-2 disk I can't read at the moment.  You know who
      you are, please send me a mail.

Fine!

   o  Added another URI security consideration. ..

Fine!

      ...... Added another note why
      this memo does not try to cover more NNTP features.  Refrained
      from adding expectations what future NNTP servers will do.  The
      author hopes that Netnews will survive, and that this memo helps.
      Adding features known to not work everywhere would be
      counterproductive.

But not that one. You have added:

      ...   This
      memo intentionally limits its description of the 'news' URI scheme to
      essential features supposed to work with "any browser" and NTTP
      server.

But that is blatantly untrue. What you propose will not work with "any
browser" (specifically ones that conforms rigorously to RFC 1738, though
most nowadays go beyond that), nor with an NNTP server that conforms
rigorously to RFC 977. Indeed you contradict yourself later on where you
admit:

      ... User agents and NNTP servers not yet compliant with [RFC3977] do
      not implement all parts of this new feature.

The point at issue is the extent of wildcarding to be allowed. You propose
to allow anything in a <wildmat-pattern> [RFC 3977]. I want to see the full
<wildmat>.

Present implementations of the news: URI support varying degrees of
wildcarding, from the minimal single "*" of RFC 1738 through all sorts of
ad hoc notations allowing "*" in more or less liberal contexts. I doubt if
any of the support even <wildmat-pattern> fully (and for sure most of them
don't).

But surely implementations will steadily move towards full [RFC 3977]
support (and if they don't, then the NNTP WG will have been wasting its
time). So why not permit the full <wildmat>? For surely all that future
user agents need to do is to take the <newsgroups> from the URI and offer
it to the LIST ACTIVE command of the NNTP server; if it works, it works,
but if not then you have a pre-3977 server, and that might not even
understand all <wildmat-pattern>s. But in the long term it will all come
right.

I would like to see some proper discussion of this matter, and this list
is the place to discuss it because this list is where the proper NNTP
expertise is to be found.

   o  Rejected a proposal to "undocument" 'snews'.  In 2006 folks on the
      URI lists preferred "document and deprecate".  At this time
      'snews' was supported by at least two servers and two user agents.

Point taken!

   o  Created another IANA ticket #124141 and rejected a proposal to
      ignore BCP 65 [RFC3405].  Registering 'nntp' in the style of the
      existing 'ftp', 'http', and 'mailto' DDDS records is a mere
      clerical task.

I never asked for BCP 65 [RFC3405] to be ignored. But RFC3405 is one of
the more obscure RFCs (I doubt if it is widely inmplemented or used), and
so I wanted to see some additional explanatory text at that point so that
the casual reader of your document could tell what you were talking about
and why that IANA registration was a sensible thing to do without having
to make an unnecessary trip to 3405.

   o  Rejected a proposal to derive from the <msg-id-core> syntax in the
      normative reference [I-D.ietf-usefor-usefor] reflecting a
      consensus of the IETF USEFOR WG formed after months of
      discussions.

Eh?  The USEFOR WG spent months refining that <msgid> text, but it never
ever discussed its usage in URIs. All I want is for you to refer
normatively to the syntax of <msg-id-core> in the USEFOR draft (or
alternatively to incorporate that syntax in toto) instead of inventing
yet-another syntax (similar nut not identical) to describe the same thing.

As to whether that syntax in USEFOR gets altered in the light of recent
developments in RFC 2282bis is a matter for the USEFOR WG to address (and
I intend to raise it there). But if your document simply refers
normatively to what is in USEFOR, then you are covered either way.

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