ietf-nntp Commetns on draft-15.pdf

[Stan Barber]

I am not commenting on the "Significant Issues" part of Charles post in 
this email. I am only commenting on the "nitpicks" section.

I am only leaving in the sections where I disagree with Charles. 
Anything I left out can be assumed to be in the next revision of 15 
either as Charles suggested it or as some reasonable derivative of the 
suggestion.


> Nitpicks
> --------
> 
> I hope there is nothing particularly controversial in here, though some of
> the issues raised will require some thought to fix them. And I hope
> somebody in addition to Stan will read carefully through this lot to fix
> any errors I have made.
> 
> Line numbers are counted from the top or bottom of a page, not including
> headers or footers.
> 
> P1. S1. Status
> Shouldn't it say somewhere that this document is intended for Standards
> Track?


That's kinda inappropriate for an internet-draft, but I added a sentence 
to clarify this for those that don't know how the IETF standards process 
works.


> 
> P15-13	Please can we have an example with a parameter in it. E.g.
> 		[S] FOOBAR Version-3


Please provide one for consideration.


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


Think this was discussed in another thread.


> 
> P18	{bad page split in the middle of a line of a table}


These things will be handled in the final publication of the draft. 
Don't worry about them here.


> 
> P35-24	the~ -> the
> 	{where '~' is some spurious character - may be an artefact of the
> 	PDF}


Looks that way. I can't find it.


> 
> P40-10	valid.) ->valid).
> 
> P40-4	information.) -> information).


These are sentences that follow sentence fragments. The fragments would 
not be followed by a period if the sentence in the parathesis were removed.


> 
> P43-14	US-ASCII spaces -> US-ASCII TABs
> 	{Surely it is standard practice that a "Newsgroups line" uses a
> 	TAB between the name of the group and the descriptive text -
> 	certainly USEFOR defines it that way both for newgroup and
> 	checkgroups control messages.}



The standard practice is to keep the printable characters and spaces 
where possible. The only exception I know about here is OVER and that's 
because of how it was defined by the creators of the OVERVIEW database. 
USEFOR can define things for control messages however they want to do 
it, but that's not relevant to this WG's efforts.


> 
> P44. S9.4.5.2
> Please can we have a realistic example of a LIST NEWSGROUPS command with a
> wildmat in it?


Sure. Please supply one for consideration.


> 
> P44-10	to LIST EXTENSIONS ->
> 	to LIST EXTENSIONS (assuming LIST EXTENSIONS is supported)
> 	{servers are not obliged to support LIST EXTENSIONS}


Compliant servers that implement any extensions defined in the memo are 
required to suppport LIST EXTENSIONS. This is clarified in the latest 
version of 15.



> P45-7	211 -> 211 n l h ggg {+ verbiage as in GROUP command}
> 	{I find it odd that the 211 response from LISTGROUP is not the
> 	same as the 211 response from GROUP; I also note that the model
> 	NNTP implementation provides the full set of parameters: e.g.
> 	    group comp.risks
> 	    211 1 562 562 comp.risks
> 	    listgroup comp.risks
> 	    211 1 562 562 comp.risks
> 	    562
> 	    . }


I didn't invent LISTGROUP. It will stay as it is.


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



I think this was already covered in another thread.


> 
> P46-9	We need an example of a LISTGROUP with an explicit ggg parameter.
> 	I suggest:
> 	GROUP example. -> LISTGROUP example.



Again, provide one for consideration.


> 
> P47+4	{The news convention seems to be to refer to "headers" in places
> 	where RFC2822 would refer to "header fields". Likewise, RFC 2822
> 	refers to the complete set of "header fields" as "the header",
> 	whereas news (and even many email error messages) refers to them
> 	as "the headers".  USEFOR has consistently used the "news"
> 	convention, and I recommend that this draft does the same
> 	throughout.}
> 	header fields -> headers (including the following colons)


I am not sure what you want here. Are you saying that the current memo 
is not consistent or follows the RFC 2822 definition or what?



