ietf-nntp new Draft available

[Stan O. Barber]

Ade Lovett wrote:
> 
> 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.

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

Both are supposed to be inclusive. I will clarify in the next draft.
> 
>  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.

Okey. UTC was based on the common-practices document. I have no opinion about
it. Others here at IETF 46 aren't too crazy about it either. I have some
interoperability checks to do, but it's probably gone in the next draft.

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

Clarity is good. Words like this will be in the next draft.
> 
>  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/

I will look into these for the next draft.
> 
> 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 will rewrite this to make it clearer in the next draft.