ietf-nntp new Draft available

[Ade Lovett]

On Fri, Nov 05, 1999 at 01:58:19AM -0600, Stan Barber wrote:
> 
> The next draft is available in the usual place:
>	ftp://ftp.academ.com/pub/nntp/ietf/nntpext.txt.
> 
> The diffs are available as well:
>	ftp://ftp.academ.com/pub/nntp/ietf/nntpext-diffs.txt.


A few things here - cosmetic ones first:

 1.  in various example transactions, there are plenty of cases
     where real domains are being used, eg: whitehouse.gov, nowhere.to

     these should all be changed to use the IANA reserved
     domains 'example.{com,org,net}'

 2.  References to other RFC's are inconsistent, with some
     being "RFC xxxx", and others "RFC-xxxx".  Choose one format,
     and stick with t.


Now the other stuff:


 3.  Section 9.4.9 (PAT), regarding ways to specify a range of
     articles.

     (a) In the case of "X-", it is not clear whether "all following"
	 means any articles with a number greater than X, or
	 greater than or equal to X.

     (b) for completeness sake, add in "-X", meaning all articles
	 up to and including "X".  Since article numbers are always
	 numerically positive, there is no potential for a clash.


 4.  Section 11.3 (NEWGROUPS)

     Remove all references to "UTC", it's not in RFC822
     (though "UT" is - those Longhorns get everywhere :), and RFC1036
     explicitly refers to GMT as Universal Time.


 5.  Section 7.1, paragraph 4.  Not completely clear on what the
     server should do after sending a 502 greeting code.
     Suggested re-wording:

	The server MUST present a 502 greeting code and immediately
	close the connection, if the client is not permitted under
	any circumstances to interact with the server.


 6. Section 7.1.2 (MODE READER), paragraph 1, line 3.

	... The server MUST present a greeting code ...


 7. Section 8, paragrah 1, line 1

	s/should/SHOULD/


 8. Section 8.1.1, paragraph 3 states that each line listing an
    extensions ... begins with a single [non-optional] space ...

    However, the example reply does not show this space.


 9. Section 8.1.3, paragraph 2, line 1

	s/should/SHOULD/

    or, better yet, since based on past experience, ambiguities
    cause much pain between client and server authors:

	s/should/MUST/


10. Section 8.1.3, paragraph 3, line 3

	s/must/MUST/


11. Section 8.1.3, paragraph 4, line 2

	s/should/SHOULD/


12. Section 8.1.5, paragraph 2 does not make sense.
    If "a particular extension is required for the client to
    properly operate", how would configuring "itself for the
    basic NNTP functionality", help at all?

    If the client NNTP _requires_ an extension that isn't available,
    then it's only course of action is to bail the connection.

    Note the "requires" in the above sentence.  This is not the same
    as a client being able to operate "better" given the existence
    of a set of extensions, and where it may have a fallback option
    (eg: using XHDR and local regexp matching in the absence of PAT) 


I'm sure there's more..

-aDe

-- 
Ade Lovett, Austin, TX.