ietf-nntp Charles's nitpicks

[Clive D.W. Feather]

Charles Lindsey said:
> P12-2	to not require -> not to require
> 	{split infinitive}

What is wrong with a split infinitive ? This is English, not Latin.

> P15-18	503 -> 502
> 	{I think so; certainly not 503}

Which command is this ?

These are generic response codes. They don't need to be described (except,
perhaps, in a short list of generic codes in the response section; I've
talked about this before).

> P16-3	{Why 16 digits? If the maximum is 4,294,967,295, then that is 10
> 	digits}

Because you SHOULD NOT use leading zeroes, but must still be prepared to
handle them. So it would be legal for a client to send the command
"ARTICLE 0000000000000001". The hard limit of 16 was to allow either side
to use a fixed size buffer.

> P22+6	From: nobody at whitehouse.gov (Demo User) ->
> 	From: "Demo User" <nobody at whitehouse.gov>
> 	{The former usage is now deprecated both in RFC 2822 and in
> 	USEFOR; you need to scan for all occurrences of "Demo User" to fix
> 	it}

Could we also switch to a ".invalid" address ?

> P36+1,2	to immediately determine -> immediately to determine
> 	{split infinitive}

Vid.sup.

> P46+7	211 2000 3000234 3002322 -> 211 6 300234 3002322
> 	{since you give only 6 groups in the example, the "2000" is hardly
> 	realistic; moreover 2000 is impossible given those high/low
> 	watermarks}

Um, 3002322-3000234 = 2088, according to my calculator.

> P53-17	I find it odd that the commands DATE, HELP, NEWGROUPS and NEWNEWS
> 	are described _after_ the CONCLUSION step, and even after the
> 	Extensions.  I would recommend some section re-ordering here (but
> 	I don't think I want a wholesale re-ordering as some others have
> 	suggested).

I disagree: the current ordering is highly confusing. All extensions should
be listed after all mandatory commands. QUIT ought to be the last mandatory
command.

This re-ordering isn't hard and I thought it had consensus.

> P55-20	It says there is no way to establish the server's timezone. This
> 	would not be correct if the DATE command used the server's local
> 	time.

Only true if you (a) know this, (b) know the current time in UTC, and (c)
know that the result from DATE is reasonably accurate.

[Various syntax issues]

I thought we were ignoring the syntax section until the rest of the
document was about done.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 20 8371 4037
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |