ietf-nntp Commetns on draft-15.pdf
Charles Lindsey
chl at clw.cs.man.ac.uk
Wed Jan 2 03:51:57 PST 2002
In <3C32603A.40803 at academ.com> Stan Barber <sob at academ.com> writes:
>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
>> --------
>>
>>
>> P15-13 Please can we have an example with a parameter in it. E.g.
>> [S] FOOBAR Version-3
>Please provide one for consideration.
I suggest [S] EXAMPLEEXTEN Version-3
>>
>> P40-10 valid.) ->valid).
>>
>> P40-4 information.) -> information).
>These are sentences that follow sentence fragments. The fragments would
^^^^^
ITYM should
>not be followed by a period if the sentence in the parathesis were removed.
OK, I see the convention you are following now, but in that case I would
suggest
P40-10 valid.) ->valid)
P40-4 information.) -> information)
>>
>> 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.
Eh? Standard practice is to store the Newsgroups file with TABs after the
newsgroup-name. Tale always supplies them in that form (with some arcane
rules concerning how many TABs there should be). So why do you want LIST
NEWSGROUPS to provide them in other than that standard format? USEFOR was
merely confirming existing practice in this regard. At the least you
should say "one of more US-ASCII spaces or TABs".
>>
>> 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.
How about:
[S] 200 NNTP Service Ready
[C] LIST NEWSGROUPS *.test
[S] 215 information follows
[S] alt.test Alternative subnetwork testing.
[S] biz.test Biz newsgroup test messages.
[S] misc.test For testing of network software. Very boring.
[S] .
>> 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.
Then in that case you need to change the example so as not to suggest that
the "n l h ggg" is to be expected. And maybe also some text to draw
attention to the anomaly (Greg Andruk has posted some suggested wording).
>>
>> 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.
[S] 200 NNTP Service Ready
[C] LISTGROUP
[S] 412 no current group
[C] LISTGROUP example.is.sob.bradner.or.barber
[S] 411 no such group
[C] LISTGROUP
[S] 412 no current group
>>
>> 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?
No, I am saying that the current memo does follow the RFC 2822 convention,
but that common usage within the Usenet world does not follow that
convention and USEFOR has therefore chosen to follow what the Usenet world
actually does (as did Son-of-1036). I was suggesting that the NNTP draft
might do likewise.
Observe that RFC 1036 itself seems to use "header", "field" and "line"
synonymously, which is the worst of all worlds.
>>
>> 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.
There is a convention that headers are always quoted that way (even RFC
2822 adheres to it when mentioning them). I was just suggesting that you
did likewise.
>>
>> 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.
No, I don't see that a separate RFC is called for. The syntax I gave above
is entirely consistent with the official definitions for UTF-8 and UCS-16
Clive and I checked them very carefully when arriving at that syntax in
USEFOR, and so I was suggesting that you might like to follow that lead.
But no gret harm arises if you do not. The Usefor syntax is a proper
subset to what you have presently.
Perhaps Clive would like to comment on this.
>>
>> 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.
Yes, that would be fine.
--
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 clw.cs.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