ietf-nntp Comments on NNTP SEARCH

[Rich Salz]

Some notes on the draft of 4 October.

2.  The abstract should probably mention that this document introduces
the new concept of virtual groups.

3.  "The new SEARCH NNTP command"; remove "NNTP" -- confusing (is the
command "search" or "search nntp"), and not needed -- this is an NNTP
spec.

3/para2.  Virtual groups can also be implemented using "lazy evaluation",
performing upates only when a client enters the group, right?

3.1: "LIST SRCHFIELDS".  as in my other email, this should not be a
short name

3.1: "The LIST SEARCHES command allows..."  it allows the client to determine
which groups are full-text searchable, not full-tex indexed and therefore
searchable. A minor distinction; the current wording mandates implementation
style.

3.1: "The XPAT command has..." allows the psuedo-header ":TEXT".  Or
virtual or synthesized.

4.2: "OVER extension" and elsewhere: "explicitly include ... in the list
of extensions it supports."  Those first two words (and that phrasing is
used throughout) are confusing.  Perhaps "must support the ... extension"
is a better way of wording it?

4.3: see 4.2 comments above

4.4: see 4.2 comments above

5.3: Can the returnvalue for any GET ever be multiline text?

5.4: Isn't "-32" a legal range meaning from the beginning up to and including
article number 32?

5.4, "The SET command may be used...":  Should there be a forward reference?
Should probably also call out that this is the biggest difference
between OVER and XOVER.

5.4, following paragraph: What about when the client specifies fields the
server doesn't undertand.

5.4, last paragraph: Strike the colon after Lines.  Does this paragraph
mean to imply that Lines and Bytes MUST be supported?  If so, I disagree.

5.4, general: there should probably be the concept of read-only
attributes.

5.6 example output: Should the "/t" really be "\t" to indicate tab?
Should the text explain that \t means the TAB character?

5.7, "keep the group at least ten minutes."  Should there be a VIRTUALNGTTL
parameter?  (Probably read-only.)  Also typo on "it's" --> "its"

5.7.1, "group_pat" rule.  Is whitespace allowed before the ,group_specifier?
The example shows whitespace.  Usenet in general doesn't allow it, so
some explanation is needed.

5.7.1, "search_term" rule.  Flip TEXT and BODY to maintain alpha order.

5.7.1, just after the BNF.  "always required" strike always, it's redundant.

5.7.1, last paragraph: what is case insensitive -- keywords?  I assume
not search strings, since that requires the engine to parse MIME data...

5.7.2: Why don't Bob and I get along?

5.7.[12]: Why are these subsubsections?  Why don't they use the same
term (query vs. search)?  Perhaps all commands should be sectioned as:
	5.x FOO command
	...intro/discussion of foo
	5.x.1 EXAMPLES
	5.x.2 RESPONSES
or something similarly consistent.

5.8: Can responses in PRETTYNAME output?  Seems highly useful "Bob's
Reading List" would be more interesting to see than "virt.users.rsalz111"
for example.

5.10: "RET" and "DEL" Spell these out.

5.10.1: The profilenamehint *may* be used, not *is used*

5:10.2.  Is the intent of "PROFILE RETURN " (sic:) that a client can
retrieve the data so that it can recreate the group later if the server
deletes it?

5.1[56]:  The profile created in 5.15, isn't returned in 5.16 -- it says
	261 TEXT searchstring
thatlooks like meta-output that needs to be edited.

5.18:  I dislike single-word limitation on value, but don't know if it's
worth defining a quote-based syntax.  Again, I think read-only should be
supported.  Again**2, VIRTUALNGTTL is a worthwhile concept, expressed as
default number of minutes a group will exist after client disconnects.

5.24:  "LIST SEARCHES" is a bad word -- SEARCHABLE maybe?

5.27, 2nd and 3rd paragraphs:  I really like this.

5.27, penultimate paragraph:  In 5.8 it says client treats this as
a non-postable newsgroup.

6:  Other considerations:
    -	A malicious client modifying or deleting an existing profile
    -	Clients inadvertently leaking readership/interest by always embedding
	the user's name in the "namehint" when creating a profile.

Hope this helps.
	/r$
	One client changing the profile of existing one
	Clients tracking what others read, based on the name.