> 
> P48-11	subject, author, date, message-ID, references ->
> 	Subject, From, Date, Message-ID, References


I am not sure I understand why this is relevant. Header fields are not 
supposed to be case specific. I don't think RFC 2822 changed this.




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


These commands are here because they are not usually used in a session. 
So, they are defined after all the commands that are usually used in a 
session.






> P56-11	when possible -> (i.e. by including the "GMT" parameter) when possible
> 
> P56-4	000000 -> 000000 GMT
> 	{since we say "GMT" SHOULD be present}
> 
> P60-15	Unnecessary line split
> 
> P60-10	msg-id = <defined in RFC2822>
> 	Sadly, that is wrong, since RFC2822 allows the msg-id
> 		<"123\ 456"@[123.123.123.\ 123]>
> 	which has two SP characters in it. That breaks the rules for
> 	command arguments in our Section 4, and breaks existing software
> 	all over Usenet. In addition, RFC 2822 also contains some obsolete
> 	msg-id syntax which I really think we don't want to know about.
> 
> 	This problem came to light just as DRUMS was entering its 'last
> 	call' phase, so it was not possible to get them to fix it (and we
> 	had already had enough trouble to get them to remove comments and
> 	folding from inside msg-ids).
> 
> 	We got around it in USEFOR by saying
> 		"A msg-id MUST NOT contain any SP within any quoted-pair."
> 	(we had already excluded all RFC2822 obsolete syntax). We also put
> 	a 250 octet limit on a msg-id.



> 
> P61+8,14
> 	The UTF-8 syntax in USEFOR is:
> 
>       UTF8-xtra-2-head= %xC2-DF
>       UTF8-xtra-3-head= %xE0 %xA0-BF / %xE1-EC %x80-BF /
>                         %xED %x80-9F / %xEE-EF %x80-BF
>       UTF8-xtra-4-head= %xF0 %x90-BF / %xF1-F7 %x80-BF
>       UTF8-xtra-5-head= %xF8 %x88-BF / %xF9-FB %x80-BF
>       UTF8-xtra-6-head= %xFC %x84-BF / %xFD    %x80-BF
>       UTF8-xtra-tail  = %x80-BF
>       UTF8-xtra-char  = UTF8-xtra-2-head 1( UTF8-xtra-tail ) /
>                         UTF8-xtra-3-head 1( UTF8-xtra-tail ) /
>                         UTF8-xtra-4-head 2( UTF8-xtra-tail ) /
>                         UTF8-xtra-5-head 3( UTF8-xtra-tail ) /
>                         UTF8-xtra-6-head 4( UTF8-xtra-tail )
> 
> 	where <UTF8-xtra-char> corresponds to <UTF-8-non-ascii> in the
> 	NNTP draft. The difference is that USEFOR has excluded more octets
> 	that are not supposed to occur in UTF-8, including all those which
> 	would belong to Unicode "surrogates". Do we want to make the two
> 	drafts identical at this point, for the removal of all confusion?



It might be more appropriate for one or the other group to publish a 
UTF-8 definition as its own RFC and then have both groups refer to it. 
Trying to keep the two in sync is more than either group should have to 
worry about. I was hoping there would be some DRUMS document that would 
solve this, but given that noone has pointed at one to solve this 
problem, I have to assume there isn't one.


> 
> P63+18	Is it still true that UNIX is a trademark of X/Open?


Officially, X/Open Company Ltd. is the tradmark holder. You can read 
more about it on their web site.


> 
> P63-1	one of the progenitors -> the many progenitors


I'd rather say one or more of the many since not everyone listed 
contributed to every version.


> 
> P64+14	Is the reference to "Bnews" still appropriate?


Yes. Bnews is where NNTP started.


> 
> P64-11	Is the reference to "AUTHINFO" still appropriate?


Yes. There is some text in the memo about authentication and AUTHINFO 
was the reason that that discussion is there.