ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt

[Brian Hernacki]

Interesting reading Nat. After the feedback we received, Ben and I had
also been changing our draft to have SEARCH return overview-like data
directly (without virtual groups). For demand searching (not profiles)
it seems to be a cleaner approach..and people seemd to like this lighter
weight approach to SEARCH better. 

I've included some comments below.

Here are a couple things I'm not quite comfortable with (details are
below)
 o bogus article IDs in return data
 o redundant/uneeded syntax for headers (HEADER, FROM, etc)
 o seems like it's trying to hard to be IMAP

> The SEARCH  command searches the newsgroup for  articles that  match the
> given searching criteria.   Searching  criteria consist of one   or more
> search keys.  If there are articles that  match the search criteria, the
> server responds with  code 224 and returns  OVER data for each  matching
> article in the same  format as described  in [NNTP-NEW].  The article ID
> is only  meaningful  when searching either  the  current newsgroup or  a
> single newsgroup.

So in the general case where a search is across more than one group, the
article id's are bogus? are they fake values? Why not just not drop the
article numbers all together? Our revision suggests using overview like
data, but using this field for an Xref style entry (alt.foo.bar:7) so
that it is always valid. This way clients may either parse this, or
acces by MID.


>      <message set>  Messages with article identifiers
>                    corresponding to the specified message sequence
>                     number set.  This can only relevant for searches
>                     on a single newsgroups.
>
>      ALL            All messages in the newsgroup; the default initial
>                     key for ANDing.

I'm not sure I see the utility of these. Other than trying to mimic IMAP
they don't really seem to be needed for news. Why not just specify one
newsgroup in the newsgroups header? This is inly useful in the case
where you are searching one group anyways.

>      BEFORE <date>  Messages whose internal date is earlier than the
>                     specified date.

Do clients really care about internal dates? I would think the date the
article was posted covers the whole date categroy pretty well.

>      FROM <string>  Messages that contain the specified string in the
>                     envelope structure's FROM field.
>
>      HEADER <field-name> <string>
>                     Messages that have a header with the specified
>                     field-name (as defined in [RFC-822]) and that
>                     contains the specified string in the [RFC-822]
>                     field-body.

Why have redundant syntax? If I can say HEADER FROM or HEADER NEWSGROUP
why add more syntax? 

>      OR <search-key1> <search-key2>
>                     Messages that match either search key.

Why the change from an (implied) in-order AND to a pre-order OR? It's
not really that much harder to parse...


--brian